Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — みんなが使っているのに標準ではなかったプロトコル
何が出たか — 3つの文書に分かれたDMARC
まず変わらなかったこと — あなたのレコードはそのまま有効
最大の変化 — PSLが外れ、DNSツリーウォークが入った
タグ整理 — pctはなぜ死んだのか
標準が初めて明文化した運用原則
RFCが自ら認めていること — メーリングリスト問題は解けていない
SPF -allの死角 — レポートに現れない拒否
実装はどこまで来ているか
実務チェックリスト — 今やるべきことと、やらなくてよいこと
おわりに
参考資料

はじめに — みんなが使っているのに標準ではなかったプロトコル

奇妙な事実から始めます。GmailとYahooは2024年から大量送信者にDMARCを事実上強制してきましたし、銀行や政府機関は導入状況の監査を受け、メールセキュリティのスタートアップ生態系がまるごとその上に築かれています — それなのに、DMARCを定義したRFC 7489はIETF標準ではありませんでした。2015年3月に出たこの文書は、IETFワーキンググループの合意を経ていないIndependent Submissionであり、分類もInformationalです。文書としての地位だけを見れば、「誰かがこうしているらしい」を記録した文書の上で、世界中のメール認証が11年間回ってきたことになります。

2026年5月、この状態は終わりました。IETF DMARCワーキンググループのいわゆるDMARCbis作業がRFC 9989として発行され、DMARCはStandards Track文書になり、RFC 7489と(PSD DMARCを扱った実験文書)RFC 9091を廃止(obsolete)しました。datatrackerによれば、ドラフトリビジョン41番、本文83ページの成果物です。

「標準になったのはめでたい話だ」で片付けるには惜しいほど、今回の改定は実際にプロトコルの挙動を変えます。組織ドメインを探すアルゴリズムはまるごと入れ替わり、タグがいくつか消えて生まれ、そして何より、これまでコミュニティの暗黙知だった運用原則が初めてMUSTとSHOULD NOTの言葉で明文化されました。一つずつ見ていきます。(SMTPとDNS自体になじみがなければ、DNSとメールプロトコルの基礎整理を先に読んでおくとよいでしょう。)

何が出たか — 3つの文書に分かれたDMARC

RFC 7489一本だったスペックが3つの文書に分割されました。すべて2026年5月に同時発行され、すべてStandards Trackです。

RFC 9989 — DMARC本体。ポリシーレコードの文法、整列(alignment)評価、ポリシー発見。RFC 7489とRFC 9091を廃止します。編集者はValimailのT. HerrとStandcoreのJ. Levine。
RFC 9990 — 集約レポート(aggregate reporting)。XMLレポートフォーマットと送信方式がこちらに分離されました。
RFC 9991 — 失敗レポート(failure reporting)。RFC 6591を更新します。

レポート仕様が分離されたのは単なる文書整理ではなく、今後レポートフォーマットを本体とは独立に進化させていくという構造変更です。参考までに、RFC 7489に11年間積み上がった正誤表(errata)15件がそれぞれどう処理されたかも、RFC 9989の付録C.9に項目ごとに記録されています。

まず変わらなかったこと — あなたのレコードはそのまま有効

実務者にとって最も重要な事実はこれです。バージョン文字列はそのままです。 RFC 9989のvタグの定義は、依然として唯一の有効値としてv=DMARC1を明示します(大文字小文字を区別し、レコードの最初のタグでなければならない)。かつてコミュニティで囁かれた「DMARC2が来る」という話は実現しませんでした。今DNSにあるレコードは新スペックの下でもそのまま有効で、移行イベントのようなものは存在しません。

これが可能な理由はスペックの拡張規則にあります — 未知のタグは無視しなければならない(MUST)ため、新しいタグの追加はバージョン昇格を要求しません。後で見るt、np、psdタグがすべてv=DMARC1の中で追加された理由はここにあります。逆にpctのような廃止されたタグは、新世代の受信者にとって単なる「未知のタグ」となり、静かに無視されます。

最大の変化 — PSLが外れ、DNSツリーウォークが入った

RFC 7489では、組織ドメイン(Organizational Domain)を判定する方法はPublic Suffix List(PSL)でした。この方式の問題点はRFC 7489自身も自覚していました — どのPSLを使うべきかを強制しておらず(publicsuffix.orgを提案しただけ)、更新周期の指針もなく、受信者ごとに違うPSLを使えば相互運用性の問題が生じることを認めたうえで、「もっと信頼できる方法ができたら置き換えられるべきだ」と書き残していました。IETFの外でボランティアが管理するリストファイルが、世界中のメールポリシー判定の基準点になっているというのは、常に居心地の悪い依存関係でした。

