DMARCレポートの見方：集計レポートを読み解く

DMARC集計レポートの読み方

集計レポートはXMLで届きます。XMLは機械向けの形式で、人が目で読むものではありません。最も早いのは、ファイルをレポートリーダーに読み込ませ、送信元の表として表示することです。ただし、表示された内容を理解するには、元のセクションの意味を知っておくと役立ちます。

DMARCのXMLレポートを確認するたびに、この手順に従います。

1. レポートを開く。通常はXMLの添付ファイル（多くはgzip圧縮）か、監視ダッシュボードで届きます。
2. レポートのメタデータを読む。ヘッダーには、レポートを送った組織、対象期間、自社のドメインが記載されています。どのレポートを見ているのかを把握するための情報です。
3. 公開ポリシーを確認する。受信側が確認した自社ドメインのDMARCポリシー（none、quarantine、reject）とサブドメインポリシーが表示され、レコードが意図どおりに読まれたかを確認できます。
4. レコード行を順に確認する。各行が一つの送信元です。IPアドレス、メッセージ数、SPFとDKIMの結果、それぞれがFrom:ドメインと一致したか、処理結果（受信側の対応）が記載されています。
5. 送信元の候補を特定する。送信元IPと認証ドメインを、考えられる送信サービスと照らし合わせ、責任を持つ業務上の担当者を見つけます。見覚えのあるネットワーク名やベンダー名は手がかりであり、承認の判断ではありません。
6. 根拠を調べる。重要な送信元ごとにレポート期間を記録し、本番の送信経路とされる経路から新たに配信されたメッセージを確認します。承認、修正、廃止、エスカレーションの前に、表示上のFrom:ドメイン、SPFのID、DKIMのd=ドメイン、アライメント、業務上の目的、担当者を確認してください。

最も重要なフィールドはアライメントです。DMARCで必要なのは、SPFかDKIMのどちらか一方が合格し、かつ表示上のFrom:ドメインと一致することだけで、両方は必要ありません。SPFが失敗でも、DKIMが一致して合格していれば、DMARCに合格できます。ただし認証に成功しても、業務としてその送信元を承認した証明にはなりません。

DMARCレポートの行からわかること、わからないこと

DMARCの集計データが示す範囲は、意図的に狭くなっています。技術的な結果と、組織としての承認の判断は分けて考えてください。

RFC 9990は、生の認証結果を、DMARCのアライメント結果や報告された処理結果と区別しています。だからこそ、IPの調査やSPFの合格だけでは、送信元の判断に不十分なのです。

処理結果とポリシー値からわかること

どのレポートにも受信側が検出したポリシーが記載され、各行には評価後に報告されたDMARCの処理結果が含まれます。none、quarantine、rejectは段階的に強い処理を求めるものですが、受信側のオーバーライドや他のフィルタリングで最終的な結果が変わることがあります。一般的な導入の流れはnone → quarantine → rejectです。組織が重要な送信元を特定し、アライメントの不備を解消し、例外を記録し、ロールバックの準備を整えてから、段階的に厳しくします。最後の二段階のどちらを選ぶかは、DMARCのrejectとquarantineの違いをご覧ください。

DMARCレポートを読むときのよくある問題

レポートで起きる問題の多くは、予測できるいくつかの原因から生じます。見分け方と対処法は次のとおりです。

レポートがまったく届かない

レポートが届かない原因は3つあります。まず、ruaの構文を確認します。アドレスは完全なmailto:形式のURIである必要があり、誤字があると配信されません。次に、レポート対象とは別のドメインのアドレスに送る場合、受け取る側のドメインが承認レコード（v=DMARC1を含む、yourdomain._report._dmarc.receiver.comのTXTレコード）を公開していないと、受信側は送信を拒否します。最後に、時間をおいてください。多くの受信側はレポートを毎日送り、RFC 9990はより頻繁な送信も認めています。作成したばかりのレコードや、送信量がごく少ないドメインでは、何か届くまでに一日か二日かかることがあります。レコードが公開され正しいかは、DMARCチェックで確認してください。

XMLが読めない

それは想定どおりです。集計レポートは人ではなくパーサー向けの構造なので、<record>や<row>タグだらけの生のXMLは、どうしても読みにくく見えます。手で読もうとせず、ファイルをDMARCレポートリーダーや監視サービスに読み込ませてください。XMLが、合格／失敗の件数付きで送信元ごとに並ぶシンプルな表に変わります。

正規の送信元でSPFが失敗、DKIMが合格。問題はありますか？

