DMARC集約レポート（RUA・RUF）の読み方と解説イメージ画像

DMARCレポートの読み方

DMARC集約レポートの構造と活用法


著者: Maitham Al Lawati
翻訳: 竹洞 陽一郎

この記事はPowerDMARCのブログ記事 How to Read DMARC Reports: A Complete Guide to RUA & RUF の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

主なポイント

  1. DMARCレポートを確認することで、誰が自社ドメインを使用してメールを送信しているのかを把握できます。
  2. 集約レポート（RUA）は、通常1日ごとに送信されるXML形式のサマリであり、自社ドメインから送信されたとするメールの送信元IPアドレスや、それぞれのSPF・DKIM認証結果が記載されています。
  3. レポートを読むことは最初のステップにすぎません。重要なのは、その内容に基づいて適切に対応することです。
    認証に失敗している正当な送信元の設定を修正し、不明な送信元を監視しながら、認証成功率の推移を確認してください。
  4. また、DMARCレポートは、強制適用ポリシーへ移行するタイミングを判断するためにも活用できます。
    把握しているすべての正当な送信元が認証に成功し、成功率が95%以上の状態を安定して維持できたら、p=noneからp=quarantineへ、その後p=rejectへ移行することを検討できます。
  5. PowerDMARCのDMARCレポート分析ツールを使用すると、こうした作業の多くを自動化できます。
    生のXMLデータを分かりやすいダッシュボードへ変換し、IPアドレスではなく送信元の名称で確認できるほか、過去のデータを一元管理できるため、XMLを手作業で解析することなく傾向を把握し、対応につなげられます。

DMARCレコードを公開し、rua=にレポート受信用のメールアドレスを設定すると、圧縮されたXMLファイル形式のレポートが受信トレイへ届くようになります。
しかし、これらのレポートはそのままでは読みにくく、見覚えのない企業や組織から送られてきたり、内容を見ても何をすればよいのか分かりにくかったりします。
このガイドでは、そうした疑問を解消します。

DMARCレポートに含まれる情報、XMLをフィールドごとに読み解く方法、RUAとRUFの違い、そして最も重要な、送信元が認証に成功した場合、失敗した場合、または予期せず表示された場合に取るべき対応について説明します。
初めてDMARCレポートを確認する場合は、上から順番に読み進めてください。

このブログでは、すでにDMARCレコードが設定されていることを前提としています。
まだ設定していない場合は、まずDMARCレコードを公開し、その後、生成されたレポートを確認してください。

DMARCレポートとは？

DMARCレポートは、受信メールサーバからrua=タグに指定したアドレスへ送信される、メール認証状況のサマリです。
各レポートには、報告期間中に自社ドメインから送信されたとするメールの送信元IPアドレスや、各送信元についてSPFおよびDKIMが成功したか失敗したかなどの情報が記載されています。

DMARCレポートは、ドメインのメール認証状況を監視するための重要な手段です。
正当な送信元だけでなく、不正な送信元も含め、どの送信元が自社ドメインを使用してメールを送信しているのかを可視化できます。

誰がDMARCレポートを送信するのか？

rua=を設定している場合、自社ドメインから送信されたメールを受信したメールサーバからDMARCレポートが送られてきます。
Google、Microsoft、Yahooなどの大手メールサービス提供者もこれに含まれます。

そのほかにも、受信者が利用している小規模なメールサービス提供者、企業のメールゲートウェイ、大学のメールシステム、海外のプロバイダなどからレポートが届く場合があります。
見覚えのない組織からレポートが届くことは、必ずしも異常ではありません。
これは単に、その組織のメールサーバが、自社ドメインから送信されたように見えるメールを処理したことを意味する場合があります。

ただし、自社で管理していないIPアドレスから大量のメールが報告されている場合は、スプーフィングの兆候である可能性があるため、調査が必要です。
1日に受信するレポート数は、自社のメールを受信したメールサービス提供者や受信メールサーバの数によって異なります。
少数の受信者にのみメールを送信している場合は、1日あたり2～3件程度しか届かないこともあります。