RFC 9989はこれをDNSツリーウォークに置き換えました。外部リストの代わりに、DNSの階層を直接たどってDMARCレコードを探す方式です。

動作はこうです。まず_dmarc.を付けた送信ドメイン(RFC5322.Fromのドメイン)でTXTレコードを問い合わせ、なければラベルを一つずつ剥がしながら上へ登ります。DoS防止のためクエリ数には上限があります — 最大8クエリ。ラベルが8個を超えるドメインは途中を飛ばし、右から7ラベル目の地点にジャンプします。RFCの例をそのまま持ってくると、ラベル13個のドメインの全ツリーウォークは次の8回の問い合わせで終わります。

送信ドメイン: a.b.c.d.e.f.g.h.i.j.mail.example.com

1. _dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com   (元のドメイン)
2. _dmarc.g.h.i.j.mail.example.com               (右側7ラベルへジャンプ)
3. _dmarc.h.i.j.mail.example.com
4. _dmarc.i.j.mail.example.com
5. _dmarc.j.mail.example.com
6. _dmarc.mail.example.com
7. _dmarc.example.com
8. _dmarc.com

上限を8とした根拠も文書にあります — 発行時点の観測データ上、実際に使われている送信ドメインはラベル7個までしか存在せず、そこに余裕分を1つ足した値です。

登りながら見つけたレコードの中から組織ドメインを選ぶ規則は、新しいpsdタグと結びついています。要約するとこうです。

有効なレコードにpsd=nがあれば、そのドメインが組織ドメイン。以上。
たどる途中で出会ったレコードにpsd=yがあれば(公共サフィックスドメインである宣言)、その1ラベル下のドメインが組織ドメイン。
どちらもなければ、有効なレコードが見つかった名前のうちラベル数が最も少ないものが組織ドメイン。

この設計のおかげで、RFC 9091が実験的に試みたPSD DMARC(公共サフィックスレベルのポリシー。たとえば国別TLD運用者が配下の存在しないドメインへのなりすましを防ぐもの)が、別レジストリなしに本体へ吸収されました。RFC 9989はRFC 9091について「記述通りには実装されなかった」という実験結果を淡々と記録し、廃止処理します。

移行期の落とし穴もスペックに明記されています。 RFC 7489実装(PSLベース)の受信者とRFC 9989実装(ツリーウォーク)の受信者は、同じメールに対して異なる組織ドメイン、したがって異なるポリシーと異なる整列判定に到達しうるのです。スペックが示す回避策は2つです — 実際に送信に使うすべてのドメインに明示的なDMARCレコードを掲示すること、そしてstrict整列を使うこと。送信ドメイン自体にレコードがあれば、どちらの受信者もツリーを登る前の最初のクエリで終わるため、アルゴリズムの違いは表に出ません。

タグ整理 — pctはなぜ死んだのか

今回の改定でタグが3つ追加され(np、psd、t)、3つ削除されました(pct、rf、ri)。

pct廃止のいきさつがおもしろいのです。もともとの狙いは「メールのN%だけにポリシーを適用してほしい」という段階的移行の装置でしたが、RFC 9989の付録A.6が記録する運用経験はこうです — 0と100以外は正確に適用されることがまれで、実装ごとのばらつきも大きかった。ところがそのうちpct=0だけは、まったく別の用途で生き残りました。一部の中継者(メーリングリストなど)やメールボックスプロバイダがpct=0を「このドメインはもうすぐポリシーをオンにする予定」というシグナルとして読み取り、DMARC失敗を避けるためにFromヘッダーを書き換えるトリガーとして使い始めたのです。ドメイン所有者の立場では、pct=0をオンにする前後で集約レポートを比較すれば、「Fromを書き換えない中継者を通るトラフィックがどれくらいあるか」を推定でき、enforcementに進んでよいかを判断するうえで実際に役立ちました。

そこでRFC 9989は、有効値が事実上2つしかないパーセンテージタグを維持する代わりに、その生き残った機能だけを取り出して tタグ(testing)に置き換えました。t=yはpct=0に、デフォルト値のt=nはpct=100に対応します。t=yの意味は明確に定義されています — 検証者に対して、宣言されたポリシーをそのまま適用せず、一段階下げて適用してほしいという要請です。p=rejectにt=yならquarantineのように、p=quarantineにt=yならnoneのように扱われ、レポート生成には影響しません。

