DMARCレポートの読み方：ポリシー適用の前に確認

rua=のアドレスを指定したDMARCレコードを公開すると、メールプロバイダーから、自社ドメインを使っているすべてのサーバーについてのレポートが毎日届き始めます。DMARCレポートの読み方を身につけているかどうかが、安全にポリシー適用へ進めるか、自社の請求書をうっかり迷惑メールに送ってしまうかの分かれ目になります。ただし、これらのレポートは人が流し読みすることを想定していない、読みにくいXMLで届きます。このガイドでは、集計レポートに何が含まれているのか、認証に失敗している正規のメールをどう読み取って見つけるのか、そしてレポート解析ツールがどこで役立つのかを説明します。

結論#

DMARCの集計レポート（rua=タグによって送信されるもの）は、受信側が1日に1回ほど送ってくるXMLファイルです。各レポートは、自社ドメインを名乗るメールを送信元IP別にまとめています。送信元ごとに、メール数、SPFとDKIMがアライメントを一致させた状態で成功したかどうか、そして受信側がそのメールをどう処理したかがわかります。レポートを読む目的は2つあります。自社名義で送信している送信元の全体像を把握すること、そしてp=noneからquarantine、rejectへとポリシーを引き上げる前に、すべての正規の送信がアライメントを一致させて認証されていることを確認することです。生のXMLは読みにくいため、ほとんどの人はDMARCレポート解析に読み込み、読みやすい表に変換しています。

すでにレポートをお持ちの場合は、無料のDMARCレポート解析に貼り付けるかアップロードすれば、お手元のデータでこのガイドを追いながら確認できます。すべての解析はブラウザー内で行われ、アップロードはされません。

集計レポートが送られるきっかけ#

きっかけは、DMARCレコードのタグ1つです。_dmarc.yourdomain.comにrua=を公開すると、対応しているすべての受信側に、集計フィードバックをメールで送るよう依頼することになります。

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

その後は、Google、Yahoo、Microsoft、Comcastなどの大手受信側が、24時間のうちにyourdomain.comから受け取ったすべてのメールをまとめ、ドメインごとに1通のXMLレポートを送ってきます。レポートは通常、圧縮された添付ファイル（.xml.gzまたは.zip）で届き、ファイル名にはレポートの送信元、自社ドメイン、対象期間が含まれています。ruaには複数のアドレスを指定できます。外部の送信先を使えば、管理していないドメインのレポートを集めることもできますが、その場合はレポートを受け取る側のドメインに追加の承認レコードが必要です。まだレコードを公開していない場合は、順を追って解説したDMARCの設定手順から始めてください。レポートの送信は、レコードが有効になって初めて始まります。

DMARC集計レポートを1行ずつ読む方法#

集計レポートはすべて、RFC 7489で定められ、その後RFC 9989とRFC 9990に置き換えられた同じXMLスキーマに従っています。構成は3つの部分です。レポートの送信者、その時点で公開されていたポリシー、そして1つ以上の<record>ブロック（送信元ごとに1つ）です。1件のレコードを抜粋した例を示します。

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>128</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <selector>s1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

最も重要なのは、レポートが認証結果を2つの異なる場所に記載しており、その意味が異なるという点です。

auth_resultsブロックが報告するのは、SPFとDKIMがそもそも成功したかどうかです。一方、policy_evaluatedブロックが報告するのは、アライメントが一致した状態で成功したかどうかで、DMARCが重視するのはこちらだけです。この2つは食い違うことがあり、調査の大半はその差分に費やされます。

認証に失敗している正規の送信元を見つける#

探すべきパターンと、それが重要な理由を説明します。たとえば、source_ipが利用中のマーケティングプラットフォームのものだと明らかで、header_fromが自社ドメインのレコードがあるとします。auth_resultsにはspf: passと表示されていますが、記載されているSPFのドメインは自社ではなくプラットフォーム自身のバウンス用ドメインで、policy_evaluated/spfはfailです。このメールは誰かのためには認証されていますが、自社としてアライメントが一致する形では認証されていません。p=noneの間はdispositionがnoneのままなので、まだ何も壊れていません。しかしquarantineやrejectに移行した瞬間、そのcountにあたるメールがすべて迷惑メールに振り分けられたり、バウンスしたりし始めます。

そのため、読み方は常に次の3段階の比較になります。

• 送信元を特定します。各source_ipを実在のサービスに対応付けます。逆引きDNSを確認するか、解析ツールの自動ラベル付けを使えば、たいてい名前がわかります。目標は完全な一覧を作ることです。レポートからは、忘れていた請求ツールや、いまだに自社名義で送信している古いキャンペーンプラットフォームが見つかることがよくあります。
• 認証だけでなく、アライメントも確認します。見るのはauth_resultsではなくpolicy_evaluatedです。送信元がSPFやDKIMに成功していても、認証されたドメインが「From」と一致していなければ、DMARCには失敗することがあります。
• 修正するか、失敗のままにするかを決めます。正規の送信元なら、アライメントを修正します。SPFに追加するか、さらに望ましくは自社ドメインでDKIM署名を設定し、署名ドメインが一致するようにします。なりすまし犯であれば、その失敗はまさに望む結果です。将来のp=rejectが役目を果たす証拠にもなります。

優先すべきは、通常SPFよりもDKIMのアライメントです。DKIM署名はメールと一緒に届くため転送されても有効ですが、SPFのアライメントは中継された時点で崩れるからです。アライメントの仕組み、つまり緩和されたアライメントと厳格なアライメントの違い、組織ドメインと完全一致の違いは、概念をじっくり確認したい場合にSPF・DKIM・DMARCの解説で説明しています。