一方、大量送信者では、数十件から数百件のレポートを受信する場合があります。
レポート数が多いからといって、それだけで問題があるわけではありません。
レポート数は主に受信環境の分布を反映しており、ドメインの健全性そのものを示す指標ではありません。

レポートはいつ届くのか？

多くのプロバイダは、約24時間ごとに1件の集約レポートを送信します。
通常、レポートは対象となるメール送信から24～48時間以内に届きます。
各報告組織から個別にレポートが送信されるため、例えばGoogleとMicrosoftの両方でメールが受信されている場合、同じ日の送信について複数のレポートを受け取ることになります。

レポートは、.zipまたは.gz形式で圧縮された添付ファイルとして、自動送信アドレスから届くことがあります。
メールクライアントによっては、こうした添付ファイルが不審なものとして扱われる場合があります。
レポートが届くはずなのに見つからない場合は、設定に問題があると判断する前に、迷惑メールフォルダやジャンクフォルダも確認してください。

DMARCレポートの種類

DMARCレポートには、大きく分けて2種類あります。
多くのドメインでは、主にRUAを確認すれば十分です。

集約レポート（RUA）
DMARC集約レポートは、特定の受信メールサーバが処理した、自社ドメインからのメールトラフィックを一定期間ごとにまとめたサマリです。
通常は圧縮されたXML形式で届き、送信元IPアドレス、メッセージ数、SPFの成功／失敗、DKIMの成功／失敗、DMARCのDisposition（受信側が行った処理）などが記載されています。
重要なのは、通常、メール本文そのものではなく、認証結果を中心としたメタデータが含まれている点です。

そのため、RUFと比べるとプライバシー上のリスクは低く、継続的な監視に適しています。
このガイドでは、主にRUAについて説明します。
失敗レポート（RUF）
DMARC失敗レポートは、従来フォレンジックレポートとも呼ばれていたもので、特定のメッセージが認証に失敗した際の情報を提供します。
失敗レポートには、メッセージヘッダや、場合によっては本文の一部など、個人情報や機密情報を含む可能性のあるデータが含まれることがあります。

そのため、Google、Microsoft、Yahooなどの主要なメールサービス提供者では、RUFを送信していない場合があります。
ruf=を有効にする場合は、こうしたデータを安全かつ適切に処理できる仕組みが整っていることを確認してください。
また、ruf=を設定していても、すべてのメールサービス提供者から失敗レポートが届くわけではない点に注意が必要です。

RUAとRUFの比較

機能 RUA（集約レポート） RUF（失敗レポート）
含まれる内容 送信元ごとのメール認証結果のサマリ 個別の認証失敗に関する情報
配信頻度 通常は約24時間ごと 認証失敗ごとに送信される場合があります
主要プロバイダからの送信 広く対応されています 対応していないプロバイダも多くあります
形式 圧縮XML（.zip/.gz） ARF形式など
プライバシーリスク 比較的低い 個人情報などを含む可能性があります
多くのドメインに推奨されるか はい 適切な処理体制がある場合に限ります

DMARCレポートの中身

DMARC集約レポートは、主に3つのセクションから構成されるXMLファイルです。

1つ目はレポートメタデータで、誰がいつレポートを生成したのかを示します。
2つ目は公開済みポリシーで、受信側が確認したDMARCレコードの内容を示します。
3つ目はレコードで、送信元ごとの認証結果が記録されています。

この3つの構成を理解すれば、DMARCレポートの全体像を把握しやすくなります。

セクション1：レポートメタデータ

このブロックでは、誰がレポートを送信したのか、どの期間を対象としているのかを確認できます。

org_name
Google.comなど、レポートを生成した組織です。
email
レポート送信元の連絡先メールアドレスです。
report_id
レポート固有の識別子です。
date_range（begin+end）
報告期間をエポックタイムスタンプで示します。
必要に応じて、一般的な日時形式へ変換して確認します。

