2026年10月8日にRFC 7489の本文を再確認した。DMARCはFromドメインとSPF/DKIMの認証結果の整合を受信者が評価し、DNSでポリシーを公開し、集計・失敗レポートを受け取る仕組みである。正規ドメインのなりすましを減らす材料だが、似たドメイン、表示名攻撃、受信者の判定、メール本文の詐欺、配送保証を解決しない。p=rejectへの変更は正当な送信経路を観測して段階的に行う。
30秒で要点
DMARCはメール本文の安全性を判定する仕組みではなく、Fromに見えるAuthor Domainの利用を、Domain Ownerが認めた送信元として検証し、失敗時の希望とレポート先を示す仕組みです。認可、受信側の判断、送信元の可視化、内容の安全性を別の問いに置きます。
- RFC 9989は2026年5月発行のStandards Track文書で、RFC 7489とRFC 9091を置き換える
- DMARC passはAuthor Domainの利用が認可されたことを示すだけで、内容の安全性や受信箱への配送を保証しない
- 受信側はDomain Ownerの希望する取り扱いを尊重してもよく、必ず従う義務はない
- 集約レポートは、なりすましだけでなく自社の認証設定の穴を見つける材料になる
1. 2026年10月7日に確認した仕様
RFC 9989は、DMARCを説明する2026年5月発行のInternet Standards Track文書です。ページの冒頭にはRFC 7489とRFC 9091を置き換えるとあり、Author Domainの利用を検証し、失敗時のメッセージ取り扱いの希望とレポートを示す仕組みとして説明されています。この記事で使うのはRFC 9989本文の範囲です。関連するレポート仕様や受信側の製品挙動を、参照していない文書から補いません。
2. DMARCが判定するもの
DMARCは、Fromヘッダーから取り出したAuthor Domainと、SPFまたはDKIMで認証されたドメインの整合を確認します。passは、そのメッセージで使われたAuthor DomainがDomain Ownerに認可されたものだ、と受信側が検証できたという意味です。
表が収まらない場合は、横にスクロールできます
| 問い | DMARCが示すこと | ここからは言えないこと |
|---|---|---|
| 認可 | Author Domainの利用が認可されたか | 本文や添付ファイルが安全か |
| 整合 | SPF・DKIMの認証ドメインとFromの整合 | なりすまし以外の攻撃がないか |
| 処理の希望 | 失敗時にnone・quarantine・rejectなどを希望する | すべての受信側が同じ処理をすること |
| 報告 | 検証結果を報告する仕組み | すべての受信側が必ず報告すること |
RFC 9989は、DMARC passだけで受信者の受信箱への配送が安全・望ましいと保証するわけではない、と説明します。認可された送信元から、誤った案内や危険なリンクが届く可能性は残ります。
3. ポリシーは命令ではない
Domain OwnerはDNSのDMARCポリシーで、検証に失敗したメッセージをどう扱ってほしいかを示します。しかし、RFC 9989は、DMARC検証を行う受信組織はその希望を尊重してもよいが、必須ではないとしています。受信側の独自の評判、迷惑メール判定、配送ルールが組み合わさるためです。
したがって「p=rejectを書いたから、世界中の受信箱が拒否する」「DMARC passだから受け入れてよい」とは書けません。自社の送信側の設定と、主要な受信側で観測できる結果を別に確認します。
4. 集約レポートを送信元の棚卸しに使う
RFC 9989は、DMARCレポートを、ドメインを不正利用する送信元の発見だけでなく、自社の認証運用の穴を見つけて直すためにも使えると説明します。営業、請求、サポート、外部SaaSなど、誰が自社ドメインで送るかを一つの台帳にまとめる入口になります。
ポリシーを厳しくする前に、次を記録します。
- 自社ドメインを使う送信元と担当者。
- SPF・DKIMの認証結果とAuthor Domainとの整合。
- 転送、メーリングリスト、外部SaaSなど失敗しやすい経路。
- レポートの受信先、保持期間、調査する責任者。
ここで確認できない送信元が残っているなら、p=rejectへの変更を保留し、まず観測と修正を続けます。期間や閾値は自社の送信量と業務影響に合わせて決め、仕様から一律の日数を作りません。
5. DMARCの外側を別の対策にする
RFC 9989は、見た目が似たドメイン名、表示名の攻撃、本文の内容分析をDMARCだけで解決しません。認証にpassしたメールでも、フィッシング、誤送信、悪意ある添付、誤った請求は起こり得ます。
- 類似ドメインや表示名は、受信側の検知と利用者への表示で確認する。
- 本文・リンク・添付は、別のマルウェア・フィッシング対策で検査する。
- 重要な依頼は、メール以外の連絡先や承認経路で再確認する。
- DMARCのレポートで見える送信元と、業務上許可した送信元を照合する。
6. 自社で行う最小の確認
- DNSに公開したDMARCレコードと、参照しているRFCの版を記録する。
- 集約レポートから送信元、認証結果、整合失敗を一覧にする。
- 未把握の外部サービスを担当者へ照会し、正規かどうかを確認する。
- 受信側が希望ポリシーをどう扱ったか、テストメールで観測する。
- passを内容の安全性と混同しないよう、別の受信・リンク検査を残す。
この手順はRFCの遵守証明でも、メール到達率の保証でもありません。自社の送信経路を説明できる状態を作り、変更の影響を段階的に観測するための確認です。
7. passは本文の安全性を保証しない
DMARCが保証するのは、Author Domainの利用を認可されたものとして検証できるか、失敗時の希望と報告をどう示すかです。passは本文の安全性を保証せず、ポリシーはすべての受信側を拘束しません。RFC 9989を起点に送信元と認証の穴を可視化し、内容の安全性・類似ドメイン・利用者確認を別の対策として設計します。