## この記事でわかること - DMARCbis（RFC 7489改訂版）で何が変わるのか、主要な4つの変更点の整理 - `pct`廃止と`t=y`への移行、`np=`タグの新設が実運用に与える影響 - 既存のDMARCレコード（pctを使っている場合）をどう書き換えていくかの移行戦略 ## DMARCbisはまだInternet-Draft（変更可能性あり） DMARC（ディーマーク）の現行仕様は2015年公開の[RFC 7489](https://datatracker.ietf.org/doc/html/rfc7489)です。2026年現在、その改訂版として「DMARCbis」（IETFのドラフト名: `draft-ietf-dmarc-dmarcbis`）の標準化作業が大詰めを迎えており、本体・集計レポート（rua）・失敗レポート（ruf）の3つの関連ドキュメントがRFC Editor Queueに入っています（[draft-ietf-dmarc-dmarcbis](https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/)）。 ただし執筆時点ではまだ正式RFCではないため、最終版で細部が変わる可能性があります。本記事の内容も最新ドラフト（第41版前後）を前提にしており、**緊急の設定変更は不要**です。先回りで知っておきたいWeb 担当者・情シス・制作会社担当者向けに、影響の大きい変更点に絞って整理します。 DMARCそのものの概念や役割は[DMARC とは？仕組みと中小企業が今すぐやるべき対応を 5 分でわかる入門](/blog/what-is-dmarc)、現行のタグ一覧は[DMARCレコードのタグ完全リファレンス](/blog/dmarc-record-tags-reference)をご確認ください。 ## 主要な4つの変更点 DMARCbisで影響の大きい変更を、4つに絞って順に整理します。 ### 変更点1: pctタグの廃止とt=yフラグへの置き換え DMARCbisで最も影響が大きいのが`pct`タグの廃止です。 `pct`は「DMARC失敗メールのうち何%にポリシーを適用するか」を0〜100の整数で指定するタグで、段階的ロールアウト（10→25→50→100%）の安全弁として使われてきました。ただし受信側の実装にばらつきがあり、中間値の精度が出ない、サンプリングが偏るなどの課題が指摘されてきました。実運用でも事実上`pct=0`（テスト）か`pct=100`（本番）の二択でしか使われていない、というのが廃止の背景です。 代わりに導入されるのが`t`タグ（testing flag）の二択化です。 - `t=y`: テストモード。`pct=0`と同等で、ポリシーは適用されずレポートだけ生成される - `t=n`（デフォルト）: 本番モード。`pct=100`と同等で、`p`タグの値どおりに適用される ![旧RFC 7489とDMARCbisの主要変更点対比](/blog/dmarcbis-changes/changes-comparison.svg) 段階的ロールアウトの実務手順や、t=yへの移行準備の詳細は[DMARC pctタグの段階的適用｜割合別の手順](/blog/dmarc-pct-rollout)に整理しています。pctを現在使っている場合の影響評価もこちらでまとめています。 ### 変更点2: np=タグの追加（未使用サブドメイン専用ポリシー） DMARCbisでは新しく`np`タグ（non-existent subdomain policy）が追加されます。これは**「実在しないサブドメイン宛てのメール」に対するポリシー**を、組織ドメイン（apex）や既存サブドメインとは別に指定するためのタグです。 現行RFC 7489でサブドメインのポリシーを制御できるのは`sp`タグだけで、これは「実在する/しないにかかわらず全サブドメイン」を対象にしていました。一方、なりすまし攻撃の多くは`marketing.example.co.jp`のような**実在しないサブドメイン**を詐称してくるパターンが多く、ここに専用の強いポリシー（reject）を当てたいニーズが現場でありました。 DMARCbisでは以下のように使い分けます。 - `p=`: 組織ドメイン（apex）宛てメールへのポリシー - `sp=`: 実在するサブドメイン宛てメールへのポリシー - `np=`（新規）: 実在しないサブドメイン宛てメールへのポリシー たとえば「組織ドメインはquarantine、実在サブドメインも様子見でnone、ただし存在しないサブドメイン詐称は即rejectしたい」場合、以下のような書き方ができます。 ``` v=DMARC1; p=quarantine; sp=none; np=reject; rua=mailto:dmarc@example.co.jp ``` `np=reject`を入れておくだけで、未使用サブドメイン詐称型のなりすましには即時の防御が効きます。サブドメインを多数管理する企業や、子会社・部署別ドメインを使っている場合に特に有効です。`sp`と`np`の違い、そして適切なポリシー組み合わせの考え方は[DMARCのsp / subdomainポリシー徹底解説](/blog/dmarc-sp-subdomain-policy)で詳しく扱っています。 ### 変更点3: rf / ri / fo の扱いと公開鍵情報の整理 失敗レポート（ruf）に関連する補助タグも整理されます。 - `rf=`（report format）: 現行はAFRF/IODEF指定可能だが、IODEFは実装がほぼなく削除予定 - `ri=`（report interval）: 集計レポート（rua）の生成間隔だが、受信側が固定運用のため意味が薄れており、**廃止または非推奨**の方向で議論 - `fo=`（failure reporting options）: 失敗レポート生成の条件指定で、整理対象として議論されている これらは元々「指定しなくてもデフォルトで動く」タグだったため、**ほとんどのサイト運営者では実質的な影響はありません**。現行のDMARCレコードに`rf=`や`ri=`を明示的に書いている場合のみ、運用が落ち着いたタイミングで取り除いておくと将来のメンテナンス負担が減ります。 加えて、現行ではDKIM公開鍵の管理がドメイン側のDNSに分散しており、組織ドメインのDMARCポリシーと整合させづらいという指摘がありました。DMARCbisでは公開鍵情報の整理や、ARC（Authenticated Received Chain）との連携記述も補強されています。ARCの基本は[ARCとは？転送メールの認証を救う仕組み](/blog/arc-what-is)で扱っています。 ### 変更点4: PSL依存からの脱却（Tree Walk方式の導入） 技術的に大きな変更が、組織ドメインの判定ロジックの見直しです。 現行RFC 7489では「組織ドメイン」を判定するために[Public Suffix List（PSL）](https://publicsuffix.org/)に依存しています。例えば`marketing.example.co.jp`のDMARCポリシーを引くとき、PSLを参照して`example.co.jp`を組織ドメインと判定し、そのDMARCレコードを取得する仕組みです。 ただしPSLはコミュニティ運営のリストで、IETFの正式な標準ではありません。DMARCbisではこの依存を緩和するため、DNSを段階的に上にたどって最初に見つかったDMARCレコードを使う**Tree Walk方式**を導入します。具体的には、サブドメインのDMARCレコードがなければ1段階上、それでもなければさらに上、と最大4〜5段階たどる動作になります。 ![pct→t=yへの移行フロー](/blog/dmarcbis-changes/migration-flow.svg) 運用観点では、**組織ドメイン直下にDMARCレコードを1本きちんと置いておけば従来どおり動く**ため、設定変更は基本的に不要です。サブドメイン直下にDMARCレコードを別途置いている場合は、Tree Walk導入後の挙動を一度確認しておくと安心です。 ## 既存DMARC設定の移行戦略 ここまでの変更を踏まえた、既存DMARCレコードの移行方針を整理します。 | 現状 | 推奨アクション | |---|---| | `pct=`を書いていない（または100） | 何もしない。DMARCbis後もそのまま動く | | `pct=0`〜`pct=99`を書いている | 運用が安定したら`pct`を取り除く。新規書き換え時は`t=y`/`t=n`への置き換えを検討 | | `sp=`を書いていない | 機会を見て`sp`と`np=reject`を併記。未使用サブドメイン詐称への防御が強化される | | `rf=`/`ri=`/`fo=`を明示している | 必要性を再確認し、不要なら取り除く | | サブドメイン直下にDMARCを置いている | Tree Walk導入後の挙動を確認。多くは引き続き動作するが念のため | 繰り返しですが、DMARCbisはまだInternet-Draftで、**正式RFC公開後も既存設定はおおむね互換動作**するため、緊急の書き換えは不要です。次回のDMARC見直しタイミング（ポリシー強化や送信元変更時）に合わせて、上記の整理を進めるのが現実的です。 ## 自社の状況を確認してみませんか 設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。 DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。 判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。