レポートが想定している期間を対象としているか確認してください。

セクション2：公開済みポリシー

ここでは、受信側がメール処理時に参照したDMARCポリシーを確認できます。

domain
ポリシーの対象となるドメインです。
adkim/aspf
DKIMおよびSPFのアライメントモードです。
p
DMARCポリシーで、none、quarantine、rejectのいずれかです。
sp
設定されている場合のサブドメインポリシーです。
pct
従来、ポリシーを適用する割合を指定するために使用されていたフィールドです。
古いレポートにはpctが表示される場合があります。

レポートに表示されているポリシーが、自分が意図して設定した内容と一致しているか確認してください。
一致しない場合は、DNSの反映状況や現在公開されているDMARCレコードを確認してください。

セクション3：レコード

各recordには、特定の送信元IPアドレスから送信されたメールの認証結果がまとめられています。
DMARCレポートを確認する際に、最も重点的に見るべき部分です。

source_ip
送信元IPアドレスです。
IPアドレスを確認し、どのサービスから送信されたものかを特定します。
count
そのIPアドレスから送信されたメッセージ数です。
policy_evaluated/disposition
受信側が行った処理です。
none、quarantine、rejectなどが表示されます。
policy_evaluated/dkimおよびpolicy_evaluated/spf
DMARCアライメントを考慮したDKIMおよびSPFの結果です。
identifiers/header_from
受信者に表示される「From:」ヘッダのドメインです。
auth_results/spf
SPF認証で使用されたドメインと結果です。
auth_results/dkim
DKIM認証で使用されたドメイン、セレクタ、結果です。

把握しているすべての正当な送信元がDMARCに成功しているか、また、不明なIPアドレスが存在しないかを確認してください。

DMARC XMLレポートの例

以下は、3つの送信元を示した、匿名化した集約レポートの例です。
1つ目は認証に成功している正当な送信元、2つ目は一部の認証に失敗している正当な送信元、3つ目は不明なIPアドレスです。
各フィールドには、内容を理解しやすいようコメントを付けています。 


<?xml version="1.0" encoding="UTF-8"?>
<feedback>

<!-- ===== セクション1：誰がいつこのレポートを送信したか ===== -->
<report_metadata>
<org_name>google.com</org_name>
<email>noreply-dmarc-support@google.com</email>
<report_id>1234567890123456789</report_id>
<date_range>
<begin>1718928000</begin>
<end>1719014400</end>
</date_range>
</report_metadata>

<!-- ===== セクション2：受信側が確認したDMARCポリシー ===== -->
<policy_published>
<domain>example.com</domain>
<adkim>r</adkim>
<aspf>r</aspf>
<p>none</p>
<sp>none</sp>
</policy_published>

<!-- ===== セクション3：送信元ごとのレコード ===== -->

<!-- レコード1：正当な送信元。SPF・DKIMともに成功しているため、基本的に対応は不要です。 -->
<record>
<row>
<source_ip>209.85.220.41</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>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain>example.com</domain>
<selector>google</selector>
<result>pass</result>
</dkim>
</auth_results>
</record>

<!-- レコード2：既知のメールサービス。SPFは成功していますが、DKIMは失敗しています。必要に応じてDKIM設定を確認します。 -->
<record>
<row>
<source_ip>198.51.100.42</source_ip>
<count>45</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>example.com</domain>
<result>pass</result>
</spf>
<dkim>
<domain>esp-vendor.example.org</domain>
<selector>s1</selector>
<result>fail</result>
</dkim>
</auth_results>
</record>

<!-- レコード3：不明な送信元。SPF・DKIMともに失敗しています。送信量や継続性を確認し、スプーフィングの可能性を調査します。 -->
<record>
<row>
<source_ip>203.0.113.17</source_ip>
<count>8</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>example.com</header_from>
</identifiers>
<auth_results>
<spf>
<domain>example.com</domain>
<result>fail</result>
</spf>
<dkim>
<domain>example.com</domain>
<selector>unknown</selector>
<result>fail</result>
</dkim>
</auth_results>
</record>

