ドメイン番人
DMARCメール認証レポート解析

DMARC Aggregate レポート (RUA) の読み方

ドメイン番人約 9 分で読めます
目次

この記事でわかること

  • DMARC 集計レポート (RUA) の XML が持つ 3 階層構造と、各要素のビジネス上の意味
  • <record> タグから読み取るべき 4 つの判断軸
  • 実例 XML を 1 件ずつ追って「自社にとって何を意味するか」を解釈する方法

なぜ「自分で XML を読む」スキルが必要なのか

DMARC（ディーマーク）の集計レポートは、ほとんどの場合 SaaS ツールに食わせて可視化します。それでも一度は自分の目で XML 原本を読んでおく価値があります。ツールが出すアラートが「本当の異常なのか、誤検知なのか」を判断するには、生データの構造を理解している必要があるためです。

DMARC レポート全般の概論や、SaaS ツールを使う前提での読み方は DMARC レポートの見方 に整理しています。本記事はそこから一歩踏み込み、集計レポート (RUA) の XML を要素ごとに分解して、各タグが自社にとって何を意味するかを解説します。レポートを毎日 SaaS で見るのが負担、もしくはツール選びに迷っている方は DMARC 解析ツールの選び方 と DMARC ツール おすすめ 7 選比較 を併読してください。

XML は 3 階層の入れ子構造

集計レポートの XML は、大まかに 3 階層で構成されています。この骨格を頭に入れておくと、長い XML を見ても迷子になりません。

Aggregate レポート XML の 3 階層構造

ルートは <feedback>、その下に「メタ情報 (<report_metadata>)」「適用ポリシー (<policy_published>)」「実データ (<record>)」が並びます。<record> は送信元 IP と認証結果の組み合わせごとに複数並ぶため、1 通のレポートに数件〜数十件入っているのが普通です。

<report_metadata>｜誰がいつ送ってきたか

最初に来るブロックです。レポートの送信元と集計期間を示します。

<report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <report_id>1234567890123456789</report_id>
  <date_range>
    <begin>1747353600</begin>
    <end>1747440000</end>
  </date_range>
</report_metadata>
  • org_name: レポートを送ってきた受信側プロバイダ名（この例では Google）
  • report_id: 送信側が振る一意のレポート ID。問い合わせ時はこの値を伝える
  • date_range: 集計対象期間（Unix 時刻）。date -r 1747353600 などでローカル時刻に変換できる

ビジネス上は 「どの受信プロバイダから、いつの分のデータが届いているか」 を把握するための情報です。Gmail からは毎日届くのに Microsoft から週次でしか届かない、といった偏りもここで気付けます。

<policy_published>｜受信側が認識しているポリシー

受信側がレポート生成時点で DNS から取得していた DMARC ポリシーです。自社で設定したレコードと食い違っていないかをここで確認します。

<policy_published>
  <domain>example.co.jp</domain>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <p>none</p>
  <sp>none</sp>
  <pct>100</pct>
</policy_published>

主要タグの意味は次の通りです。

  • p: 親ドメインのポリシー（none / quarantine / reject）
  • sp: サブドメインのポリシー
  • pct: ポリシーを適用する割合（0〜100）。段階的強化のテスト時に使う
  • adkim / aspf: アラインメントモード（r=relaxed / s=strict）

自社で設定した値と異なっていれば、DNS 伝播の遅延か、レコードの記述ミスが疑われます。ポリシーを p=quarantine に上げたつもりが p=none のまま届いているなら、変更が反映されていない、という気付きにつながります。ポリシー強化の判断手順は DMARC ポリシー強化の進め方 を参照してください。

<record>｜本題のデータ

レポートの中核です。送信元 IP と認証結果の組み合わせごとに 1 件並びます。中身は 3 つのサブ要素から成ります。

<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.co.jp</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.co.jp</domain>
      <selector>selector1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.co.jp</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

このレコードは「203.0.113.45 から 42 通が example.co.jp の From で送信され、SPF も DKIM も pass し、DMARC 判定も pass、配信処理は通常配信」という意味です。

<row>

送信元 IP、通数 (count)、そして DMARC として最終的にどう判定されたか (policy_evaluated) が入ります。disposition は受信側が実際に行った処理で、none = 通常配信、quarantine = 迷惑メールフォルダ振り分け、reject = 受信拒否です。

<identifiers>

