DMARCメール認証Web 担当者運用

DMARC レポートの disposition と alignment を読み解く

2026年5月8日ドメイン番人約 8 分で読めます

この記事でわかること

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 タグの実用ガイドを参照してください。

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 階層構造

読み解きの中核：disposition と alignment

disposition と alignment の役割の違い

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

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

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

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

<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 アライメントとはを参照してください。

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

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

<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 は次のパターンです。

<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（観察モード）か、受信側の初動緩和が効いている状態です。

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

source_ip を WHOIS で逆引き → 知らない IP / 海外 ASN なら高確率で外部攻撃者
ポリシーが p=none なら、影響範囲を確認した上で p=quarantine → p=reject への段階強化を検討（DMARC ポリシー段階強化ガイド）
自社の正規送信元（メール基盤・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 レポートツール比較で 7 製品の選び方を整理）。

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

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

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

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