</feedback>

DMARCレポートの読み方

ステップ1：レポートを開いて解凍する
レポートは、Report Domain: yourdomain.com Submitter: google.com Report-ID: …のような件名のメールに添付されて届く場合があります。
添付ファイルを保存し、解凍してください。
zipや.gz形式であれば、一般的な解凍ツールやOSの標準機能を使用できます。

解凍後の.xmlファイルは、テキストエディタなどで開けます。
詳細に分析したい場合は、生のXMLを直接読む代わりに、DMARCレポート分析などの解析ツールを利用すると、分かりやすい形式で内容を確認できます。
ステップ2：報告組織を確認する
メタデータのorg_nameを確認し、どの組織が生成したレポートなのかを特定します。
Googleからのレポートでは主にGoogleが受信したメール、MicrosoftからのレポートではMicrosoftが受信したメールの認証状況を確認できます。
各メールサービス提供者から個別にレポートが届くため、1つのレポートだけでメール環境全体を判断しないことが重要です。
ステップ3：公開済みポリシーを確認する
p、sp、adkim、aspfが、意図した設定と一致しているか確認してください。
一致しない場合は、DNSへ変更内容がまだ反映されていないか、DMARCレコードの設定内容が変更されている可能性があります。
DMARCチェッカーを使用して、現在公開されているレコードを確認してください。
ステップ4：各レコードの送信元を確認する
各recordについて、source_ipを逆引きDNSやIP Lookupなどで調べ、どのサービスから送信されたものかを確認します。
次に、countで送信量を確認します。
見覚えのないIPアドレスから大量のメールが送信されている場合は、特に注意が必要です。

その後、Disposition、DKIM、SPFの結果を確認してください。
正当な送信元では、SPFまたはDKIMの少なくとも一方がDMARCアライメントに成功している必要があります。
把握している送信元で認証に失敗している場合は、設定を確認して修正してください。
ステップ5：各送信元を分類する
送信元は、次の3つに分類すると整理しやすくなります。
不明な送信元については、送信量や継続性を監視し、必要に応じてDMARCポリシーの強化を検討してください。

  1. 正当な送信元で認証に成功している：基本的に対応は不要です。
  2. 正当な送信元だが認証に失敗している：設定の確認と修正が必要です。
  3. 不明な送信元：スプーフィングや未把握のサービスである可能性があるため、調査が必要です。

大量のDMARCレポートを読む方法

複数のメールサービス提供者から毎日レポートが届くようになると、XMLを1件ずつ手作業で確認することは現実的ではありません。
Gmail、Outlook、Yahooなど複数のサービスを利用する受信者へメールを送信している場合、それぞれのサービスからレポートを受信する可能性があります。
送信規模が大きくなるほど、手作業での管理は難しくなります。

そのため、DMARCレポートの自動解析ツールが広く利用されています。
単発で内容を確認する場合は、PowerDMARCのDMARCレポート分析ツールなどへXMLファイルをアップロードし、分かりやすい形式へ変換して確認できます。

継続的かつ大規模に監視する場合は、専用プラットフォームを利用することで、各プロバイダから届くレポートを自動的に集約・解析できます。
PowerDMARCでは、単一ドメインだけでなく複数ドメイン環境でも、DMARCレポートを継続的に確認できます。

すべてのレポートを1か所に集約できます
受信トレイに多数のXMLファイルが届く代わりに、複数のメールサービス提供者から送られてくるレポートを1つのダッシュボードへ集約できます。
複数のドメインをまとめて確認できます
複数ドメインを管理している場合でも、ドメイン全体の状況を1つの管理画面から確認できます。
履歴データを確認できます
保存された履歴データを利用すると、認証成功率の推移を追跡できます。
また、設定変更後に認証結果が改善しているか、不審な送信元が徐々に増加していないかなども確認できます。
フィルタリングと検索ができます
すべてのレコードを手作業で確認するのではなく、特定の送信元や認証失敗だけに絞って確認できます。
新しい送信元を検知できます
新たな未承認の送信元が確認された場合に通知を受けることで、早期に調査できます。
監査向けのレポートを出力できます
コンプライアンスレビューや関係者への報告に利用できるデータを出力できます。

