DMARC 集計レポート(Aggregate Report)
概要
DMARC 集計レポート(Aggregate Report) は、DMARC の rua= タグで指定したアドレスに受信サーバーから送られる XML 形式のレポートです。仕様は RFC 7489(2015年)で定義されています。
レポートには、指定された期間(通常 24 時間)に受信したメールの送信元 IP アドレス、件数、SPF・DKIM・DMARC の認証結果が記録されています。どの IP からどれだけのメールが送られ、認証が pass したか fail したかを把握することで、自社の正規送信インフラが適切に設定されているか、不審な送信元がないかを確認できます。
p=none のモニタリングフェーズでも集計レポートは届くため、ポリシー強化前のデータ収集に活用します。
仕組み
受信プロバイダーがレポートを生成・送信するタイミングと、XML の構造を説明します。
送信タイミングと送信元
集計レポートは受信サーバー側が生成して送信します。Gmail、Yahoo、Outlook などの主要プロバイダーは DMARC レポートの送信に対応しています。送信タイミングは通常 24 時間ごとで、UTC 0 時を基点とする 1 日分のデータをまとめて送ります。
1 つの受信プロバイダーから 1 通のレポートが届く形式です。大量送信をしている場合、Gmail、Yahoo、Outlook それぞれから別々のレポートが届きます。
XML の構造
レポートは ZIP または GZIP で圧縮された XML ファイルとして届きます。ファイル名の形式は 送信者ドメイン!受信者ドメイン!開始日時!終了日時.xml.gz です。
XML の主要な構造は次の通りです。
<feedback>
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>12345678901234567890</report_id>
<date_range>
<begin>1712880000</begin>
<end>1712966400</end>
</date_range>
</report_metadata>
<policy_published>
<domain>example.com</domain>
<aspf>r</aspf>
<adkim>r</adkim>
<p>reject</p>
<sp>reject</sp>
<pct>100</pct>
</policy_published>
<record>
<row>
<source_ip>192.0.2.1</source_ip>
<count>150</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>
<result>pass</result>
<selector>s1</selector>
</dkim>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
</feedback>
フィールドの読み方
report_metadata はレポートを送ってきたプロバイダーの情報と集計期間(Unix タイムスタンプ)です。
policy_published はレポート生成時点で受信サーバーが確認した DMARC ポリシーです。自分が設定した内容と一致しているかを確認できます。
record が 1 送信元 IP ごとの集計単位です。source_ip が送信元 IP、count がその IP からのメール件数、policy_evaluated がアライメントを含む最終評価結果です。disposition は none(ポリシー適用なし)、quarantine(迷惑メール振り分け)、reject(受信拒否)のいずれかです。
auth_results は SPF と DKIM それぞれの認証結果(pass / fail)です。policy_evaluated の dkim や spf はアライメントを含む総合評価、auth_results 配下は認証そのものの結果です。両者が異なる場合はアライメントが原因です。
確認方法
集計レポートを手動で確認するには、受信した XML を dig と組み合わせて解析します。まず rua アドレスに届いたメールから添付の .xml.gz ファイルを保存し、展開します。
gunzip report.xml.gz
XML を直接読む場合は xmllint でフォーマットできます。
xmllint --format report.xml
source_ip を逆引きして送信元を特定するには dig を使います。
dig -x 192.0.2.1
;; ANSWER SECTION:
1.2.0.192.in-addr.arpa. 3600 IN PTR mail.example.com.
定期的に大量のレポートを処理するには、dmarcian、Valimail、Postmark の DMARC Digests などのレポート解析サービスが便利です。これらのサービスは XML を可視化し、source_ip をドメイン名に変換して表示します。
外部の視点からも確認したい場合は、Labee Dev Toolbox の Mail Auth API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/mail-auth?domain=example.com"
{
"success": true,
"data": {
"spf": { "record": "v=spf1 include:_spf.google.com ~all", "exists": true },
"dkim": { "record": "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...", "exists": true, "selector": "default" },
"dmarc": {
"record": "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com",
"exists": true
},
"bimi": { "record": null, "exists": false }
},
"error": null,
"meta": { "responseTime": 123 }
}
data.dmarc.exists が true であれば rua= を含む DMARC レコードが外部から確認できる状態です。data.dmarc.record フィールドで rua= のアドレス設定も確認できます。
よくある問題
集計レポートの設定・解析で陥りやすいミスと対処法を整理します。
rua を設定していない
rua= タグがない DMARC レコードではレポートが届きません。認証が失敗していても気づけないため、必ず設定します。専用のメールアドレスを用意するか、レポート解析サービスが提供する受信アドレスを指定します。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"
外部ドメインへの rua 転送が機能しない
rua=mailto:reports@thirdparty.com のように、DMARC ポリシーを公開しているドメインと異なるドメインのアドレスに送信する場合、受信側のドメイン(thirdparty.com)が _dmarc.example.com からのレポート受け取りを許可する TXT レコードを公開している必要があります(RFC 7489 Section 7.1)。
example.com._report._dmarc.thirdparty.com. IN TXT "v=DMARC1"
このレコードがないと主要プロバイダーはレポートを送信しません。レポート解析サービスを使う場合、サービス側がこのレコードを案内しているはずです。
レポートが届かない
レポートが届かない原因として、rua= アドレスのメールボックスが存在しない、メールボックスの容量が満杯、またはメールサーバーが DMARC レポートを迷惑メールとして扱っているケースがあります。レポートは添付ファイルを含む XML メールのため、フィルタリングされることがあります。
また、送信量が少ない場合は主要プロバイダーからレポートが届かないこともあります。Google は一定件数以上のメールがある場合にのみレポートを生成します。
policy_evaluated と auth_results の結果が違う
auth_results.dkim.result が pass でも policy_evaluated.dkim が fail になる場合、DKIM アライメントが取れていない状態です。DKIM は pass したが、署名の d= タグのドメインとヘッダー From ドメインが一致しなかったことを意味します。この状態で p=quarantine に移行すると、正規メールが迷惑メールに振り分けられます。アライメントを修正してから移行します。