DMARCbisとは｜RFC 7489改訂の変更点

この記事でわかること

• DMARCbis（RFC 7489改訂版）で何が変わるのか、主要な4つの変更点の整理
• pct廃止とt=yへの移行、np=タグの新設が実運用に与える影響
• 既存のDMARCレコード（pctを使っている場合）をどう書き換えていくかの移行戦略

DMARCbisはまだInternet-Draft（変更可能性あり）

DMARC（ディーマーク）の現行仕様は2015年公開のRFC 7489です。2026年現在、その改訂版として「DMARCbis」（IETFのドラフト名: draft-ietf-dmarc-dmarcbis）の標準化作業が大詰めを迎えており、本体・集計レポート（rua）・失敗レポート（ruf）の3つの関連ドキュメントがRFC Editor Queueに入っています（draft-ietf-dmarc-dmarcbis）。

ただし執筆時点ではまだ正式RFCではないため、最終版で細部が変わる可能性があります。本記事の内容も最新ドラフト（第41版前後）を前提にしており、緊急の設定変更は不要です。先回りで知っておきたいWeb 担当者・情シス・制作会社担当者向けに、影響の大きい変更点に絞って整理します。

DMARCそのものの概念や役割はDMARC とは？仕組みと中小企業が今すぐやるべき対応を 5 分でわかる入門、現行のタグ一覧はDMARCレコードのタグ完全リファレンスをご確認ください。

主要な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タグの値どおりに適用される

段階的ロールアウトの実務手順や、t=yへの移行準備の詳細はDMARC pctタグの段階的適用｜割合別の手順に整理しています。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:[email protected]

np=rejectを入れておくだけで、未使用サブドメイン詐称型のなりすましには即時の防御が効きます。サブドメインを多数管理する企業や、子会社・部署別ドメインを使っている場合に特に有効です。spとnpの違い、そして適切なポリシー組み合わせの考え方はDMARCのsp / subdomainポリシー徹底解説で詳しく扱っています。

変更点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とは？転送メールの認証を救う仕組みで扱っています。

変更点4: PSL依存からの脱却（Tree Walk方式の導入）

技術的に大きな変更が、組織ドメインの判定ロジックの見直しです。

現行RFC 7489では「組織ドメイン」を判定するためにPublic Suffix List（PSL）に依存しています。例えばmarketing.example.co.jpのDMARCポリシーを引くとき、PSLを参照してexample.co.jpを組織ドメインと判定し、そのDMARCレコードを取得する仕組みです。

ただしPSLはコミュニティ運営のリストで、IETFの正式な標準ではありません。DMARCbisではこの依存を緩和するため、DNSを段階的に上にたどって最初に見つかったDMARCレコードを使うTree Walk方式を導入します。具体的には、サブドメインのDMARCレコードがなければ1段階上、それでもなければさらに上、と最大4〜5段階たどる動作になります。

運用観点では、組織ドメイン直下に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見直しタイミング（ポリシー強化や送信元変更時）に合わせて、上記の整理を進めるのが現実的です。

自社の状況を確認してみませんか

設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSLの状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。