影響を受けるメッセージは、SPFが失敗しても、一致したDKIM署名によってDMARCに合格できます。それでも、想定外のSPF失敗は調べてください。本番の経路が変わった、または設定を誤っている可能性があります。SPFとDKIMの両方を一致させておけば、後でどちらかの仕組みが壊れても、送信元は影響を受けにくくなります。

転送メールが失敗と表示される

転送では、元の送信者ではなく転送サーバーが評価されるため、元のSPFの経路が壊れることがよくあります。DKIMは単純な転送なら壊れずに残りますが、署名済みの内容を変更する転送サービスやメーリングリストでは、署名が無効になることもあります。対処法を決める前に、受信側が付加した信頼できるAuthentication-Results、一致したDKIM署名、ARCの根拠を確認してください。RFC 8601は、認証結果が信頼できるのは定義された受信境界の内側だけである理由を説明しています。

見覚えのない送信元がレポートに表示される

不明な送信元は、根拠と責任を持つ担当者によって判断が裏付けられるまで、未解決として扱います。まずDNSルックアップとプロバイダーの照合から始めますが、ホスト名、国、ネットワークの所有者だけで送信元を分類しないでください。請求、人事、マーケティング、サポート、トランザクションメールのアプリケーションを担当するチームに、そのサービスを使っているかを尋ね、本番の送信経路とされる経路から新たに配信されたメッセージを提供してもらいます。

次に、4つの点を比較します。

1. レポートの根拠：送信元IP、送信量、レポート期間、評価されたドメイン、アライメント。
2. メッセージの根拠：表示上のFrom:、エンベロープのドメイン、DKIMのd=ドメインとセレクタ、受信側が付加した信頼できる認証結果。
3. 業務上の根拠：担当者名、目的、想定される送信量、そのサービスが今後もこのドメインとして送信すべきだという確認。
4. 設定の根拠：送信プラットフォームでの現在のドメイン検証の状態と、必要なSPFまたはDKIMの正確な変更内容。

送信元をauthorized、pending confirmation、unauthorized、retired、exceptionのいずれかに分類します。修正に進むべきなのは、認証の不備が確認された承認済みの送信元だけです。サービス名、SPFのinclude、合格したDKIM署名、他チームでの利用は、いずれも承認の根拠になりません。どの担当者も送信元を確認できない場合は、SPFを広げたりポリシーを変えたりせず、根拠を保全してエスカレーションしてください。

不明な送信元の調査が繰り返され、ソフトウェアの購入を検討しているなら、DMARCソフトウェア評価チェックリストで、ベンダーごとの根拠の扱い方を比較してください。候補を絞り込んだら、DMARCの概念実証（PoC）計画を使い、代表的な送信元でそのワークフローをテストします。

メール認証におけるレポートの位置付け

DMARC自体は何も認証しません。受信側は、SPFとDKIMの結果をFrom:ドメインと照らし合わせて評価し、ドメイン所有者が求めるポリシーを参考にローカルな処理を選びます。レポートは、それらのチェックが合格し一致したかを送信元ごとに記録します。だからこそ、失敗する送信元を直すには、必ずそのSPFかDKIMの設定を修正することになります。ドメインの3つの仕組みはEmail Security Scoreでまとめて確認できます。個別のレコードはSPFとDKIMのツールで確認してください。

DMARCレポートを定期的に確認すれば、新しい送信元の候補や認証の変化が見えてきます。担当者の確認と本番メッセージの根拠を組み合わせれば、修正とポリシー強化について、より安全な判断ができます。

規格についての補足：DMARCは最初の十年間、RFC 7489で定義されていました。2026年、IETFはコアプロトコルとしてRFC 9989を、集計レポートとしてRFC 9990を、失敗レポートとしてRFC 9991を公開しました。これらによってRFC 7489は廃止されます。フィールドやポリシーの動作を解釈するときは、最新の文書を使ってください。

分類後の送信元ごとの認証失敗については、DMARCが失敗する原因と対処法をご覧ください。

根拠

出典と参考資料

• RFC 9989：Domain-based Message Authentication, Reporting, and Conformance：p、rua、rufタグを含む、現行のDMARCコア仕様。
• RFC 9990：DMARC Aggregate Reporting：集計レポートの形式と、受信側による送信方法。
• RFC 9991：DMARC Failure Reporting：失敗レポートの形式とプライバシー上の考慮事項。
• RFC 8601：Message Header Field for Indicating Message Authentication Status：認証結果のフィールドとその信頼境界。

関連記事

• DMARCとは？
• DMARCの設定方法
• DMARCのrejectとquarantineの違い