DMARCbisで何が変わり、何が変わらないのか

DMARC仕様の次期バージョンであるDMARCbis（実質的なDMARC 2.0）は、IETFのLast Callを終え、現在RFC Editor Queueに入っています。Proposed Standardとしての公開は2026年が見込まれており、現行のRFC 7489は廃止される予定です。すでにDMARCレコードを運用しているのであれば、変わる点のほとんどは静かに進むものです。ただし、一つだけ静かでは済まない変更があります。

DMARCbisでは pct タグが削除されます。これはDMARCがプロトコル内で唯一提供していた段階的ロールアウトの仕組みでした。当社独自のデータを見ると、このタグは正しく使われることが稀で、そもそもほとんど使われていませんでした。削除は、プロトコルがもともと抱えていた穴を公式化するものであり、同時にDMARCが依然として答えを持たない問いを浮き彫りにします。つまり、正規のメールを壊さずに監視から強制へどう踏み出すのか、という問いです。

DMARCbisの現在地

最新のドラフトは draft-ietf-dmarc-dmarcbis-41で、2026年1月13日に更新されました。IETFのLast Callはバージョン36で2024年末に完了しています。ドキュメントは現在RFC Editor Queueに入っており、これはProposed StandardとしてRFC番号が割り振られ公開される前の最後の事務手続きです。

実務面で押さえておきたいポイントは三つです。

1. 既存のDMARCレコードはそのまま動きます。バージョンタグは v=DMARC1 のままで、DMARCbisを実装した受信側もRFC 7489形式のレコードを受け入れます。
2. ほとんどの変更は静かに進みます。タグのリネームや、Public Suffix ListのDNSベース方式への置き換えは受信側の実装内部で起きる話です。ドメイン所有者がレコードを有効に保つために何かをする必要はありません。
3. 監視から強制への移行に影響する変更が一つあります。 pct の削除です。再設計されたテストモードのセマンティクスと合わせて、段階的ロールアウトの想定が変わります。仕様書の他の部分を読まないとしても、この変更だけは理解しておく価値があります。

変更点の概観

RFC 7489（現行DMARC）とDMARCbisの主な違いは次のとおりです。

• 削除されるタグ： pct（パーセンテージによるポリシー適用）、rf（フォレンジックレポート形式）、ri（レポート間隔）。
• 追加されるタグ： psd（パブリックサフィックスドメイン用フラグ。DMARCに参加するPSO向け）、np（存在しないサブドメインに対するポリシー）、t（バイナリのテストモード）。
• Organizational Domainの判定： Public Suffix List（PSL）は廃止されます。代わりに、祖先ドメインのDMARCレコードを順にたどるDNS Tree Walkで境界を決定します。
• メーリングリストに関する指針：アクティブなメーリングリストトラフィックを持つドメインでは p=reject を使わないよう、仕様が明示的に注意喚起しています。購読者への巻き添え被害を抑えるためです。
• 廃止されるRFC：RFC 7489（DMARC）およびRFC 9091（PSD DMARC）。

本記事の残りでは、本番運用でDMARCをどう扱うかに実際に影響する変更点に絞って掘り下げます。

pct タグがなくなる

pct タグは、運用者が強制適用を段階的に進められるようにするためのDMARCの仕組みでした。 p=quarantine のレコードに pct=10 を設定すれば、失敗したメッセージの10%に検疫ポリシーを適用し、残り90%は通過させる、という意図です。実際に壊すことなく、完全に強制した場合に何が壊れるかを先に把握できるようにする狙いでした。

ところが現場ではうまく機能しませんでした。IETF自身がタグ削除の根拠として述べているとおり、受信側の pct 値の扱いには一貫性がなく、0 でも 100 でもない値のときの挙動は受信者エコシステム全体で信頼できるものではありませんでした。pct による段階的ロールアウトはくじ引きのようなもので、公開したパーセンテージと、実際にメールへ適用されたパーセンテージが一致することはまずありません。

