DMARC.

Domain-based Message Authentication, Reporting and Conformance (DMARC) は RFC 7489 で規定され、SPF (RFC 7208) と DKIM (RFC 6376) の上に、可視の From: ドメインと SPF または DKIM が認証したドメインとの間の識別子アライメントを要求します。これにより、この 2 つのプロトコルが残す隙間が塞がれます。SPF と DKIM はそれぞれ 1 つのドメインを検証しますが、いずれもそれが受信者が実際に目にするドメインであることを保証しません。ドメイン所有者は _dmarc.<domain> に TXT レコードを公開し、ポリシー (p=none、quarantine、reject)、サブドメインの扱い (sp=)、アライメントモード (aspf/adkim、緩和または厳格)、展開の割合 (pct=)、レポート URI (rua、ruf) を記述します。

展開と適用

安全な展開手順はまず p=none から始めます。集計 XML レポート (RFC 7489) が、見落とされたマーケティングやチケット販売の基盤も含め、すべての正規送信元を明らかにするため、quarantine、そして reject へ厳格化する前にそれらを認証できます。この手順を飛ばすと、正規のメールが宛先不明で消えてしまいます。

DMARC は BIMI の基盤となり(検証済みのブランドロゴは p=quarantine/reject のときにのみ表示されます)、Google と Yahoo の大量送信者ルールが February 2024 に発効したことで実質的な必須要件となりました。このルールは、Gmail 宛てに 1 日あたり ~5,000 通以上を送信する送信者に対し、アライメントの取れた SPF または DKIM を通過すること、少なくとも p=none を公開すること、ワンクリック配信停止 (one-click unsubscribe) を提供することを求めます。2026 年に公開された DMARCbis の改訂版は RFC 7489 を廃止し、v=DMARC1 レコードを引き続き有効に保ちつつ、組織ドメインを見つけるために Public Suffix List の参照を DNS の「Tree Walk」に置き換えます。

flowchart TD
  A[受信メッセージ] --> B{SPF 合格?}
  A --> C{DKIM 合格?}
  B --> D{From が SPF<br/>ドメインと整合?}
  C --> E{From が DKIM<br/>ドメインと整合?}
  D --> F{いずれかの検査が<br/>合格し整合?}
  E --> F
  F -->|はい| G[DMARC 合格 - 配信]
  F -->|いいえ| H[p= ポリシーを適用]
  H --> I[none: 監視]
  H --> J[quarantine: 迷惑メールフォルダ]
  H --> K[reject: 拒否]
  G & H --> L[rua 集計レポートを所有者に送信]