npタグはRFC 9091から輸入されたもので、存在しないサブドメイン(NXDOMAIN、RFC 8020の意味論に基づく)に対するポリシーです。フォールバック順序は、npがなければsp、spもなければpです。実務上これは、サブドメインなりすまし対策にそのまま使える道具です — 実在するサブドメインはsp=noneで観察しつつ、そもそも存在しない名前へのなりすましだけをnp=rejectで即座に遮断する組み合わせが可能になります。

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; t=y; sp=none; np=reject; rua=mailto:dmarc-rpt@example.com"

rf(失敗レポートフォーマット)とri(レポート間隔)タグは削除され、レポートURIに最大サイズを指定する文法も消えました(旧文法は無視対象)。レポート関連の詳細は今やRFC 9990/9991の領域です。

標準が初めて明文化した運用原則

私の考えでは、今回の改定の本当の重みはアルゴリズムよりもここにあります。この10年間「みんなそうしている」という暗黙知だったものが、初めて規範的な言葉(MUST/SHOULD)になりました。RFC 9989の7.4節と8節から抜粋します。

第一に、p=rejectドメインはSPFだけに依存してはいけません(MUST NOT)。DKIM署名は義務です(MUST)。 理由はフォワーディングです。卒業生向けメールリレーやロールベースのエイリアスのようにメールを中継する流れでは、SPFはほぼ確実に壊れます — 最終受信者が見る送信元IPは中継者のものだからです。一方DKIM署名は、本文が変形されない限り中継を生き延びます。SPF単独でDMARCを通過させていたドメインがp=rejectをオンにすると、正常な中継メールが静かに破棄されます。

第二に、一般ユーザーがメールを書くドメインはp=rejectを掲示すべきではありません(SHOULD NOT)。 従業員・構成員がインターネットのメーリングリストに投稿できるドメインであれば、p=rejectはリストとその購読者に実害を与えます。どうしても行くならスペックが手順まで定めています — p=noneで最低1か月、続いてp=quarantineで同じ期間を置き、集約レポートの処分結果を比較したうえで判断せよ、というものです。銀行のように機械送信のトランザクションメールしか出ないドメインと、人が自由にメールを書くドメインとでは、違うポリシーがふさわしいという話でもあります。

第三に、受信者はp=rejectという理由だけでメールを拒否してはいけません(MUST NOT)。 他に裏付けとなる分析がなければ、DMARC失敗のみをもってp=quarantineのように扱えと(MUST)明記しています。送信ドメインのポリシー宣言は、受信者への命令ではなく参考入力にすぎないということ — Gmailのような大規模受信者が実際にやってきたやり方が、標準の文章になったわけです。

そのほか、「完全なDMARC参加」のチェックリストを定めた8節も一読の価値があります。ドメイン所有者は整列したSPFと整列したDKIMの両方を備え、集約レポートの受信箱を用意して実際に分析し、送信ドメインと組織ドメインの両方にレコードを掲示する必要があります。受信者は集約レポートを最低1日単位で送るべきです(SHOULD)。

RFCが自ら認めていること — メーリングリスト問題は解けていない

7.4節には、標準文書としては珍しいほど率直な段落があります。要旨を移せば — 上記の助言にもかかわらず、間接メールの流れに緩和策を適用する受信者は現実にはほとんどおらず、自分のユーザーの間接メールへの影響を考慮する組織もほとんどなく、この文書のどんな助言もその現実を変えそうにないというのです。その結果、Fromを修正せずにメーリングリストを経由したメールはp=rejectのせいで頻繁に拒否されており、この10年でリストソフトウェアはことごとくFrom書き換えという回避策を採用し、今やそれが既成事実になったと記録しています。

では、From書き換えなしにリストを生かす技術はどこまで来ているのか。RFC 9989が名指しする候補はARC(Authenticated Received Chain、RFC 8617)ですが、評価は冷静です — "none of the methods have become widely used"(どの手法もまだ広く使われるには至っていない)。実際、RFC 8617は2019年以降今もExperimentalの地位のままです。広く採用される日が来たら文書を更新する、という一文でこの節は締めくくられます。要するに、DMARCの最も古い副作用は標準化後も未解決の問題として残っており、標準自身がそう述べているのです。

SPF -allの死角 — レポートに現れない拒否

7.1節が指摘する運用上の落とし穴の一つは、別に触れておく価値があります。SPFはSMTPトランザクションの初期、本文が送信される前に評価されることがあります。そのため、SPFレコードをハードフェイル(-all)で終える設定のドメインのメールは、DMARC処理が始まる前に拒否されることがあります。問題は二重です。

整列したDKIM署名があってDMARCでは通過したはずのメールが、SPFの段階で先に切り落とされることがあります。
こうしてDATA段階の前に拒否されたメールは、Fromドメインが明らかになる前なので、集約レポートにまったく現れません。