DMARCbisはこの仕組みを t タグで置き換えます。 t=y を指定するとレコードはテストモードに入り、実効ポリシーが一段階引き下げられます。つまり p=reject のレコードに t=y を付けると p=quarantine として扱われます。 t=n（既定値）は完全強制です。パーセンテージは存在しません。グラデーションもありません。

素直に読めばこうなります。新仕様は pct を、段階的ロールアウトが実際に機能する別の仕組みで置き換えたわけではありません。機能しなかった仕組みを取り除き、段階的ロールアウトの問題は運用者に丸投げしているのです。

Public Suffix ListからDNS Tree Walkへ

RFC 7489の下では、受信側が invoices.example.com のようなサブドメインからのメールを処理するとき、外部で維持されている Public Suffix List を参照してOrganizational Domainの境界を特定します。その境界によって、適用されるDMARCポリシーと整合性評価の方法が決まります。

DMARCbisはPSLをDNS Tree Walkに置き換えます。受信側は外部リストを参照する代わりに、DNSに直接問い合わせます。まずFromドメインでDMARCレコードを探し、なければ一つ上の親ドメインへと1ラベルずつ登っていき（invoices.example.com → example.com → com）、最初に見つかった有効なDMARCレコードで止まります。そのレコードに付く新しい psd タグは、そのレコードが組織のものなのかパブリックサフィックス運用者のものなのかを受信側に伝え、その後の扱いを左右します。

組織のレコードを一つだけ持つ典型的なドメインであれば、Tree WalkとPSLは同じ結果にたどり着きます。問題はエッジケースです。自分の環境で確認しておきたいのは次の三つです。

• サブドメインにDMARCレコードを公開している場合（トランザクションメールとマーケティングメールを分離したり、サードパーティ送信元を切り離したりする目的でよくある構成です）。Tree Walkの下では、そのサブドメインからのメールに関しては、サブドメインのDMARCレコードが常に組織ポリシーより優先されます。何年も前に設定したまま見直されていないレコードがあれば、現在の組織ポリシーを知らぬ間に上書きしているかもしれません。棚卸ししてください。
• パブリックサフィックスを運用している場合（自社ゾーン配下で顧客ブランドのドメインを発行しているホスティング基盤、ccTLDやgTLDのレジストリ、テナントにサブドメインを割り当てるBaaSやCMSなど）。新しい psd=y タグはまさにこの用途のためにDMARCbisに組み込まれました。RFC 7489の下では別立てのRFC 9091で層を重ねていた仕組みが、DMARCbisでは本体仕様に取り込まれています。自ゾーンで psd=y レコードを公開すべきかを検討してください。
• 珍しいTLDやccTLD、あるいは複数ラベルからなるパブリックサフィックスを使う送信元がある場合（例： co.uk、github.io、s3.amazonaws.com 配下など）。そのサフィックスについてPSLのエントリとTree Walkの挙動が厳密に一致するとは限りません。自分のドメインから、その上のラベルをパブリックサフィックスまで一つずつたどって、期待どおりにDMARCレコードが解決されるか確認してください。

それ以外の方は、特に何もする必要はありません。既存のDMARCレコードはPSLの下と同じようにTree Walkの下でもそのまま機能します。

メーリングリストに関する新たな指針

改訂仕様では、アクティブなメーリングリストトラフィックを持つドメインで p=reject を公開することに対して明示的な警告が加わりました。理由は、DMARCの運用者が長年ぶつかってきた痛みそのものです。メーリングリストはDMARCの整合性を壊す形でヘッダーを書き換えてしまい、拒否ポリシーは何も悪くない購読者を巻き込みます。

オープンソースプロジェクトのリスト、業界フォーラム、業界団体のニュースレターなど、メーリングリストが盛んに使われているドメインであれば、この新しい指針は真剣に受け止める価値があります。メーリングリストへの参加を強い組織ポリシーと両立させるためにほとんどのチームが採用しているサブドメイン分離やARC活用のパターンは、DMARC実装完全ガイドで解説しています。

