## この記事でわかること

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

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

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

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

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

![DMARC集計レポート（rua）が届くまでの流れ](/blog/dmarc-report-reading/report-flow.svg)

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

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

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

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

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

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

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

![集計レポートXMLの主な要素](/blog/dmarc-report-reading/xml-structure.svg)

### ルート `<feedback>`

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

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

```xml
<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ポリシーです。自社で設定したレコードと食い違っていないかを確認します。

```xml
<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つです。

```xml
<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した」という意味になります。

#### 参考: 受信側ヘッダー（Authentication-Results）との対応

XMLレポートの内容は、実は受信した1通1通のメールに付与されている `Authentication-Results` ヘッダーと表裏の関係にあります。たとえば Gmail で受信したメールの「メッセージのソースを表示」を開くと、次のような行が見つかります。

```text
Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.co.jp header.s=selector1;
       spf=pass (google.com: domain of bounce@example.co.jp designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@example.co.jp;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.co.jp
```

`dkim=pass` `spf=pass` `dmarc=pass` の3つは、XMLの `<auth_results>` と `<policy_evaluated>` の値そのままです。XMLが分かりにくいうちは、まず Gmail などで受信した数通のヘッダーから「自社のメールはちゃんと pass しているか」を目視で確認し、慣れたところでXMLの集計に移ると、構造の理解が早まります。各タグの意味は[DMARCレコードのタグ一覧](/blog/dmarc-record-tags-reference)を併せて参照してください。

## 見るべき3つのポイント

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

![レポートで見るべき3つのポイント](/blog/dmarc-report-reading/check-points.svg)

### ポイント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設定の確認方法](/blog/dkim-verification)で解説しています。

### ポイント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](https://dmarc.postmarkapp.com/)の無料ツールで、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）。この手順を省くと、送信側から見て「許可されていない転送先」として扱われ、レポートが届きません。届かない時のチェック手順は[DMARC rua レポートが届かない時に確認すること](/blog/dmarc-rua-not-receiving)に整理しています。
2. **レポートが突然減った/途絶えた**: 送信元プロバイダ側のポリシー変更や、メーリングリスト・SaaSからの中継で認証結果が壊れるケースがあります。`p=none`のままで月ごとの受信件数が極端に変動している場合は、DMARCレコード自体の変更履歴と合わせて確認してください。
3. **迷わず`p=reject`に上げてしまう**: レポートの眺めがよくなってきたからといって、十分な観察期間なしに`p=reject`へ上げると、転送メールや社員個人が使うサードパーティツール経由の送信が一括で拒否される事故が起きます。最低2〜3か月のモニタリング、正規送信元の`pass`率99%以上を目安に段階強化してください。DMARC義務化の背景と全体の進め方は[DMARC義務化はいつから？対応手順](/blog/dmarc-mandatory)に整理しています。

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

レポートの確認や段階強化の判断を毎月続けるのが難しい場合は、[DMARC運用代行の選び方](/blog/dmarc-uneidaikou-erabikata)で外注の判断軸や料金体系も確認できます。

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

要点をおさらいします。

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

レポート受信が必要かどうかの判定（1 日 5,000 通の閾値）は [DMARC 1 日 5000 通の対象判定](/blog/dmarc-5000-mails-check)、Microsoft 側の最新動向は [Microsoft DMARC 必須化 2025](/blog/microsoft-dmarc-mandatory-2025) を参照してください。

自社ドメインにDMARCが設定されているか、`rua`送信先は正しく動作しているかは、[無料のドメイン診断ツール](/diagnose)で数秒で確認できます。レポートの可視化ツール選定で迷う場合は[DMARC ツール おすすめ 7 選比較【無料 / 日本語対応】](/blog/dmarc-report-tool-comparison)も併せてどうぞ。毎日届くXMLの確認が負担になっている、どのIPが自社のものか特定できない、ポリシー強化の判断に不安があるといった場合は、[お問い合わせフォーム](/contact)から状況をお知らせください。レポートを事前にご確認いただきながら、次の一手を一緒に整理します。

SSL 証明書や Web セキュリティヘッダ、サブドメイン棚卸しの単発チェックも合わせて [無料ツール一覧](/tools) にまとめています。