DMARC仕様の次期バージョンであるDMARCbis（実質的なDMARC 2.0）は、IETFのLast Callを終え、現在RFC Editor Queueに入っています。Proposed Standardとしての公開は2026年が見込まれており、現行のRFC 7489は廃止される予定です。すでにDMARCレコードを運用しているのであれば、変わる点のほとんどは静かに進むものです。ただし、一つだけ静かでは済まない変更があります。
DMARCbisでは pct タグが削除されます。これはDMARCがプロトコル内で唯一提供していた段階的ロールアウトの仕組みでした。当社独自のデータを見ると、このタグは正しく使われることが稀で、そもそもほとんど使われていませんでした。削除は、プロトコルがもともと抱えていた穴を公式化するものであり、同時にDMARCが依然として答えを持たない問いを浮き彫りにします。つまり、正規のメールを壊さずに監視から強制へどう踏み出すのか、という問いです。
最新のドラフトは draft-ietf-dmarc-dmarcbis-41で、2026年1月13日に更新されました。IETFのLast Callはバージョン36で2024年末に完了しています。ドキュメントは現在RFC Editor Queueに入っており、これはProposed StandardとしてRFC番号が割り振られ公開される前の最後の事務手続きです。
実務面で押さえておきたいポイントは三つです。
v=DMARC1 のままで、DMARCbisを実装した受信側もRFC 7489形式のレコードを受け入れます。pct の削除です。再設計されたテストモードのセマンティクスと合わせて、段階的ロールアウトの想定が変わります。仕様書の他の部分を読まないとしても、この変更だけは理解しておく価値があります。RFC 7489（現行DMARC）とDMARCbisの主な違いは次のとおりです。
pct（パーセンテージによるポリシー適用）、rf（フォレンジックレポート形式）、ri（レポート間隔）。psd（パブリックサフィックスドメイン用フラグ。DMARCに参加するPSO向け）、np（存在しないサブドメインに対するポリシー）、t（バイナリのテストモード）。p=reject を使わないよう、仕様が明示的に注意喚起しています。購読者への巻き添え被害を抑えるためです。本記事の残りでは、本番運用で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 を、段階的ロールアウトが実際に機能する別の仕組みで置き換えたわけではありません。機能しなかった仕組みを取り除き、段階的ロールアウトの問題は運用者に丸投げしているのです。
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は同じ結果にたどり着きます。問題はエッジケースです。自分の環境で確認しておきたいのは次の三つです。
psd=y タグはまさにこの用途のためにDMARCbisに組み込まれました。RFC 7489の下では別立てのRFC 9091で層を重ねていた仕組みが、DMARCbisでは本体仕様に取り込まれています。自ゾーンで psd=y レコードを公開すべきかを検討してください。co.uk、github.io、s3.amazonaws.com 配下など）。そのサフィックスについてPSLのエントリとTree Walkの挙動が厳密に一致するとは限りません。自分のドメインから、その上のラベルをパブリックサフィックスまで一つずつたどって、期待どおりにDMARCレコードが解決されるか確認してください。それ以外の方は、特に何もする必要はありません。既存のDMARCレコードはPSLの下と同じようにTree Walkの下でもそのまま機能します。
改訂仕様では、アクティブなメーリングリストトラフィックを持つドメインで p=reject を公開することに対して明示的な警告が加わりました。理由は、DMARCの運用者が長年ぶつかってきた痛みそのものです。メーリングリストはDMARCの整合性を壊す形でヘッダーを書き換えてしまい、拒否ポリシーは何も悪くない購読者を巻き込みます。
オープンソースプロジェクトのリスト、業界フォーラム、業界団体のニュースレターなど、メーリングリストが盛んに使われているドメインであれば、この新しい指針は真剣に受け止める価値があります。メーリングリストへの参加を強い組織ポリシーと両立させるためにほとんどのチームが採用しているサブドメイン分離やARC活用のパターンは、DMARC実装完全ガイドで解説しています。
仕様改訂は、段階的ロールアウトが機能していなかったことを認めています。しかし、それを修正してはいません。取り除いているだけです。
監視から強制へ移ろうとしている組織にとって、これは当社のデータがここ数カ月示してきた構造的な欠落を公式化する動きです。DMARCeyeプラットフォームで実際に監視されているドメインを対象とした2026年第1四半期のスナップショットでは次のようになっています。
p=none のまま留まっており、監視ツールを動かす程度には関与しているにもかかわらず、なりすましに対してまったく保護が効いていません。pct<100 を使っているのは6.2%にとどまります。現象は二つですが、原因は一つです。DMARCには監視と強制の間に機能する中間地点が存在しません。その橋渡しのはずだった仕組み（pct タグ）はくじ引きで、DMARCbisのあとには姿を消します。新しいバイナリのテストフラグは、段階的ロールアウトが本来果たすべきだった役割を肩代わりしてくれません。
ほとんどのドメイン所有者にとって、DMARCbisは火事場のような対応が必要な話ではありません。既存のレコードはそのまま動きますし、受信側の整合性評価が一夜で変わるわけでもありません。普及が進むにつれて頭に入れておきたい実務的な論点がいくつかあります。
pct を段階的ロールアウトに使っている場合：レコード自体は構文的に有効なままですが、DMARCbis準拠の受信側は実質的に pct<100 を pct=100 として扱います。パーセンテージに依存していたのであれば、今のうちに移行計画を立ててください。仕様内でもっとも近い代替はテストモードの t=y ですが、これは確率的な適用ではなく、ポリシーを一段階引き下げる挙動です。p=reject を使わないようにという新しい指針は、真剣に受け止める価値があります。サブドメインを切り出して扱うのが定番のパターンです。p=none のまま長く留まっている場合：DMARCbisは状況を変えません。構造的な問題は仕様にあるのではなく、安全に移行するための橋が欠けていることにあります。DMARCbisはその欠落を公式化しますが、解決はしません。DMARC集約レポートの読み方ガイドとDMARC実装完全ガイドはどちらも、DMARCbisの下でもそのまま通用します。仕様が公開されて変わるのはレコードに書ける内容であって、返ってきたレポートの読み方ではありません。
ご自身のドメインのDMARC設定をご存じですか？下記の無料チェックをお試しください：
あわせて読みたい：第三者送信者のオンボーディング30日間のDMARCプラン
あわせて読みたい：DMARCの段階的ロールアウト：94%の企業が安全機構を使わない理由
急ぎで対応すべきことはありません。DMARCbisのあともDMARCはDMARCですし、今日公開しているレコードは新仕様がRFC化された日にも受け入れられます。移行が求めるのは姿勢の切り替えです。監視から強制への移行は、プロトコルが助けてくれない問題だと前提に置き、そのつもりで計画する、ということです。
集約レポートを監視し、強制適用の前に未知の送信元にフラグを立て、ポリシーを厳しくした場合に何が壊れるかを平易な言葉で伝えてくれるツールは、プロトコルが厳しくなるほど価値を増します。DMARCeyeはまさにこの役割を担うために作られており、無料オンラインツール（DMARC設定ツール、SPF・DKIM・BIMIチェッカー）を使えば設定面は10分以内で確認できます。
仕様が切り替わる前に、自ドメインのDMARCレポートが実際に何を語っているのか確認しましょう。DMARCeyeを無料で試す。