DMARCbisが解決しないこと

仕様改訂は、段階的ロールアウトが機能していなかったことを認めています。しかし、それを修正してはいません。取り除いているだけです。

監視から強制へ移ろうとしている組織にとって、これは当社のデータがここ数カ月示してきた構造的な欠落を公式化する動きです。DMARCeyeプラットフォームで実際に監視されているドメインを対象とした2026年第1四半期のスナップショットでは次のようになっています。

• 有効なDMARCポリシーを持つドメインのうち39.9%が永続的に p=none のまま留まっており、監視ツールを動かす程度には関与しているにもかかわらず、なりすましに対してまったく保護が効いていません。
• 強制適用まで進めているドメインのうち93.8%はトラフィックの100%にポリシーを適用しており、段階的ロールアウトは行っていません。 pct<100 を使っているのは6.2%にとどまります。

現象は二つですが、原因は一つです。DMARCには監視と強制の間に機能する中間地点が存在しません。その橋渡しのはずだった仕組み（pct タグ）はくじ引きで、DMARCbisのあとには姿を消します。新しいバイナリのテストフラグは、段階的ロールアウトが本来果たすべきだった役割を肩代わりしてくれません。

慌てずに備える

ほとんどのドメイン所有者にとって、DMARCbisは火事場のような対応が必要な話ではありません。既存のレコードはそのまま動きますし、受信側の整合性評価が一夜で変わるわけでもありません。普及が進むにつれて頭に入れておきたい実務的な論点がいくつかあります。

• 現在 pct を段階的ロールアウトに使っている場合：レコード自体は構文的に有効なままですが、DMARCbis準拠の受信側は実質的に pct<100 を pct=100 として扱います。パーセンテージに依存していたのであれば、今のうちに移行計画を立ててください。仕様内でもっとも近い代替はテストモードの t=y ですが、これは確率的な適用ではなく、ポリシーを一段階引き下げる挙動です。
• サブドメイン構成が複雑な場合：Tree Walkモデルを前提にDMARCレコードを見直してください。多くの場合PSLと同じ結果になりますが、エッジケースは確実に存在します。
• メーリングリストトラフィックが活発な場合：対象ドメインに p=reject を使わないようにという新しい指針は、真剣に受け止める価値があります。サブドメインを切り出して扱うのが定番のパターンです。
• すでに p=none のまま長く留まっている場合：DMARCbisは状況を変えません。構造的な問題は仕様にあるのではなく、安全に移行するための橋が欠けていることにあります。DMARCbisはその欠落を公式化しますが、解決はしません。

DMARC集約レポートの読み方ガイドとDMARC実装完全ガイドはどちらも、DMARCbisの下でもそのまま通用します。仕様が公開されて変わるのはレコードに書ける内容であって、返ってきたレポートの読み方ではありません。

移行が実際に求めてくるもの

急ぎで対応すべきことはありません。DMARCbisのあともDMARCはDMARCですし、今日公開しているレコードは新仕様がRFC化された日にも受け入れられます。移行が求めるのは姿勢の切り替えです。監視から強制への移行は、プロトコルが助けてくれない問題だと前提に置き、そのつもりで計画する、ということです。

集約レポートを監視し、強制適用の前に未知の送信元にフラグを立て、ポリシーを厳しくした場合に何が壊れるかを平易な言葉で伝えてくれるツールは、プロトコルが厳しくなるほど価値を増します。DMARCeyeはまさにこの役割を担うために作られており、無料オンラインツール（DMARC設定ツール、SPF・DKIM・BIMIチェッカー）を使えば設定面は10分以内で確認できます。

仕様が切り替わる前に、自ドメインのDMARCレポートが実際に何を語っているのか確認しましょう。DMARCeyeを無料で試す。