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

- DMARC aggregate レポートで最も重要な 2 要素「disposition」と「alignment」の意味と読み方
- XML の `<policy_evaluated>` と `<auth_results>` を突き合わせて、なぜ pass / fail になったかを 1 通単位で判別する手順
- forensic（ruf）レポートとの違い、aggregate だけで何が分かり何が分からないか
- `disposition=none` のまま `p=reject` でも届く実装の謎を解く

## 前提：DMARC レポートには 2 種類ある

DMARC が受信側 ISP に送らせるレポートは aggregate（rua）と forensic（ruf）の 2 種類です。

| 種類 | タグ | 中身 | 国内 ISP の送信実態 |
|---|---|---|---|
| aggregate | `rua` | 24 時間分の認証結果集計（XML） | Gmail / Yahoo Japan / Microsoft 等が送信 |
| forensic | `ruf` | 個別失敗メッセージのコピー | 国内大手はほぼ送らない |

本記事は **aggregate（rua）レポート** の読み方に絞ります。forensic（ruf）の現実については [DMARC ruf と fo タグの実用ガイド](/blog/dmarc-ruf-forensic-report) を参照してください。

## aggregate レポートの 4 階層を押さえる

XML の構造は次の 4 階層で、深いほど 1 通の認証結果に近づきます。

```
<feedback>
  ├ <report_metadata>      … レポーター（Google等）と期間
  ├ <policy_published>     … あなたの DNS に書かれた DMARC ポリシー
  └ <record>(複数)         … 送信元 IP × 認証結果のグループ
        ├ <row>            … カウント・disposition
        ├ <identifiers>    … From ヘッダのドメイン
        └ <auth_results>   … SPF / DKIM の生の結果
```

判定ロジックを追うときは、`<record>` の中の `<row><policy_evaluated>` と `<auth_results>` を **横並びで突き合わせる** のがコツです。

![DMARC aggregate レポートの XML 4 階層構造](/blog/dmarc-aggregate-disposition-reading/xml-structure.svg)

## 読み解きの中核：disposition と alignment

![disposition と alignment の役割の違い](/blog/dmarc-aggregate-disposition-reading/disposition-vs-alignment.svg)

### disposition は「受信側がどうしたか」

`<row><policy_evaluated><disposition>` は受信側が実際に取った処置で、3 つの値があります。

- **`none`**: 通常配信（Inbox or Spam フォルダへ）
- **`quarantine`**: 隔離（Spam フォルダ送り）
- **`reject`**: 拒否（受信せず破棄）

ここで重要なのは、disposition は **DNS で宣言した `p=` ポリシーと一致するとは限らない** ことです。受信側が独自判断で緩める（reject 宣言でも none で配信）ケースが頻繁にあります。

```xml
<policy_published>
  <p>reject</p>
</policy_published>
<record>
  <row>
    <policy_evaluated>
      <disposition>none</disposition>   ← reject 宣言なのに none
    </policy_evaluated>
  </row>
</record>
```

理由は受信側の「初動緩和」設計です。reject 宣言が初日から厳格適用されると正規メールまで弾く事故が起きるため、Gmail などは **学習期間中は disposition=none に落として送信ドメイン側のレポート観察に委ねる** 動きを取ります。これは仕様違反ではなく、運用上の安全弁です。

### alignment は「DMARC のロジック上どう判定されたか」

`<row><policy_evaluated><dkim>` と `<spf>` は、DMARC の合否ロジック上の判定結果（`pass` / `fail`）です。disposition と違い、これは受信側の独自判断ではなく **RFC 7489 で定義された純粋な計算結果** です。

- どちらか片方でも `pass` なら DMARC 合格
- 両方 `fail` なら DMARC 不合格 → DNS の `p=` に従って disposition が決まる（はず）

ここで「**alignment**」が出てきます。alignment は「認証通過したドメインと From ヘッダのドメインが揃っているか」のチェックで、SPF / DKIM それぞれに独立に存在します。詳しい概念は [DMARC アライメントとは](/blog/dmarc-alignment-explained) を参照してください。

## 実例 XML を 1 件だけ精読する

次の record は「`p=reject` 宣言のドメインに、社内システムからの正規メールが届いたケース」です。