RUAとRUF：まったく別の2種類のレポート#

DMARCにはレポート用のタグが2つあり、互換性はありません。

• ruaは集計レポートです。ここまで説明してきた、1日ごとのXMLサマリーです。メールの内容は含まれず、送信元ごとにまとめた件数と結果だけが記載されています。導入の全期間を通じて頼りにするのはこのレポートで、主要な受信側はすべて送信します。
• rufはフォレンジック（失敗）レポートです。個々のメールが認証に失敗した時点で、メール単位で生成されます。従来はヘッダーや、場合によってはメールの一部が含まれることがあり、個人データを含む可能性があります。

フォレンジックレポートは受信者の情報を漏らすおそれがあるため、大手プロバイダーの多くはプライバシー上の理由で何年も前に送信をやめており、rufをまったく公開しない送信者も大勢います。両方を要求するレコードは次のようになります。

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:agg@example.com; ruf=mailto:forensic@example.com"

実際には、ruaの集計レポートは継続的に届き、rufのフォレンジックレポートはほとんど、あるいはまったく届きません。監視は集計データを前提に計画してください。届いたフォレンジックレポートは、たまに得られるおまけとして扱います。rufを有効にするのは、適法な根拠があり、個人データを含む可能性のある内容を保管する場所がある場合だけにしてください。

受信トレイで直接読むのではなく、解析ツールを使う理由#

XMLを手作業で開くことはできます。送信元が2、3件しかない1つのドメインなら、しばらくはそれでしのげるでしょう。しかし、すぐに限界が来ます。送信量の多いドメインでは、異なる受信側から1日に数十通のレポートが届き、それぞれに多数の送信元IPが並びます。重要な手がかり、つまり正規の送信者がひそかにアライメントに失敗していることは、UNIXタイムスタンプのタグや、ラベルのないIPアドレスの中に埋もれてしまいます。おすすめのDMARC監視ツールでは、重要な基準でそれぞれの選択肢を比較しています。

DMARCレポート解析ツールや監視ダッシュボードは、専用のアドレスに届いたレポートを取り込み、圧縮を展開してXMLを解析し、IPアドレスを認識しやすいサービス名に変換して、すべてを読みやすい表にまとめます。送信元を縦に、成功と失敗の件数を横に並べ、時系列の推移も確認できます。優れたツールは、新しい送信元や新たに失敗し始めた送信元にフラグを付けるため、すべてのファイルを読み直さなくても変化に気づけます。ホスト型のサービスでも自前のパーサーでも、役割は同じです。XMLの山を、「自社名義で送信しているのはここで、まだアライメントが一致していないのはここだ」という情報に変えることです。この明確さによって、レポートは単に保管されるだけのものではなく、行動につながるものになります。

安全な導入手順の中での位置付け#

レポートを読む作業は、DMARCの設定とは別の雑務ではありません。導入の中間段階そのものであり、これを飛ばすと自社のメールを埋もれさせることになります。手順は次のとおりです。

1. ruaを指定してp=noneを公開します。メールの扱いは何も変わらず、レポートの送信が始まるだけです。
2. 送信サイクルを一通り把握するまで、集計レポートを読みます。最低でも2週間、月次の明細書のように送信頻度の低いメールがある場合はさらに長くかかります。送信元の完全な一覧を作ります。
3. アライメントに失敗している正規の送信元をすべて修正します。実際に最も時間がかかるのがここで、レポートが対処すべき箇所を示してくれます。
4. quarantine、次にrejectへ移行します。すべての正規の送信がアライメントを一致させて成功していることがレポートで確認できてからにしてください。p=rejectは、なりすましを実際に止められる設定であり、GoogleとYahooの送信者ガイドラインにある大量送信者向けのルールも満たします。

rejectに到達したあとも、レポートは役立ち続けます。自社で新たに追加したSaaSツールが自社名義で送信し始めたことや、ブランドを狙ったなりすましキャンペーンが拡大していることを検知できるからです。フィードバックループによる迷惑メール報告や全体的な送信者レピュテーションとあわせて確認すれば、一度きりの設定作業ではなく、早期警戒の仕組みとして使えます。QualisendのDMARCレポートは、ドメインごとの集計レポートを、成功数と失敗数付きの送信元の表にまとめます。生のXMLを開かなくても、新しい送信元に気づけます。この表を軸にした週次ルーティンについては、DMARCモニタリングをご覧ください。

正直に言っておくべき限界があります。DMARCにアライメントが一致した状態で成功しても、証明されるのは送信者が誰かであり、優良な送信者であることではありません。アライメントが完全に一致したドメインでも、無効なアドレスやスパムトラップに送信していれば、迷惑メールに振り分けられます。認証は入場券であり、配信先を決めるのはリストの品質とエンゲージメントです。この大きな全体像はメール到達率ガイドで扱っています。レポートに問題がなくても正規のメールが迷惑メールに振り分けられる最も多い原因は、これです。

集計レポートからわかるのは、誰が自社名義で送信しているかであり、そのメールの宛先リストがクリーンかどうかではありません。無料メールチェッカーにアドレスを通せば、バウンスする前に、無効なドメイン、入力ミス、スパムトラップを取り除けます。アライメントが完全に一致したドメインでも、受信トレイに届くには健全なリストが必要だからです。