ドメイン番人
DMARCメール認証中小企業

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

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

この記事でわかること

  • DMARC集計レポート（rua）と失敗レポート（ruf）の違い
  • XMLレポートの主要な要素（record / row / auth_results など）の読み方
  • 中小企業が毎週チェックすべき3つのポイントと、無料で使える可視化ツール

DMARC（ディーマーク）をp=noneで設定すると、翌日から rua で指定したアドレスにXMLの集計レポートが届き始めます。Google、Yahoo、Microsoftなど主要な受信プロバイダから1日1通ずつ、.xml または .xml.gz 形式の添付ファイルで送られてきます。

最初に受け取った多くの方が、「XMLを開いたけれど意味不明な羅列で、何を読み取ればいいか分からない」という状態になります。これはXMLが機械処理を前提とした形式で、人間が直接読むことは想定されていないためです。本記事では、中小企業の担当者が正規のメール配信を壊さずにポリシーを強化するために、レポートのどこをどう見ればよいかを整理します。DMARCそのものの概念や設定手順は、先にDMARCとは？中小企業が今すぐ対応すべき理由とDMARC設定方法を徹底解説をご参照ください。

DMARCレポートには2種類ある（rua と ruf）

DMARCの仕様（RFC 7489）は2種類のレポートを定めていますが、実務で扱うのはほぼ rua（集計レポート）のみです。

DMARC集計レポート（rua）が届くまでの流れ

集計レポート（rua: aggregate report）

24時間分のメール配信結果を送信元IP・認証結果ごとに集計したXMLです。各受信プロバイダが1日1回を目安に送信してきます。通数や認証の成否といった統計データのみで、個別メールの本文や件名は含まれません。プライバシー上の問題が起きにくく、Gmail・Outlook・Yahooなど主要プロバイダが広くサポートしているため、通常の運用はこのレポートを前提に進めます。

失敗レポート（ruf: failure report）

認証に失敗した個別メールのサンプルが、ほぼリアルタイムで送られてくる形式です。件名や本文の一部が含まれるため機微情報の取り扱いが必要で、GmailやMicrosoftなど多くの主要プロバイダは現在ruf送信を行っていません。そのため中小企業の実務では、まずはruaのみを監視し、rufは特段の調査が必要なケースに限って検討するのが現実的です。

本記事は以降、rua（集計レポート）の読み方を扱います。

集計レポートXMLの主要な要素

XMLは入れ子構造になっています。構造を把握すれば、どこを見るべきかが一気にわかりやすくなります。

集計レポートXMLの主な要素

ルート <feedback>

レポート全体のルート要素です。直下に <report_metadata>、<policy_published>、<record>（複数可）が並びます。

<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>1729123200</begin>
    <end>1729209600</end>
  </date_range>
</report_metadata>
  • org_name: レポート送信元（この場合はGoogle）
  • report_id: 送信側が発行する一意のID
  • date_range: 集計対象期間（Unix時刻で記載）

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

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

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

<record>｜本題のデータ（送信元IPごとに1件）

1通のレポートには、送信元IPと認証結果の組み合わせごとに<record>が並びます。中身は <row>（通数や適用結果）、<identifiers>（差出人ドメイン）、<auth_results>（SPFとDKIMの検証結果）の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><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した」という意味になります。

見るべき3つのポイント

すべての要素を理解する必要はありません。実務で最初にチェックすべきは次の3つです。

レポートで見るべき3つのポイント

ポイント1: 知らない送信元IPが混ざっていないか

<source_ip> を順に眺め、「自社で把握しているメール送信元だけか」を確認します。想定外のIPが出てきた場合、次のいずれかが疑われます。

  • 部署が個別に契約したSaaS（勤怠ツール、請求書サービス、MAツールなど）
  • 退職者が残したメール転送設定
  • 自社ドメインを騙ったなりすまし送信

IPの逆引き（dig -x <IP>）やWHOIS検索で、どの事業者が使っているIPかを特定できます。正規の送信元ならSPFやDKIMに追加し、不明なものは社内調査の対象にします。

ポイント2: SPF/DKIMのpass状況に偏りがないか

<auth_results> の結果を見ます。正規の送信元であれば、最低どちらか片方が pass しているのが正常です。両方とも fail の場合は、SPFのinclude設定漏れや、DKIMのセレクタ名の取り違えが典型的な原因です。

