忙しいメール管理者のための RFC7489 から見直すべき「3 つのポイント」とオススメ運用方針 ── RFC9989 で DMARC はどう変わった?
2026年07月14日 火曜日
2026 年 5 月に、従来の DMARC (RFC7489) のアップデートにあたる RFC9989 が発行されました。
- RFC9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
https://datatracker.ietf.org/doc/html/rfc9989
「あぁ…またやることが増えるのか…」
などと絶望する必要はありません。
メール運用の立場より結論から申し上げますと、細かな変更点はあるものの、新しい RFC9989 は既存の DMARC を大きく変えるものではありません。特殊なケースの追加と、現実解に即した仕様整理に近いものとご理解いただければよいと思います。ご安心ください。
本記事では、忙しいメール管理者のために、RFC9989 の要点を 3 つに絞って解説します。細かい変更点を説明するのではなく、「何をすればいいか」にフォーカスして説明していますので、必要に応じてご担当されている組織内で DMARC のポリシーを見直すキッカケとしていただければ幸いです。
(ポイント1) DMARC レコードが存在しなかったときの探索方法が変わる
RFC9989 の最も大きな、そして微妙な仕様変更です。
すでに DMARC に対応しており、メール送信にサブドメイン名を利用していない場合は影響なしと考えて問題ありません。
差出人メールアドレスがサブドメイン名で、DMARC レコードが存在しなかったときの動きを一言で表すと、新旧で次のような違いがあります。
- (旧・RFC7489) Public Suffix List を見て組織ドメイン名を参照する (※1) (※2)
- (新・RFC9989) 一つ上の階層の親ドメイン名を順に参照する (最大 8 階層まで探索する)
従来は深いサブドメインの中間にあるサブドメイン名に設定されている DMARC レコードは参照されませんでしたが、新しい RFC9989 では参照されるケースが出てくることに注意が必要です。DNS を一つずつ上位ドメインへ辿りながら DMARC レコードを探索するため、組織ドメインの判定を Public Suffix List に依存していた従来方式とは異なるポリシーに到達する可能性があるからです。
なお、新しい RFC9989 が発行されたからといって、運用現場ではすぐに宛先(メール受信者)側の動きが新 RFC に追従されるわけではないことにも注意が必要です。差出人側からは、多数ある宛先の DMARC 評価がどのように実装されているかを事前に知ることはできません。
よって、メール管理者へのオススメのアクションは、メールで利用しているドメイン名を棚卸しし、利用中の組織ドメイン名とサブドメイン名すべてに明示的な DMARC レコードを設定することです。どの宛先から見ても同じ DMARC ポリシーにたどり着くように DNS を設計すれば、新旧 DMARC の実装の違いによるアクションの違いが生まれません。さらにメールで利用しているドメイン名も明確になり、監査や運用の引き継ぎも容易になるという副次的なメリットも得られます。
(ポイント2) np=reject を追加で設定することをオススメ
従来の DMARC では、存在しないサブドメイン名でなりすましメールが送られたときに、そのメールをどのように扱うべきかを明示的に指定する仕組みがありませんでした。例えば、example.jp に次のような DMARC レコードが書いてあったとします。
_dmarc.example.jp. IN TXT "v=DMARC1; p=reject; sp=quarantine"
このとき、example.jp に対する DMARC のポリシーは「reject」、もし mail.example.jp というサブドメインが存在するときは「quarantine」が適用されます。しかし、差出人メールアドレスが badguy@no-such-domain.example.jp という存在しないサブドメイン名だったとして、そのなりすましメールが送られたとき、このメールをどのように扱うかは曖昧でした。
そこで有用なのが、np= タグによる制御です。ほとんどの組織ではメールアドレスに利用されるドメイン名は決まっており、管理されていないサブドメイン名でメールが出ることは望ましい状況とは言えません。また、存在しないサブドメイン名で送信されたメールは、宛先で何らかのエラーになったときに元の差出人へエラーを通知できないことや、バックスキャッターといった問題の温床にもなることから、受信拒否するメールサービスも多くあります。(IIJ のメールサービスもそうです)
存在しないサブドメイン名を用いたなりすまされたメールに対して「受信拒否してほしい」という明確な意思表示ができ、組織ドメイン名のポリシー(p=)や、存在するサブドメイン名向けのポリシー(sp=)とは区別して定義することができるようになったのが、np= タグによる新機能です。このような背景から、np= タグに reject 以外のポリシーを設定するケースは多くないと思われます。
なお、np= タグは任意 (OPTIONAL) とされていますので、このタグが存在しなかったとしても DMARC の運用に影響はありません。
(ポイント3) p=reject に強化すべきか
新しい RFC9989 ではメーリングリストを代表とするシステムとの相互運用性を考慮し、p=reject の運用には注意が必要である点が加筆されました (§5.1.7, §7.4)。しかし、今回追記された内容は、従来から存在していた「DMARC との相性の悪さ」をより明確に整理・記述したものであり、現在の送信ドメイン認証の運用を変えるものではありません。
また、仮に p=reject にできなかったとして、なりすましメールから守るための代替策を用意する必要があります。これは「なりすましメールからの防御」と「DMARC と相性の悪いシステムから送られたメールを救済すること」のどちらを優先するかというトレードオフの問題です。
したがって筆者としては「基本スタンスとして p=reject を目指すべき」、という従来の方針と変わらないと考えます。
幸いにも最新の Mailman3 や Sympa といったメーリングリストサーバは、Header From をメーリングリストのドメイン名に書き換えることで DMARC との相性の悪さを回避する機能を実装しています(※3)(※4)。この方法は最適解とは言えないものの、多くのメーリングリスト運用者で支持されている手法であり現実解です。
重要なのは「メーリングリストがあるから p=none に戻す」ではなく、「p=reject を維持できるようシステム側を改善できないか検討すること」です。p=reject にすれば、DMARC 認証に失敗した Header From のなりすましメールに対する強力な防御が期待できます。その結果、差出人ドメイン名のブランドが守られるという大きなメリットが得られる点は従来から変わっていないのです。
まとめ
新しい RFC9989 は PDF にして 69 ページありますが、ほとんどは従来の RFC7489 と同じで、大きな運用を変更するものではありませんでした。改めて重要なポイントをまとめると次の 3 点です。
- DMARC レコードが存在しなかったときの探索方法が変わりました。中間の階層にあるサブドメイン名の DMARC レコードが意味を持つケースがあります。運用者としてはメールで利用しているドメイン名を棚卸しし、すべてのサブドメイン名に明示的な DMARC ポリシーを書いておくのがオススメです。
- 存在しないサブドメイン名でなりすまされたときの DMARC ポリシーを、np= タグで新規に定義することができるようになりました。np=reject を書いておくのがオススメです。
- 引き続き、p=reject を目指してメール環境を整えていくのがオススメです。なりすましメールに対する強力な防御が期待でき、差出人ドメイン名のブランドを保護するためです。
より詳しく知りたい方へ
RFC9989 で新設されたタグと廃止されたタグをまとめました。
廃止されたタグは RFC7489 で仕様は定義されていたものの、ほとんどのケースで使われていなかった(受信側で実装されなかった)ものです。もし、ご担当されている組織の DMARC レコードで廃止されたタグが記述されている場合は、将来の負債とならないようにこのタイミングで消しておくと良いでしょう。
| タグ | 意味 | 値 | 例 | 省略時 | |
|---|---|---|---|---|---|
| 新 | np | 存在しないサブドメインのポリシー | none, quarantine, reject | np=reject | sp があれば sp、なければ p を継承 |
| 新 | t | テストモードかどうか | y, n | t=n | t=n (テストではない) |
| 新 | psd | Public Suffix Domain かどうか | y, n, u | psd=n | psd=u |
| 廃止 | pct | ポリシーを適用する割合 | 0～100 | pct=80 | pct=100 |
| 廃止 | rf | 失敗レポートの形式 | afrf | rf=afrf | rf=afrf |
| 廃止 | ri | 集約レポートの送信間隔 | 0～4294967295 | ri=43200 | ri=86400 |
新設されたタグのオススメ運用方針は次のとおりです。
- np (存在しないサブドメイン名のポリシー)
- np=reject を追加で設定する。
- 存在しないサブドメイン名でなりすましメールが送られても守られる。
- 省略時は従来の動作と変わらない想定でよい。
- t (テストモードかどうか)
- 従来の pct=0 と同じ動きになるが、使わなくてよい。
- 例えば「p=none」と設定するのと、「p=quarantine; t=y」と設定するのと同様の効果になるが、受信側が新しい RFC9989 の t= タグの解釈・実装をしていることが前提となる。
- none → quarantine → reject の 3 段階でポリシーを強化していくベストプラクティスは従来から変わらない。
- psd (Public Suffix Domain かどうか)
- 一般的な事業者・組織は psd=n (No) 固定でよい。
- TLD (トップレベルドメイン名) のオーナーや、GitHub Pages のようにサブドメイン名を複数の組織に開放しているようなケースで psd=y と設定すべきケースはあるが特殊用途。例えば、銀行向けの TLD として運用されている .bank には psd=y が定義されている。
_dmarc.bank. IN TXT "v=DMARC1; p=reject; sp=none; np=reject; psd=y; (以降省略)"
- 省略時は psd=u (Undefined) として扱われるので、動作は従来と変わらない想定でよい。
なお、DMARC レポートの仕様は、RFC9990 (集約レポート) と RFC9991 (失敗レポート) として別 RFC に整理されました。DMARC レポートを生成・解析する開発者向けであり、運用担当者は必要に応じて参照する程度で十分かと思います。
- RFC9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting
https://datatracker.ietf.org/doc/html/rfc9990 - RFC9991: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting
https://datatracker.ietf.org/doc/html/rfc9991
脚注
- 旧 RFC7489 では組織ドメインの判定に Public Suffix List (PSL) を利用することが前提でした。PSL はもともと Web ブラウザの Cookie の境界を定義する目的で整備されたリストであり、電子メールのために IETF で標準化された仕組みではありません。そこで RFC9989 ではこの外部依存を解消するため、DNS の階層を一つずつ上位ドメインへたどる「DNS Tree Walk」と呼ばれる探索方式へ変更されたのです。[↑]
- 「組織ドメイン名」の考え方については、筆者の以下の資料もご参照ください。
なお、これらの資料は新しい RFC9989 発行前の資料である点もご留意ください。[↑]
- Mailman3 DMARC mitigation:
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rules/docs/dmarc-mitigation.html[↑] - sympa DMARC protection:
https://www.sympa.community/manual/customize/dmarc-protection.html[↑] - なお、RFC9989 にはタイプミスが存在します。見つけてみてください。→ 答え
