// シス担のミカタ
セキュリティ

DMARC でぃーまーく

メール認証SPFDKIMなりすましメール対策フィッシング対策ポリシー
DMARCについて教えて

簡単に言うとこんな感じ！

DMARCは「うちの会社のふりをしたメールが来たら、受け取り側でブロックしてね」と宣言できる仕組みだよ。フィッシング詐欺に使われる”なりすましメール”を防ぐ、メール界の「入口警備員への指示書」みたいなものなんだ！

DMARCとは

DMARC（Domain-based Message Authentication, Reporting, and Conformance）とは、メールの送信ドメインが正規のものかどうかを受信側で検証し、不正なメールをどう扱うかを送信側が指定できるメール認証の枠組みです。「なりすましメール」や「フィッシングメール」を組織的に防ぐための仕組みとして、2012年に主要なメール事業者が共同で策定しました。

DMARCは単体で動くわけではなく、SPF（送信元IPアドレスの認証）とDKIM（電子署名による改ざん検知）という2つの既存の認証技術を土台にしています。受信側のメールサーバーは「このメールはSPFまたはDKIMで正当性が確認できたか？」を確認し、確認できなかった場合にどう処理するかをDMARCポリシーに従って判断します。

さらにDMARCにはレポート機能があり、自分のドメインを使ったメール送受信の状況を定期的に管理者へ報告させることができます。「誰かが自社ドメインを使ってなりすましメールを送っていないか」を把握・監視できる点が、SPF・DKIMにはない大きな特徴です。

DMARCの仕組みと3つのポリシー

DMARCの核心は「認証に失敗したメールをどう扱うか」をDNSのTXTレコードに書いておくことです。受信サーバーはそのドメインのDNSを参照し、指示に従います。

ポリシーの種類（p= タグ）

ポリシー値意味実務での使いどころ
none何もしない（モニタリングのみ）導入初期。まずレポートで状況を把握する
quarantine迷惑メールフォルダへ振り分けるSPF/DKIMの整備が済んだら次のステップ
rejectメールを完全に拒否・破棄する最終形。なりすましを完全ブロック

DMARCレコードの例

v=DMARC1; p=reject; rua=mailto:dmarc-report@example.com; ruf=mailto:dmarc-fail@example.com; pct=100
タグ内容
v=DMARC1バージョン指定（必須）
p=rejectポリシー指定（none / quarantine / reject）
rua=集計レポートの送付先メールアドレス
ruf=失敗レポート（フォレンジック）の送付先
pct=ポリシー適用割合（%）。段階的に引き上げられる

覚え方：「ノー・クワ・リジェ」で段階アップ

導入は none → quarantine → reject の3ステップで段階的に進めるのがセオリーです。「ノー・クワ・リジェ」と唱えて覚えておきましょう。最初からrejectにすると、正規のメールまで弾いてしまうリスクがあります。

認証フローの全体像

DMARCの認証フロー 送信者 example.com DNS SPF/DKIM/DMARC 受信サーバー メール受信 SPF検証 送信元IPを確認 DKIM検証 電子署名を確認 DMARC判定 ポリシー適用 pass → 受信 受信者へ届く fail → ポリシー none/quarantine/reject レポート送信 管理者へ集計

歴史と背景

  • 2000年代初頭 — なりすましメール・フィッシング詐欺が急増。SPF・DKIMが個別に普及し始めるが、「検証失敗時の処理方法」が統一されていなかった
  • 2012年1月 — PayPal・Google・Microsoft・Yahoo!・Facebook などが共同でDMARCを策定・公開。業界標準として普及を推進
  • 2015年 — RFC 7489 としてIETFに情報提供RFCとして登録
  • 2019年 — 米国連邦政府機関がDMARC（policyはreject）の導入を義務化（BOD 18-01指令）
  • 2022年〜 — Googleおよび米Yahoo!が、大量メール送信者に対してDMARC設定を必須化すると発表。日本でも金融機関・大企業で導入が急速に広がる
  • 2024年2月 — GmailとYahoo! Mailが「1日5000通以上送るドメインはDMARC必須」ルールを施行。メールマーケティング業界への影響が特に大きかった

SPF・DKIM・DMARCの役割の違い

3つの仕組みはセットで理解するのが重要です。

技術何を検証するかDNSレコード種別単独で十分か
SPF送信元IPアドレスが許可リストにあるかTXTレコード△（転送メールに弱い）
DKIMメール本文・ヘッダーが改ざんされていないかTXTレコード（公開鍵）△（From詐称を防げない）
DMARCSPF/DKIMの結果 + Fromドメインの一致確認 + 失敗時の処理指定TXTレコード◎（上2つの弱点を補う）

SPF・DKIM・DMARCの関係図

SPF / DKIM / DMARC の関係 SPF 送信元IPを認証 DNSのTXTレコード DKIM 電子署名で改ざん検知 公開鍵をDNSに登録 DMARC SPF・DKIMの結果を統合 → Fromドメインと突き合わせ 失敗時ポリシー（none/quarantine/reject）＋レポート送信 From ドメイン メールヘッダーの 差出人ドメイン

実務での注意点

導入前に確認すべきこと

  • 自社ドメインからメールを送るシステムをすべてリストアップする（社内メール・メルマガ配信・問い合わせフォーム・SFA/CRMツールなど）
  • それぞれのシステムにSPF・DKIMが設定済みかを確認する
  • DMARCを reject にする前に、必ず none でレポートを数週間収集し、意図せず弾かれるメールがないかを確認する

よくある落とし穴

落とし穴説明
メール転送の失敗転送メールはSPFが破れやすく、DMARCが厳しいとブロックされることがある
サードパーティサービスの見落とし採用ツール・決済通知・MAツールなど、自社ドメインを使うSaaSのSPF/DKIM設定を忘れがち
レポートの未確認rua= を設定してもレポートを見なければ意味がない。専用の解析ツール（dmarcian等）の活用を推奨

関連する規格・RFC

規格・RFC番号内容
RFC 7489DMARCの仕様を定義した情報提供RFC（2015年制定）
RFC 9091DMARC実験的拡張（Experimental）に関するRFC
RFC 7208SPF（Sender Policy Framework）の仕様
RFC 6376DKIM（DomainKeys Identified Mail）の仕様
RFC 5321SMTP（Simple Mail Transfer Protocol）の仕様

関連用語

  • SPF — 送信元IPアドレスをDNSで許可する、メール送信元認証の仕組み
  • DKIM — 電子署名でメールの改ざんを検知するメール認証技術
  • フィッシング — なりすましメールなどで個人情報を詐取するサイバー攻撃の手口
  • DNS — ドメイン名とIPアドレスを対応付けるインターネットの名前解決システム
  • SMTP — メールを送信・転送するためのプロトコル
  • メールヘッダー — メールの送信経路・差出人・日時などを記録したメタデータ
  • ゼロトラスト — 「信頼しない・常に検証する」を原則としたセキュリティアーキテクチャ