DMARCの集約レポートで送信状況を監視しているつもりでも、-allによる早期拒否はその監視網の外で起きているということです。「レポートがきれいだ」と「メールが全部届いている」が別の命題になる地点なので、-allを使うドメインはこの死角を認識しておく必要があります。ソフトフェイル(~all)とDKIM整列の確保を土台に、DMARCポリシーで拒否を制御するほうが、可視性の面では優れています。

実装はどこまで来ているか

発行から2か月目の今は明らかに移行期です。確認できる点をいくつか挙げます。

OpenDMARCは2026-05-27にRFC 9989/9990/9991に対するギャップ分析のissueを開いて追跡中で、組織ドメイン探索を旧来の7489ウォーク・PSL・9989ツリーウォーク・自動から選べるようにするwalk_mode選択機能のPRが2026-06-21にdevelopブランチへマージされました。つまり参照実装級のオープンソースでも、ツリーウォークはまだ開発ブランチに入ったばかりの段階です。
オランダ政府系の診断ツールInternet.nlも、PSLをツリーウォークへ置き換えるissueを開いたままです。
Gmailの送信者ガイドラインは、本稿執筆時点でも依然として2024年体制のままです — 1日5,000通以上をGmailアカウントに送る送信者はSPFとDKIMを両方設定し、DMARCを掲示しなければなりませんが、ポリシーはnoneでも構いません(公式文書)。ページのどこにもRFC 9989への言及はありません。

大手メールボックスプロバイダが内部でツリーウォークへ移行済みかどうかは、公開資料がないためここでは断定しません。はっきりしているのは、当面インターネット上にPSL基準の受信者とツリーウォーク基準の受信者が共存するという事実であり、だからこそ上で述べた回避策 — 送信に使うすべてのドメインに明示的なレコードを掲示すること — が移行期の実質的な防御になります。

実務チェックリスト — 今やるべきことと、やらなくてよいこと

やらなくてよいことから。 レコードのv=DMARC1はそのままにしておきます。DMARC2への移行というものは存在しません。既存の展開はそのまま動き続けます。

やるべきことはこの程度です。

まずDKIM整列を確保してください。 p=rejectであるか、そこへ向かう計画があるなら、すべての送信経路が整列したDKIM署名を持っているかどうかをまず確認する必要があります。SPF単独通過に頼るp=rejectは、今や明示的な標準違反(MUST NOT)です。
レコードからpct、rf、riを整理してください。 新世代の受信者はどのみち無視しますが、旧世代の受信者はpctを解釈し続けるため、両者の挙動が食い違う原因になります。段階的移行のシグナルが必要ならt=yに移してください — ただし旧世代の受信者は逆にtを知らないということまで考慮する必要があります。
実際に送信に使うすべてのドメインに明示的なDMARCレコードを掲示してください。 PSL基準の受信者とツリーウォーク基準の受信者が異なる答えに到達する余地を根本から断つ、スペックが直接推奨する方法です。
存在しないサブドメインへのなりすましが心配ならnpを使ってください。 実在するサブドメインのポリシー(sp)と分けて、NXDOMAINとなる名前だけを強く遮断できます。
-allを使っているなら、集約レポートの死角を認識してください。 DATA以前に拒否されたメールはレポートに残りません。
一般ユーザードメインのp=rejectは考え直してください。 標準が定めた手順 — noneで最低1か月、quarantineで同じ期間、レポート比較 — を踏まなかったreject移行は、今や根拠文書を突きつけられる反対理由になります。

おわりに

プロトコルのビットだけを見れば、今回の標準化は静かな改定です — レコードはそのままで、通過・失敗判定のロジックもほとんどそのままです。しかし3つの点は実質的に変わりました。組織ドメインの判定が外部リスト(PSL)依存からDNS自身の探索(ツリーウォーク、最大8クエリ)へ変わり、段階的移行の装置が現実で検証された形(tタグ)に置き換わり、運用原則が初めて引用可能な規範文になりました — p=rejectにはDKIMが義務だ、ユーザードメインのrejectはやめておけ、受信者はreject宣言だけで捨てるな。

そしてこの標準の最も信頼できる部分は、自らの限界を文書の中に書き残したことです。メーリングリスト問題は依然未解決であり、ARCは依然Experimentalであり、受信者たちが助言に従わないだろうということまで標準自身が予測しています。11年かかった標準化の結論が「完成」ではなく「現実の正直な記録」であるということ — 40年前からあるメールというシステムには、それがむしろふさわしい結末に思えます。