メールの From ヘッダーに書かれていたドメインです。SPF / DKIM の検証ドメインとこの値が一致しないと DMARC は fail します（アラインメントの不一致）。SaaS 経由のメールが fail する典型原因はここです。

<auth_results>

SPF と DKIM の 単体での 検証結果です。policy_evaluated 内の SPF/DKIM が「DMARC として通ったか（アラインメント込み）」を表すのに対し、こちらは「SPF/DKIM 単体としては通ったか」を表します。両者が食い違うときは、アラインメント不一致が起きているサインです。

<record> から読み取る 4 つの判断軸

実務では <record> を 1 件ずつ眺めながら、次の 4 軸でメールの健康状態を判断します。

record タグから読み取る 4 つの判断軸

軸 1: source_ip は自社の送信元か

source_ip をリストアップし、自社が把握しているメール送信元（メールサーバ、MA ツール、勤怠 SaaS、請求書サービス等）と照合します。知らない IP が混ざっていれば、部署が個別に契約した SaaS、退職者の転送設定、なりすまし送信のいずれかが疑われます。dig -x <IP> や WHOIS で事業者を特定できます。

軸 2: policy_evaluated/disposition の分布

p=none 運用中はほぼ全件 none になります。それでも quarantine や reject が混ざる場合、受信側のスパム判定や独自ルールが効いた可能性があります。正規メールが含まれていないか必ず差出人を特定してください。

軸 3: auth_results の SPF / DKIM

正規送信元であれば、最低どちらか片方は pass しているのが正常です。両方 fail なら SPF の include 設定漏れか、DKIM セレクタの取り違えが典型原因です。DKIM 確認の具体手順は DKIM 設定の確認方法 を参照してください。

軸 4: header_from と auth_results ドメインの一致

SPF / DKIM が単体 pass しているのに policy_evaluated/dkim や policy_evaluated/spf が fail になっているレコードは、アラインメント不一致です。header_from が example.co.jp なのに、SPF の検証ドメインが SaaS の独自ドメイン (bounce.saas-vendor.com 等) になっているケースが典型です。SaaS 側で SPF / DKIM のドメインを自社ドメインに揃える設定（BYODKIM など）が必要になります。

レポート量が増えてきたら

XML を手で読めるのは、1 日数件〜十数件の規模までです。日次で数十〜数百件に増えてきたら、SaaS ツールやセルフホストの解析基盤に移行します。自社サーバで自動集計したい場合は parsedmarc セルフホスト構築手順 に IMAP 受信 → Elasticsearch 投入 → Kibana 可視化の手順をまとめています。SaaS で済ませたい場合は DMARC 解析ツールの選び方 と DMARC ツール おすすめ 7 選比較 でツール候補を絞れます。

よくある質問

date_range の Unix 時刻をすばやく変換するには

macOS なら date -r 1747353600、Linux なら date -d @1747353600 で人間が読める日時に変換できます。Web 上の Unix Timestamp Converter でも問題ありません。

policy_evaluated と auth_results のどちらを信じるべきですか

両方です。auth_results は「SPF / DKIM 単体としての結果」、policy_evaluated は「アラインメントを含めた DMARC としての判定」です。両者が食い違うレコードこそ、自社設定の見直しが必要なサインなので、必ず両方を見比べてください。

<record> が 1 つも入っていないレポートが届きました

該当ドメイン宛のメールがその期間にゼロ通だった、もしくは受信側が認証検査をスキップした可能性があります。連続して数日続く場合は、レポート送信側のポリシー変更や、自社の DMARC レコードの構文エラーで集計対象から外れていないかを確認してください。

まとめ

  • 集計レポート XML は <feedback> → <report_metadata> / <policy_published> / <record> の 3 階層構造
  • 実務では <record> の中身を「送信元 IP」「disposition」「SPF/DKIM 単体結果」「アラインメント」の 4 軸で読む
  • 手読みは日次 10 件規模が限界。それ以上は SaaS かセルフホストの解析基盤に切り替える

自社レポートの読み解きで詰まったらご相談ください

自社ドメインに DMARC が正しく設定されているか、レポートが届いているかは 無料のドメイン診断ツール で数秒で確認できます。XML を見ても自社の送信元か判断がつかない、アラインメント不一致の解消方法がわからないといった場合は、お問い合わせフォーム から状況をお知らせください。直近のレポート例を一緒に読み解きながら、次の一手を整理いたします。

関連記事

次の一歩は無料診断から。

無料診断を試す →相談したい方はこちらから