DMARCbisの解説 変更点と準備のポイント

DMARCbisで何が変わる？主要な変更点と移行の準備を徹底解説

2025年5月20日
著者: Yunes Tarada
翻訳: 古川 綾乃

この記事はPowerDMARCのブログ記事 DMARCbis Explained – What’s Changing and How to Prepareの翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。

DMARC（ドメインベースのメッセージ認証・レポート・適合）は、公開以来初めて大幅な改訂が予定されています。
DMARCbisとして知られる改訂版仕様は現在もドラフト段階ですが、メール認証における長年の課題を解決することを目的としています。
本記事では、主な変更点と準備のポイントを整理します。

現在のステータス

Internet-Draft（インターネットドラフト）

フェーズ

Last Call（ラストコール）

公開予定日

未定

廃止されるRFC

RFC 7489およびRFC 9091（承認された場合）

ソース

DMARCbisドラフト

主なポイント

1. DMARCbisは、明確性と整合性の向上を目的とした、DMARCの後継となる改訂版仕様です。
2. 組織ドメインを識別する方法として、パブリックサフィックスリスト（PSL）への依存を見直し、より信頼性の高い方式（DNS階層を上位に向かって探索する方式）を採用します。
3. pct、rf、riといったタグは、実装を簡素化し混乱を減らすために、非推奨（廃止予定）となります。
4. psd、np、tなどの新しいタグが追加されます。
   これにより、パブリックサフィックスドメインを明確に定義できるようになり、ポリシー継承の管理もしやすくなります。
5. DMARCレコードのバージョンは、後方互換性を保つために、v=DMARC1のまま変更されません。
6. 組織ドメイン（ベースドメイン）に有効なDMARCレコードがある既存設定は、直ちに変更しなくても、そのまま利用できます。
7. PowerDMARCなどの管理ツールを使うと、レコード管理の自動化、専門的なガイダンスの提供、すべてのドメインにわたる可視性の確保により、移行を簡素化できます。

DMARCbisとは何か。

DMARCbisは、DMARC仕様の改訂版（後継仕様）であり、IETF（Internet Engineering Task Force）によって策定されています。
RFC 7489およびRFC 9091をベースにしつつ、承認されればそれらを置き換える形となり、プロトコル内で曖昧だった点を明確化する改訂が導入されます。
従来のDMARCが情報提供目的のRFCであったのに対し、DMARCbisは提案標準（Proposed Standard）として公開される予定です。

つまり、より広い合意を経た仕様であり、業界での採用を想定していることを意味します。
DMARCbisは主に、明確性、セキュリティ、およびドメイン整合性（アライメント）の扱いをより厳密にすることに重点を置いています。
また、仕様の改訂はあるものの、後方互換性を維持するために、v=DMARC1タグは変更されていません。

1. DNSツリーウォークによるPSL依存の見直し

パブリックサフィックスリスト（PSL）は組織ドメイン判定に長く使われてきましたが、DMARCbisではPSLへの依存を見直し、DNS上で完結するツリーウォーク方式に置き換えられます。
DNSツリーウォークアルゴリズムは、ドメイン階層を上位へ順にたどって有効なDMARCレコード（ポリシーレコード）を探し、psd=y（パブリックサフィックスドメイン）またはpsd=n（組織ドメイン）を含む有効なDMARCポリシーレコードが見つかった時点で探索を打ち切ることで、受信側は外部リストに依存せず組織ドメインを判断できます。
そのようなポリシーが見つからない場合、探索は最大8階層まで継続されます。

2. 非推奨となるタグ

プロトコルを簡素化するため、以下のタグは非推奨となります（廃止予定）。

• pct（ポリシー適用率を指定するタグ）
• rf（レポート形式）
• ri（レポート間隔）

3. 新規および更新されたタグ

新しいpsdタグはパブリックサフィックスドメインを明確に定義し、DNSツリーウォークにおけるポリシー継承をドメイン所有者が制御できるようにします。
tタグは、ドメイン所有者がテスト段階でありポリシー（p、sp、np）を完全に強制したくない可能性があることを受信側に示す目印ですが、DMARCレポート生成方法は変更せず、すでにnoneに設定されているポリシーにも影響しないうえ、受信側が考慮するかどうかは任意です。
また、新しいnpタグ（non-existent policy）は、DNS上で解決できない存在しないサブドメインに適用するDMARCポリシーを指定します。

4. 「完全実装（Full Participation）」の要件

ドメイン所有者および受信側がDMARCを完全にサポートするとはどういうことかを定義する新しいガイドラインが示されます。
これにより、期待値が明確化されるとともに、実装の互換性が向上します。

5. 仕様文書の構成改善

仕様文書は再構成され、例の追加や用語の明確化、レイアウトの整理が行われます。
その結果、すべての関係者にとって実装しやすい仕様になります。

既存のDMARC運用への影響

DMARCbisの更新は後方互換性があり、RFC 7489に準拠した既存の運用には影響しません。
また、新しいタグは任意であるため、現在の設定を変更する必要はありません。
ただし、設定をより適切に保つ目的でレコードの監査は推奨されますが、DMARCが正しく設定されている場合、直ちに対応する必要はありません。

DMARCbisへの準備方法

変更内容は互換性を大きく損なうものではありませんが、将来を見据えてメールセキュリティ体制を強化するために、組織として早めに準備を始めておくことが重要です。
以下に、準備のポイントをまとめます。

DMARCレコードを確認しましょう

現在のDMARCレコードを見直し、将来的に非推奨となるpctやrfなどのタグが含まれていないことを確認してください。
あわせて、ベース（組織）ドメインに有効なDMARCポリシーが設定されていることも確認しましょう。

ツリーウォーク方式を理解しましょう

新しい階層ベースの仕組みにおいて、サブドメインが期待どおりにポリシーを継承するかを確認してください。
サブドメインが多い場合や運用が複雑な場合は、DNSツリーウォークの探索手順をシミュレーションし、挙動を検証しておくと安心です。

psdタグの利用を検討しましょう

ドメイン構造上必要な場合に備えて、psd=nまたはpsd=yを使い、ドメイン境界を明示的に定義する方法を理解しておきましょう。

関係チームに周知しましょう

メールおよびセキュリティを担当するチームが今後の変更点を把握し、認証や到達率への影響を理解している状態を作っておくことが重要です。

PowerDMARCでできること

PowerDMARCは、自動化・可視化・専門的な支援を組み合わせることで、組織がDMARCbisへ移行する際の負担を減らすのに役立ちます。

1. 一元化されたメール認証ダッシュボードを通じて、DMARC、SPF、DKIMの設定・運用を効率化します。
2. レポートを分かりやすく整理することで、メールの送信元や認証状況を横断的に把握できます。
3. ポリシー更新やレコード最適化を支援するクラウド型サービスを提供します。
4. 変更点や運用上の課題に対応できるよう、専門チームによるサポートを提供します。

DMARC運用の見直しや移行準備を進めたい場合は、是非お問い合わせください。

まとめ

DMARCbisは、特にサブドメインごとにDMARCポリシーを個別に管理したい場合に、より高い柔軟性と明確性、そして管理のしやすさを提供します。
緊急の対応は必要ありませんが、より適切なドメイン認証管理のために、必要な準備を少しずつ進めておくとよいでしょう。