DMARC集計レポートの読み方｜不正送信と認証失敗を見分ける手順
DMARCの集計レポートを受け取り始めても、XMLの項目名や大量のIPアドレスを見ただけでは、何を直すべきか判断できません。知らない送信元をすべて不正送信とみなすと、正規のメール配信サービスやSaaS通知を止める恐れがあります。一方、SPFやDKIMの「pass」だけを見て安心すると、Fromドメインとのalignment不一致を見逃します。
結論：DMARC集計レポートは、報告期間と公開ポリシーを固定し、source_ipを正規の送信サービスへ照合したうえで、auth_resultsのSPF・DKIM認証とpolicy_evaluatedのalignment判定を分けて読みます。DMARC集計レポートの確認は「failの件数を見た時」ではなく、「送信元IPを正規の送信サービスへ紐付け、SPF・DKIMの認証とalignmentを分けて原因を特定し、修正後の再報告まで確認した時」に完了します。
本記事のポイント
- DMARC集計レポートは、source_ipの件数だけでなく、認証結果・Fromドメインとのalignment・受信側の処置を組み合わせて読みます。
- SPFまたはDKIMがpassでもドメインがFromと整合しなければDMARCではfailになり得るため、auth_resultsとpolicy_evaluatedを分けます。
- 未知の送信元を直ちに攻撃と決めず、正規サービスとの照合、転送・メーリングリスト、設定変更、不正利用の順で証拠を集めます。
DMARC集計レポートとは何を示すのか
DMARC集計レポートは、受信側メール事業者が、特定のFromドメインを使ったメールについて、送信元IP、件数、SPF・DKIMの結果、ドメインのalignment、適用した処置を期間単位でまとめて、DMARCレコードのruaで指定された宛先へ送る仕組みです。2026年5月に公開された現行標準のRFC 9989はDMARC本体、RFC 9990は集計レポートのXML構造と運用を定義し、旧RFC 7489を置き換えています。
レポートは、個々のメール本文、件名、受信者のメールアドレス、開封やクリックを確認するものではありません。送信元の接続IPと認証結果を集計し、自社ドメインを使う正規・非正規のメール経路を把握するための材料です。すべての受信事業者が必ずレポートを返すわけでもないため、「レポートにない送信は存在しない」「レポートにあるfailはすべて攻撃」とは判断できません。
| 確認対象 | 分かること | 単独では分からないこと |
|---|---|---|
| source_ip / count | 受信側が観測した接続元IPと同じ判定の通数 | そのIPが自社の正規委託先か、攻撃者か |
| policy_evaluated | DMARCのalignment結果と受信側が選んだ処置 | SPF・DKIM自体がなぜ失敗したかの詳細 |
| identifiers | From、MAIL FROMなど判定に使ったドメイン | メール本文や個別の受信者 |
| auth_results | SPFと各DKIM署名の検証結果・ドメイン | その送信が業務上許可されたものか |
| reason | 転送・メーリングリスト・ローカルポリシーなど処置の例外理由 | 例外が自社にとって許容できるか |
DMARCは、SPFまたはDKIMの少なくとも一方が検証に成功し、その認証ドメインがメールのheader_fromとalignmentしているときにpassします。SPF・DKIM・DMARCと到達率全体の関係は、メール到達率を改善する原因チェックで確認できます。暗号化されたSMTP配送の失敗を集計するTLS-RPTとは目的が異なるため、証明書やMTA-STSのエラーを調べる場合はTLS-RPTレポートの読み方を使います。
XMLは期間・報告元・公開ポリシーから読む
レコード行へすぐ進まず、最初に「誰が、いつの期間を、どのDMARCポリシーとして報告したか」を固定します。同じsource_ipでも、報告元や期間、適用されたポリシーが違えば件数をそのまま足せません。タイムゾーンはUTCのepoch秒で示されるため、社内の配信時刻や設定変更時刻と比較するときは変換します。
| 確認順 | XML要素 | 確認内容 | 見落としやすい点 |
|---|---|---|---|
| 1 | report_metadata / org_name | どの受信事業者・組織が報告したか | 報告元ごとに観測範囲と件数が異なる |
| 2 | report_id | 同じレポートの重複取り込みを防げるか | 再送時に同じファイルを二重集計しない |
| 3 | date_range / begin・end | UTCの集計期間 | 設定変更の前後を同じ期間で混ぜない |
| 4 | policy_published / domain | どのポリシードメインを対象にしたか | header_fromそのものと一致しない場合がある |
| 5 | p・sp・np | 組織ドメイン、既存・不存在サブドメインの方針 | 公開DNSの現在値と報告期間中の値を混同しない |
| 6 | adkim・aspf・testing | strict / relaxedのalignmentとテスト状態 | 古いレポート形式では項目名や任意項目が異なる |
現行のRFC 9990ではXML名前空間、XSD、report identifier、拡張要素、DKIM selectorなどが整理されています。既存の解析サービスや過去ファイルには旧RFC 7489形式が残る可能性があるため、取り込み処理は名前空間と必須・任意要素を検証し、未知の拡張要素を無理に通常フィールドへ変換しません。形式不正のファイルは通常集計から分離し、報告元、受信日時、検証エラーを残します。
添付されたXMLまたはgzipは、外部から届く入力です。RFC 9990は、細工された圧縮ファイルやXMLによる資源枯渇の危険を明示しています。専用メールボックスまたは受信APIへ集約し、ファイル種別、圧縮前後のサイズ上限、XML schema、解析時間、重複IDを検証します。担当者の端末で不明な添付を直接開く運用は避け、解析結果だけをダッシュボードや台帳へ渡します。
source_ip・認証結果・alignmentを組み合わせて分類する
1件のrecordには、接続元と件数を示すrow、Fromなどを示すidentifiers、SPF・DKIM自体の結果を示すauth_resultsがあります。最も重要な区別は、auth_resultsが認証機構そのものの検証結果、policy_evaluated内のspf・dkimがDMARCのalignmentを含む結果だという点です。
たとえば、配信サービスのMAIL FROMドメインでSPFがpassしていても、メールのFromが自社ドメインで、両者の組織ドメインが一致しなければSPF側のDMARC判定はfailです。DKIMも署名検証がpassしていても、d=のドメインがFromとalignしていなければDMARCのDKIM判定はfailです。反対に、SPFがfailでも、自社ドメインとalignしたDKIM署名がpassなら、DMARC全体はpassできます。
| 観測パターン | まず考えること | 確認する証拠 | 主な対応 |
|---|---|---|---|
| SPF・DKIMともDMARC pass | 正規送信の可能性が高い | 契約中サービス、送信ログ、DKIM selector | 正規送信元台帳へ登録し継続監視 |
| auth_resultsはpass、policy_evaluatedはfail | 認証ドメインとFromのalignment不一致 | MAIL FROM、DKIM d=、header_from、adkim・aspf | カスタムMAIL FROMまたはDKIM署名ドメインを調整 |
| 正規IPだがSPF・DKIMともfail | DNS・selector・サービス設定の不備 | 送信サービス設定、DNS、鍵更新、変更履歴 | 正規経路を止めずに認証設定を修正 |
| 未知IP、少量、reasonあり | 転送・メーリングリスト・受信側例外 | reason、報告元、同じ経路の継続性 | 急いで遮断せず分類と影響を確認 |
| 未知IP、高頻度、複数報告元で継続 | 未管理サービスまたは不正利用の疑い | IP所有者、逆引き、契約、社内申請、送信ログ | 正規性を確認し、未許可なら封じ込めと監視 |
| dispositionが公開ポリシーと異なる | 受信側のローカルポリシーやoverride | reason、policy_published、受信側仕様 | 処置だけで自社設定の成否を断定しない |
source_ipの逆引き名だけで所有者を確定しないことも重要です。メール配信サービスはIPプールを共有・変更することがあり、CRM、請求、採用、問い合わせフォーム、電子契約、監視通知など、マーケティング部門が知らない正規送信経路もあります。利用サービス、送信用途、From、MAIL FROM、DKIM d=とselector、管理者、契約終了日を台帳へ揃えます。新しい送信ツールの選定時に確認する認証・配信停止・承認項目は、メール配信ツールの要件定義で整理できます。
受信から再確認までを6ステップで運用する
DMARC集計レポートは、担当者が日々XMLを眺める方式では継続できません。受信、検証、正規化、送信元照合、原因分類、修正後確認を同じ処理単位にし、件数の多さだけでなく業務影響を加えて優先順位を決めます。
- 安全に受信し重複を除く：専用宛先へ集約し、MIME種別、圧縮後・展開後サイズ、XML形式、report_id、報告元を検証します。不正形式は通常集計と分離します。
- 期間とポリシーを固定する：
date_range、policy_published、公開DNSの変更履歴を照合し、変更前後のレポートを混ぜません。 - 送信元を正規台帳へ照合する：
source_ip、From、MAIL FROM、DKIM d=・selectorを、メール配信、SaaS通知、業務システム、委託先の一覧へ紐付けます。 - 認証とalignmentを分ける：
auth_resultsでSPF・DKIM自体の成否を見て、policy_evaluatedでFromとのalignmentとdispositionを確認します。 - 正規・設定不備・間接経路・未許可へ分類する：正規送信は基準値に、設定不備は修正案件に、転送等は例外観測に、未許可の疑いはセキュリティ調査へ渡します。
- 修正後の次回レポートで閉じる：DNSや配信設定を変えた時刻を残し、主要な報告元で同じ送信経路のDMARC passと件数の回復を確認します。
優先度は「fail件数が多い順」だけでは決めません。請求書、パスワードリセット、商談連絡など業務停止につながる正規送信の設定不備は、少量でも先に直します。大量でも完全に未許可で、現在のp=noneが配送へ影響していない場合は、送信元の正体と封じ込め方法を確認してからポリシー変更へ進みます。新しいドメインや送信基盤を立ち上げる場合は、送信ドメインのウォームアップ手順と同じ変更台帳へDMARCの基準値を残すと比較しやすくなります。
p=noneから強制ポリシーへ移る判断基準
p=noneは、DMARCを「無効」にする設定ではなく、認証とalignmentを監視しながら、失敗メールにquarantineやrejectを求めないMonitoring Modeです。RFC 9989は、正規送信経路の見落としを発見するためにp=noneから始め、未整合・未認証の正規メールを修正してからEnforcementを判断する流れを示しています。
強制ポリシーへ移る前に、少なくとも次の状態を確認します。
- 自社ドメインを使うメール配信サービス、SaaS通知、業務システム、委託先が送信元台帳に登録されている
- 業務上重要な送信経路で、SPFまたはDKIMの少なくとも一方がFromとalignして継続的にpassしている
- 未分類の高頻度IP、突然増えたselector、正規IPの認証failに担当者と対応期限が付いている
- 転送、メーリングリスト、海外拠点、季節配信など低頻度の経路を観測する期間を確保している
- ポリシー変更後に到達率、バウンス、問い合わせ、DMARCレポートを確認する担当と戻し方が決まっている
現行のRFC 9989では、旧RFC 7489のpctタグが削除され、テスト状態を示すtタグへ整理されています。古い設定例の「pctを少しずつ上げる」をそのままコピーせず、利用中の受信事業者、配信サービス、解析ツールが現行仕様をどう扱うか確認してください。移行は、対象ドメインやサブドメイン、p・sp・np、t、変更日時、監視期間、戻し方を一つの変更計画にします。
RFC 9989は、一般利用者がメーリングリストへ投稿するような汎用メールドメインではp=rejectを推奨していません。転送やメーリングリストなどの間接経路で正規メールが失敗し得るためです。p=rejectを検討する場合も、SPFだけに依存せず、FromとalignするDKIM署名を整え、少なくともp=noneとp=quarantineの期間を分けて集計結果を比較します。
Google WorkspaceのDMARCの段階的導入に関する公式ガイドも、まずレポートを監視し、正規メールの問題を解消してから強化する考え方を示しています。ただし、同ページのpctを使う設定例は旧仕様に基づくため、現行RFCの変更点を確認して文字列だけをコピーしないでください。DMARCの強制は到達率を自動的に上げる施策ではなく、Fromドメインを正当に使う経路を判別しやすくする管理です。BIMIのロゴ表示まで進める場合は、BIMI導入とDMARC enforcementの条件も確認してください。
よくある質問
DMARC集計レポートとは何ですか？
受信側が観測した送信元IP、件数、SPF・DKIMの認証結果、Fromドメインとのalignment、適用した処置を期間単位でまとめたXMLです。個々の本文や受信者を確認するレポートではなく、自社ドメインを使うメール経路の全体像を把握するために使います。
SPFとDKIMの失敗をどう見分けますか？
auth_resultsはSPF・DKIM自体の検証結果、policy_evaluated内のspf・dkimはDMARCのalignmentを含む判定です。認証がpassでも、認証ドメインがheader_fromと整合しなければDMARC側はfailになり得ます。二つの層を分けて確認します。
知らないsource_ipが出たら不正送信ですか？
未知のIPだけでは断定できません。利用中のメール配信サービス、CRM、問い合わせフォーム、請求、採用、電子契約、監視通知の契約と送信ログへ照合します。一致しない場合に、転送・メーリングリスト、直近の設定変更、未申請サービス、不正利用の順で調べます。
p=noneから強制ポリシーへいつ移行しますか？
正規送信経路が一覧化され、主要な送信パターンでDMARC passが継続し、未分類の高頻度送信元と業務上重要なfailがなく、変更後の監視と戻し方が決まってから検討します。低頻度の季節配信や委託先送信を観測できる期間も確保します。
DMARC集計レポートだけですべての送信を把握できますか？
すべては把握できません。レポートを送る受信事業者と観測期間に限られ、すべての受信者や攻撃を網羅しません。配信サービスの送信ログ、バウンス、受信側の評価指標、問い合わせを併用し、レポートの欠落自体も監視します。
転送やメーリングリストでfailが出るのはなぜですか？
転送ではSPFのMAIL FROMや接続元が変わり、メーリングリストでは本文・件名への変更でDKIM署名が壊れることがあります。reason、報告元、同じ経路の継続性を確認し、未知のIPという理由だけで不正送信と断定しません。
実務で確認できる公式資料
- IETF RFC 9989：DMARCでは、alignment、Monitoring Mode、Enforcement、ポリシーレコード、集計レポートを使った送信経路の是正を確認できます。
- IETF RFC 9990：DMARC Aggregate Reportingでは、XML要素、XSD、sample report、セキュリティと運用上の注意を確認できます。
- Google Workspace管理者ヘルプ：DMARCレポートでは、レポートの受信設定と日常確認の考え方を確認できます。
- Google Workspace管理者ヘルプ：推奨されるDMARC導入では、監視からポリシー強化へ進む運用を確認できます。