DMARCレポートを確認した後に行うこと

レポートを読むだけでは、ドメインを十分に保護することはできません。
重要なのは、確認した内容に基づいて適切に対応することです。

認証に失敗している正当な送信元を修正する
自社で利用しているメールサービス、CRM、ヘルプデスク、ニュースレタープラットフォームなどの正当な送信元でdkim=failまたはspf=failが表示される場合は、設定を確認してください。
SPFに問題がある場合は、送信サービスから案内されているIPアドレスやinclude:メカニズムがSPFレコードへ正しく反映されているか確認します。

その後、SPFチェッカーなどで再確認してください。
DKIMに問題がある場合は、利用しているサービスで自社ドメインを使用したDKIM署名が有効になっているか確認します。
必要な公開鍵をDNSへ設定した後、DKIMチェッカーなどで検証してください。
不明な送信元を特定して監視する
見覚えのないIPアドレスから自社ドメインを使用したメールが送信されている場合、その送信元は、社内の別部門が導入した未把握のサービス、正当な転送サービス、またはスプーフィングである可能性があります。
少量で単発の送信であれば、直ちに重大な問題とは限りません。

一方、不明なIPアドレスから大量のメールが継続的に送信されている場合は、スプーフィングの可能性が高まります。
このような場合は送信元を調査し、正当な送信元ではないことを確認したうえで、DMARCポリシーの強化を検討してください。
時間の経過とともに成功率を追跡する
DMARC成功率は、DMARC認証に成功したメールの割合を確認するための指標です。
p=noneでは認証失敗メールの配信を直接制御しませんが、強制適用へ移行する準備状況を判断するために役立ちます。
ポリシーを強化する前に、正当な送信元が安定して認証に成功していることを確認してください。

例えば、95%以上の成功率を一定期間維持できていることを、移行判断の目安の1つとして利用できます。
1日だけの結果で判断するのではなく、数週間にわたって傾向を確認することが重要です。
ポリシーを強化するタイミングを判断する
次の条件を満たしている場合は、p=quarantineへの移行を検討できます。
  • 把握している正当な送信元がDMARCに継続して成功していること。
  • 予期しない大量送信元がレポートに現れていないこと。
  • 高い認証成功率を一定期間維持できていること。
p=quarantineへ移行した後も認証状況やメール到達率に問題がないことを確認し、最終的にp=rejectへの移行を検討してください。
監視を十分に行わずに強制適用へ移行すると、正当なメールまで影響を受ける可能性があるため注意が必要です。

PowerDMARCでは、こうした分析作業を自動化できます。
認証成功率を継続的に確認し、送信元を名称で識別し、新しい未承認の送信元が確認された場合に把握しやすくなるため、生のXMLから手作業で判断する負担を軽減できます。

DMARCレポートを受信できないのはなぜですか？

rua=を設定したDMARCレコードを公開しているにもかかわらずレポートが届かない場合は、以下のような原因が考えられます。

問題1
DMARCレコードにrua=タグがありません。
rua=が設定されていない場合、集約レポートの送信先が指定されていません。

DMARCレコードへ、例えば次のような設定を追加してください。

rua=mailto:your@email.com
設定後は、DMARCチェッカーなどで公開状況を確認します。
問題2
メールアドレスが間違っている、または受信できない状態です。
入力ミス、存在しないメールアドレス、容量がいっぱいになったメールボックスなどでは、レポートを受信できません。
rua=に指定したアドレスへテストメールを送信し、正常に受信できるか確認してください。
問題3
外部レポート送信先の承認が必要です。
DMARCを設定しているドメインとは異なるドメインのアドレスをrua=へ指定している場合、外部送信先の承認設定が必要になる場合があります。