特に注意したいのは、<policy_evaluated>（DMARCとしての判定）と <auth_results>（SPF/DKIM単体の結果）が食い違うケースです。SPFとDKIMがpassしていても、Fromヘッダーのドメインと一致していないとDMARCはfailになります（アラインメントの失敗）。この場合はSPF/DKIMの検証ドメインをFromと揃える設定変更が必要で、詳細はDKIM設定の確認方法で解説しています。

ポイント3: disposition に quarantine や reject が混じっていないか

<disposition> は受信側がそのメールに対して実際に行った処理です。

  • none: 通常どおり配信
  • quarantine: 迷惑メールフォルダへ振り分け
  • reject: 受信拒否

ポリシーをp=noneにしている段階では、ほぼ全件がnoneになります。それでもquarantineやrejectが混ざる場合は、受信側がスパム判定や独自ルールを適用した可能性があります。正規メールが混じっていないか必ず差出人を特定してください。将来p=quarantine p=rejectと強化していくときは、正規メールのSPF/DKIM通過率が99%以上になってから進めるのが安全です。

無料ツールでの可視化と運用上の注意

XMLをそのまま読むのは現実的でないため、可視化ツールに流し込んで傾向を把握します。中小企業の初期運用では、以下のいずれかで十分です。

Dmarcian 無料プラン

DMARC仕様策定に関わったメンバーが創業した老舗サービスで、無料プランでも複数ドメインの集計や送信元の傾向把握ができます（プランの制限・仕様は変更される場合があるため、最新情報は公式サイトでご確認ください）。

Postmark DMARC Monitor

Postmarkの無料ツールで、rua送信先アドレスを発行してもらい、週次で人間が読める形のサマリーメールを受け取る運用に向きます。小規模運用で「まず状態を掴む」用途には相性が良い選択肢です。

オープンソース: parsedmarc

サーバーを自社で持つ場合は、parsedmarcというPython製のオープンソースがあります。IMAPで受信したレポートを集計し、Elasticsearchに投入してKibanaで可視化する構成が標準的です。社内に技術担当がいる企業向けの選択肢です。

つまずきやすい3つのポイント

  1. rua先にメールが届かない: rua=mailto:dmarc@other-domain.example のように自社ドメイン以外を指定する場合、受信側ドメインに _report._dmarc.<送信元ドメイン> のDNSレコードを設定する必要があります（RFC 7489 Section 7.1、External Destination Verification）。この手順を省くと、送信側から見て「許可されていない転送先」として扱われ、レポートが届きません。
  2. レポートが突然減った/途絶えた: 送信元プロバイダ側のポリシー変更や、メーリングリスト・SaaSからの中継で認証結果が壊れるケースがあります。p=noneのままで月ごとの受信件数が極端に変動している場合は、DMARCレコード自体の変更履歴と合わせて確認してください。
  3. 迷わずp=rejectに上げてしまう: レポートの眺めがよくなってきたからといって、十分な観察期間なしにp=rejectへ上げると、転送メールや社員個人が使うサードパーティツール経由の送信が一括で拒否される事故が起きます。最低2〜3か月のモニタリング、正規送信元のpass率99%以上を目安に段階強化してください。DMARC義務化の背景と全体の進め方はDMARC義務化はいつから？対応手順に整理しています。

またrua送信先アドレスを変更するとそれまでの集計データが切れるため、乗り換え時は並行運用期間を設け、既存の履歴も保管しておくのが安全です。

まずは自社のレポートを整理しませんか

要点をおさらいします。

  • DMARCレポートはrua（集計）を中心に監視する。ruf（失敗）は主要プロバイダが送らないため実務では補助的
  • XMLは report_metadata → policy_published → record の入れ子構造。実戦は record の中の送信元IP・認証結果・disposition を見る
  • 最初にチェックするのは「知らない送信元IP」「SPF/DKIMの通過率」「disposition の分布」の3点
  • 可視化ツール（Dmarcian無料プラン、Postmark、parsedmarcなど）を使えばXMLを直読みする必要はない

自社ドメインにDMARCが設定されているか、rua送信先は正しく動作しているかは、無料のドメイン診断ツールで数秒で確認できます。毎日届くXMLの確認が負担になっている、どのIPが自社のものか特定できない、ポリシー強化の判断に不安があるといった場合は、お問い合わせフォームから状況をお知らせください。レポートを事前にご確認いただきながら、次の一手を一緒に整理します。

関連記事

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

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