```xml
<record>
  <row>
    <source_ip>203.0.113.45</source_ip>
    <count>32</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.co.jp</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.co.jp</domain>
      <selector>default</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>marketing.example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>
```

ここから読めることを 1 行ずつ整理します。

- **送信元 IP**: 203.0.113.45 から 32 通送られた
- **生の認証結果（auth_results）**: SPF も DKIM も `pass`（=技術的には認証成功）
- **DMARC 評価（policy_evaluated）**: DKIM は `pass`、SPF は `fail`
- **DKIM が pass の理由**: `auth_results.dkim.domain` = `example.co.jp` で、`identifiers.header_from` と一致 → **alignment 成立** で DMARC 上も pass
- **SPF が fail の理由**: `auth_results.spf.domain` = `marketing.example.com`（SPF は通っているが From と異なるドメイン） → **alignment 不成立** で DMARC 上は fail
- **disposition=none**: DKIM が pass だったので DMARC 全体としては合格 → 通常配信

つまりこの record は、**SPF はリレー用のサブドメインで通り、DKIM 署名がちゃんと From のドメインで貼られているおかげで DMARC を救っている**、健全な正規メールの典型例です。

## 危険な record の見分け方

逆に、要警戒の record は次のパターンです。

```xml
<row>
  <count>120</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.co.jp</header_from>
</identifiers>
<auth_results>
  <spf>
    <domain>example.co.jp</domain>
    <result>fail</result>
  </spf>
</auth_results>
```

DKIM 署名なし、SPF も fail、From は自社ドメイン。**第三者が自社ドメインを From に偽装して送っているなりすまし**の特徴と完全に一致します。disposition=none で配信されているのは、ポリシーが `p=none`（観察モード）か、受信側の初動緩和が効いている状態です。

ここから取るべきアクションは:

1. `source_ip` を WHOIS で逆引き → 知らない IP / 海外 ASN なら高確率で外部攻撃者
2. ポリシーが `p=none` なら、影響範囲を確認した上で `p=quarantine` → `p=reject` への段階強化を検討（[DMARC ポリシー段階強化ガイド](/blog/dmarc-policy-tightening)）
3. 自社の正規送信元（メール基盤・SaaS）の IP リストと突き合わせて、本当に未許可送信元かを確認

## よくある誤読 3 パターン

### 1. 「disposition=none だから安全」と思ってしまう

disposition は配信実態の記録であり、**評価結果ではない**。1 つ手前の `<dkim>` `<spf>` を見て初めて DMARC の判定が分かります。

### 2. auth_results.SPF=pass だけ見て DMARC pass と勘違い

生の SPF pass と DMARC 上の SPF pass は別物です。alignment が崩れていれば DMARC 上は fail。**`<policy_evaluated>` の値こそが DMARC 評価**です。

### 3. count を「人数」と誤解する

`count` は同一 source_ip × 認証結果の **集約された通数**。1 IP から 1,000 通送られていれば count=1000 で 1 record にまとまります。受信者数ではありません。

## ツールに任せて良い領域・人が判断すべき領域

XML を毎日生で読むのは現実的ではないため、可視化ツールを併用するのが普通です（[DMARC レポートツール比較](/blog/dmarc-report-tool-comparison) で 7 製品の選び方を整理）。

ただし、ツールが出すサマリでは「**ポリシーをいつ厳格化するか**」「**未知の送信元 IP が正規かなりすましか**」といった**判断**は自動化されません。disposition と alignment の意味を理解した上で、月 1 回程度はサマリの裏付けに XML レコードを 2〜3 件覗く運用が、長期的にはトラブル予防に効きます。

## 自社ドメインの DMARC 状況を確認する

[無料のドメイン診断](/diagnose) で、自社ドメインの DMARC ポリシー（p / pct / rua / ruf / aspf / adkim）と SPF / DKIM の現状を 30 秒で確認できます。レポートを読み解く前に、まず自社の DNS 側がレポートを受け取れる状態になっているかを点検しましょう。

DMARC 周りの設計や、レポートに正体不明の送信元が大量に出ているといった具体的な相談は [お問い合わせ](/contact) からお気軽にご連絡ください。