DMARCレポートサービスを利用している場合は、サービス側の案内に従って設定してください。
多くのDMARC管理プラットフォームでは、この処理を簡素化しています。
問題4
DMARCレコードを公開した直後で、DNSの変更がまだ反映されていません。
DNSの変更が反映され、レポートが届き始めるまで時間がかかる場合があります。
通常は24～48時間程度待ってから確認してください。
問題5
レポートが迷惑メールフォルダへ振り分けられています。
DMARCレポートは自動送信アドレスから届き、圧縮ファイルが添付されているため、メールフィルタによって迷惑メールとして扱われることがあります。
迷惑メールフォルダやジャンクフォルダも確認してください。
問題6
まだ報告対象となるメールが送信されていません。
DMARCレポートは、自社ドメインを使用したメールを受信側のメールサーバが処理した場合に生成されます。
DMARCレコードを公開しただけで、まだメールを送信していない場合は、報告対象となるデータが存在しないため、レポートが届かないことがあります。

RFC 9990：2026年の集約レポート標準

DMARC集約レポートについては、現在の仕様に沿ったレポート形式を理解しておくことが重要です。
既存のDMARCレポートとの互換性も考慮されているため、現在利用している解析ツールやレポート環境を継続して利用できる場合があります。
最新のDMARC仕様やレポート形式については、DMARC RFC 9989／9990／9991に関する解説を確認してください。

よくある質問

DMARCレポートとは何ですか？
DMARCレポートは、受信メールサーバからrua=タグに指定したアドレスへ送信される、メール認証状況をまとめたレポートです。
自社ドメインから送信されたとするメールの送信元IPアドレスや、それぞれのSPF・DKIM認証結果などを確認できます。

Google、Microsoft、Yahooなどのメールサービス提供者は、自社ドメインからのメールであるとするメッセージを受信すると、DMARC集約レポートを生成する場合があります。
DMARCレポートは、ドメインのメール認証状況を監視するための重要なツールです。
DMARCにおけるRUAとRUFの違いは何ですか？
RUAは、メール認証状況を送信元ごとにまとめた集約レポートです。
通常、XML形式で一定期間ごとに送信されます。

RUFは、個別の認証失敗に関する詳細情報を提供する失敗レポートです。
メールヘッダなどの情報を含む可能性があるため、プライバシー上の理由から送信していないメールサービス提供者もあります。
そのため、一般的にはRUAの方が広く利用されています。
DMARCレポートはどのくらいの頻度で送信されますか？
多くのメールサービス提供者では、約24時間ごとに集約レポートを送信します。
ただし、送信頻度やタイミングはレポートを生成する組織によって異なる場合があります。
複数のメールサービス提供者が自社メールを受信している場合は、それぞれから個別にレポートが届く可能性があります。
DMARC XMLレポートはどのように読めばよいですか？
DMARC XMLレポートは、主に3つのセクションに分かれています。
report_metadataでは、レポートを生成した組織と対象期間を確認できます。
policy_publishedでは、受信側が参照したDMARCポリシーを確認できます。

recordでは、送信元IPアドレスごとのSPF、DKIM、DMARCの結果を確認できます。
具体的な読み方については、このガイド内のXML例を参照してください。
大量のレポートを継続的に確認する場合は、生のXMLを手作業で読むのではなく、自動解析ツールを利用すると効率的です。
見覚えのない組織からDMARCレポートが届くのはなぜですか？
rua=を設定している場合、自社ドメインから送信されたとするメールを受信したさまざまなメールサーバから、DMARCレポートが届く可能性があります。
これには、GoogleやMicrosoftなどの大手サービスだけでなく、小規模なメールサービス提供者、企業のメールゲートウェイ、海外のプロバイダなども含まれます。

そのため、見覚えのない組織からDMARCレポートが届くこと自体は異常ではありません。
その組織のメールサーバが、自社ドメインから送信されたように見えるメールを処理したことを示しています。