DMARCbis 概要
DMARCbis ドキュメントセクションへようこそ。ここでは、DMARC 標準が最初に公開されて以来最も重要な更新である DMARCbis の概要を紹介します。
DMARCbis とは何ですか？
DMARCbis は、DMARC（Domain-based Message Authentication, Reporting, and Conformance）の改訂版です。「bis」という呼称は、プロトコル改訂版に関する標準的な命名規則に従っています。
元の DMARC 仕様（RFC 7489）は 2015 年に「Informational（参考情報）」文書として公開されましたが、DMARCbis は「Proposed Standard（標準化提案）」として発行されています。これにより、DMARC の正式な位置づけは、10 年以上にわたる導入実績に基づいた、実証済みで広く採用されているメール認証プロトコルへと引き上げられます。
DMARCbis は、以下の点で元の標準を強化しています。
- 仕様をより明確で詳細なドラフトに分割し、追加の例を提供する
- 手動で管理されるリストの代わりに DNS ネイティブな検索を使用して、組織ドメインの境界を判定する方法を改善する
- 一貫性のないレガシー要素を削除してポリシータグを簡素化する
- 可視性とセキュリティを向上させるためにレポート要件を強化する
重要な点として、DMARCbis は後方互換性を維持しています。 バージョン識別子として引き続き v=DMARC1 を使用するため、既存の DMARC レコードは即座に変更を加えなくても有効なままです。組織は新機能を段階的に導入することができます。
DMARCbis における主な変更点
仕様の再構成
更新された標準は、3 つの独立したドラフトに分割されています。
- コアプロトコル — DMARC の基本を定義する
- 集約レポート（Aggregate reporting） — 日次レポートの生成方法とフォーマットを説明する
- フォレンジックレポート（Forensic reporting） — 認証失敗情報の報告方法を詳述する
この分割により、標準は理解、実装、そして長期的な保守がしやすくなります。
DNS Tree Walk アルゴリズム
最も重要な技術的変更は、ドメインの組織境界を見つけるために、Public Suffix List（PSL）を DNS Tree Walk アルゴリズムに置き換えることです。
手動で管理される公開リストに頼る代わりに、受信者はドメイン階層を一つずつラベル単位で上へたどりながら順次照会し、psd=y（public suffix domain）または psd=n（組織境界）とマークされた DNS レコードが見つかるまで検索を続けます。
- 過剰な DNS クエリを防ぐため、探索は最大 8 階層に制限されています。
- 8 つ以上のラベルを持つドメインの場合、探索を開始する前に、左端のラベルを 7 つになるまで削除します。
- 探索は、明示的な
psd値を持つ有効な DMARC レコードが見つかった時点で停止します。
この DNS ネイティブなアプローチにより、サードパーティのリストへの依存がなくなり、境界の変更がより一貫して反映されやすくなるとともに、ドメイン境界検出全体の精度が向上します。
注: 移行期間中は、一部の受信者が引き続き PSL を使用する一方で、他の受信者が Tree Walk を使用する場合があり、同じドメインに対して異なる結果が生じることがあります。すべてのドメインおよびサブドメインに（該当する場合は
psdタグを含めて）明示的な DMARC レコードを公開することで、この曖昧さを回避できます。
新しいポリシータグ
DMARCbis は、よりきめ細かい制御を可能にする 3 つの新しいタグを導入しています。
| Tag | Purpose |
|---|---|
psd（Public Suffix Domain） | y はそのドメインを public suffix domain として、n は組織ドメインとしてマークします。デフォルトの u では、判定は Tree Walk に委ねられます。 |
np（Non-Existent Subdomain Policy） | DNS 上に存在しないサブドメインを送信元と称するメールに適用されるポリシーを設定します。攻撃者が ceo.example.com のような架空のサブドメインを使用するなりすましの抜け穴を塞ぎます。 |
t（Testing Mode） | ポリシーが試験運用中でまだ適用されていないこと（y）、または通常どおり適用されていること（デフォルトの n）を示します。 |
廃止されたレガシータグ
3 つのタグは、受信者間で一貫性のない結果をもたらすため廃止されました。
pct（percentage） — より明確なt（Testing Mode）タグに置き換えられましたrf（report format）ri（report interval） — レポートの頻度は、設定可能にする代わりに一律に定義されるようになりました
これらのタグは、後方互換性のために設定されている場合は引き続き公開されますが、DMARCbis に対応した受信者は今後ますますその代替タグに依存するようになります。
レポート機能の強化
集約レポートとフォレンジックレポートは、それぞれ独自の仕様ドラフトを持つようになり、一貫性とセキュリティに関するより厳格な要件が課されています。
- 外部レポート送信先アドレスの検証が必須化（
rua=/ruf=の受信者は、送信ドメイン外に送られるレポートを許可する必要があります） - 添付ファイルのフォーマットと命名規則の標準化
- XML 構造と gzip 圧縮のより厳格な適用
メーリングリストに関するガイダンス
DMARCbis は、メーリングリストと転送メールに関する明確なガイダンスを提供しています。メーリングリストが通常のメールフローの一部である場合、リストソフトウェアが SPF と DKIM の整合性の両方を頻繁に損なうため、正当なメッセージが拒否される可能性があることから、p=reject ポリシーの公開は推奨されません。
同時に、DMARCbis は、ドメインを不正利用から完全に保護できる唯一のポリシーであることから、可能な限り p=reject ポリシーの達成に向けて取り組むことをドメイン所有者に引き続き推奨しています。厳格な適用に移行する前に、メーリングリストを含む自社のメールエコシステムを評価することが推奨されます。
主な利点
- DNS Tree Walk アルゴリズムによる、より正確な組織ドメインの検出
- 曖昧さのないテスト信号を備えた、よりシンプルで明確なポリシータグ
- 存在しないサブドメインのなりすましに対するより強力な保護
- 複雑なドメイン構造や public suffix domain へのより優れた対応
- レポートの一貫性とセキュリティの向上
- 強制的な移行なし — 既存のレコードは有効なまま、自分のペースで新機能を導入できます
FAQs
DMARCbis のために現在の DMARC レコードを変更する必要がありますか？
即座の変更は必要ありません。DMARCbis は同じバージョン識別子（v=DMARC1）を維持しているため、既存のレコードは有効なままです。時間をかけて新しいタグを段階的に導入し、メール認証を強化していくことができます。
DNS Tree Walk は Public Suffix List と比べてどのように改善されていますか？
手動で管理される public suffix のリストに頼る代わりに、Tree Walk は DNS に直接問い合わせを行い、ドメイン階層を上へたどりながら正しい組織境界を特定します。これは、サードパーティがリストを最新の状態に保つことに依存しないため、より一貫性があります。
DMARCbis がメーリングリストに関して p=reject を推奨していないなら、今それを設定すべきですか？
DMARCbis は p=reject を全面的に非推奨としているわけではありません。メーリングリストが SPF/DKIM の整合性を損なう可能性があるため、メーリングリストがメールフローの一部である場合に限り、注意を促しているだけです。厳格な適用に移行する前に、自社ドメインのメールが実際にどのように送信・転送されているかを確認してください。