IETF DMARCワーキンググループでの長年の作業を経て、待望のDMARC標準の更新版が公開されました。3つの新しい文書、RFC 9989、RFC 9990、RFC 9991が、2015年のオリジナルRFC 7489を正式に置き換えました。これらは総称してDMARCbisと呼ばれています。

新しい仕様は2026年5月に公開され、DMARCは以前の情報提供ステータスからIETF標準トラック上の提案標準へと移行しました。これにより、DMARCはインターネット標準スタックにおいてより強固で正式な位置を得ることになりました。

I. 各RFCの対象範囲

DMARC仕様は、1つの大きなファイルではなく、3つの焦点を絞った文書に分割されました:

• RFC 9989: ポリシー評価、識別子アライメント、レコード処理、DNSツリーウォーク手順を含む、コアDMARCプロトコルを定義します。
• RFC 9990: RUAレポートとしても知られる、DMARC集約レポートを定義します。
• RFC 9991: フォレンジックレポートとも呼ばれるDMARC失敗レポートを定義し、受信システムがサポートする場合、認証失敗に関するメッセージレベルの詳細を提供できます。

この分割により、標準の実装、保守、参照が容易になります。

II. 既存のDMARCレコードは引き続き有効です

これはドメイン所有者にとって破壊的な変更ではありません。

DMARCレコードは依然として以下で始まります:

v=DMARC1

DMARCデプロイメントを再構築したり、すべてのレコードを即座に再公開したりする必要はありません。既存のレコードは有効なままですが、この更新は設定を見直し、古い動作を削除し、監視プラットフォームが新しい仕様をサポートしていることを確認する良い機会です。

III. 主な技術的変更

セキュリティチーム、DNS管理者、メール認証プラットフォームにとって重要ないくつかの変更があります。

DNSツリーウォークが公開サフィックスリストへの依存を置き換え

DMARCbisは、組織ドメインの発見のために外部で管理される公開サフィックスリストへの依存を、DNSツリーウォーク手順に置き換えました。

受信者は、DNS階層を上位に辿り、各レベルで関連する_dmarcレコードを探すことができるようになりました。これにより、サードパーティリストへの依存が減り、複雑なドメイン構造、委任されたドメイン、公開サフィックスドメイン運営者の処理が改善されます。

新しいタグ:np、psd、t

RFC 9989はDMARCタグレジストリを更新し、以下のアクティブなサポートを導入しました:

• np: 存在しないサブドメインのポリシー。
• psd: 公開サフィックスドメインの処理。
• t: テストフラグ、テスト用のt=yと通常動作用のt=n。

npタグは、大規模または複雑なドメインフットプリントを持つ組織にとって特に重要です。なぜなら、存在しないサブドメインに対するなりすまし試行への対処に役立つからです。

歴史的タグ:pct、rf、ri

RFC 9989は、いくつかの古いタグを歴史的なものとしてマークしています:

• pct
• rf
• ri

pctタグは元々、段階的なポリシー展開をサポートすることを目的としていましたが、受信者間での実装は一貫性がありませんでした。DMARCbisは、このアプローチをtタグによるより明確なテスト動作に置き換えています。

組織は、既存のDMARCレコードに歴史的タグがないか確認し、適切な場合はクリーンアップを計画すべきです。

転送とメーリングリストに関するより明確なガイダンス

転送やメーリングリストなどの間接的なメールフローは、正当なメッセージであってもSPFやDKIMアライメントが失敗する可能性があるため、DMARCにとって依然として困難です。

DMARCbisは、これらの実世界のシナリオに関してより明示的なガイダンスを提供しています。これが重要なのは、多くの本番環境での失敗が悪意のあるメールによって引き起こされるのではなく、ルーティング、ヘッダー、または認証コンテキストを変更するシステムを通過する正当なメールによって引き起こされるからです。

より明確に定義された適合性

更新された仕様は、DMARC参加と実装動作に関するより明確な定義を提供しています。

これにより、送信者、受信者、ベンダー間での一貫性のない解釈が減少するはずです。組織にとっては、ツールやプロバイダーが実際に現在のDMARC標準に準拠しているかどうかを尋ねることも容易になります。

IV. RFC 9989:コアDMARCプロトコル

RFC 9989は、主要なDMARC仕様としてRFC 7489を置き換えます。

コアプロトコルを定義し、以下を含みます:

• DMARCポリシーの発見。
• レコード処理。
• 識別子アライメント。
• ポリシー評価。
• DNSツリーウォーク動作。
• 更新されたタグ処理。
• 適合性の期待。

ポリシーの発見と継承

RFC 9989は、ドメイン階層全体でDMARCポリシー発見がどのように機能するかを明確にしています。

これは、多数のサブドメイン、委任されたドメイン、または地域ドメインを持つ組織にとって重要です。明確なポリシー発見がなければ、チームは、受信者が期待されるポリシーを発見または適用していないときに、ドメインが保護されていると信じる可能性があります。

識別子アライメント

DMARCは依然として識別子アライメントに依存しています。

メッセージがDMARCに合格するのは、以下の少なくとも1つが真である場合のみです:

• SPFが合格し、SPF認証ドメインが表示されるFromドメインとアライメントする。
• DKIMが合格し、DKIM署名ドメインが表示されるFromドメインとアライメントする。

SPFが合格するだけでは、DMARCが合格することを意味しません。DKIMが合格するだけでは、DMARCが合格することを意味しません。アライメントこそが、認証を受信者が見るドメインに結びつけるものです。

DNSツリーウォーク

DNSツリーウォークは、RFC 9989における最も重要な運用上の変更の1つです。

組織ドメインを決定するために公開サフィックスリストに依存する代わりに、受信者はドメイン階層を通じてDNSルックアップを使用して、適用可能なDMARCポリシーを発見します。

これにより、複雑な委任モデルと公開サフィックスドメインシナリオを処理する標準の能力が向上します。

V. RFC 9990:集約レポート

RFC 9990は、DMARC集約レポート形式を定義しています。

集約レポートは、ドメイン所有者にメールエコシステム全体でドメインがどのように使用されているかを可視化します。これらのレポートには通常、以下が含まれます:

• ソースIPアドレス。
• 認証結果。
• アライメント結果。
• ポリシーディスポジション。
• 送信量。
• レポート組織。

専用の集約レポートRFCは、実装間の一貫性を改善し、ベンダーとドメイン所有者がレポート動作を解釈しやすくするはずです。

セキュリティチームにとって、集約レポートは正当な送信者を発見し、不正なソースを特定し、DMARC実施の進捗を監視する最も有用な方法の1つであり続けます。

VI. RFC 9991:失敗レポート

RFC 9991は、DMARC失敗レポートを専用の標準トラック仕様として定義しています。

失敗レポートは、受信者の実装とプライバシー管理に応じて、認証失敗に関するメッセージレベルの詳細を提供できます。

これらのレポートはトラブルシューティングと脅威調査に役立ちますが、慎重に扱う必要があります。失敗レポートには機密メタデータが含まれる可能性があり、実装によっては、メッセージヘッダーやコンテンツ要素が含まれる場合があります。組織は、失敗レポートを有効化または依存する前に、プライバシー、量、保持、アクセス制御を検討する必要があります。

すべての受信者が失敗レポートを送信するわけではありません。セキュリティチームは、これらを補助的なシグナルとして扱い、完全な監視ソースとして扱うべきではありません。

VII. ドメイン所有者が行うべきこと

ドメイン所有者はDNSレコードを慌てて編集する必要はありませんが、更新された仕様に照らしてDMARCの態勢を見直すべきです。

実用的なレビューには以下を含めるべきです:

• すべてのDMARCレコードが依然としてv=DMARC1を使用していることを確認する。
• pct、rf、riなどの歴史的タグを特定し、クリーンアップを計画する。
• 存在しないサブドメインの保護にnpタグが関連するかどうかを検討する。
• サブドメインがどのように保護されているかを確認する。
• サードパーティ送信者が適切にアライメントされているかを確認する。
• 集約レポートの可視性を確認する。
• DMARCプラットフォームがRFC 9989、RFC 9990、RFC 9991をサポートしていることを確認する。
• ベンダーがDNSツリーウォークポリシー発見をどのように処理するかを尋ねる。
• 失敗レポートが組織にとって有用、適切、かつプライバシー面で安全かどうかを確認する。

目標は緊急の移行ではありません。目標は、現在のDMARC標準との制御された整合です。

VIII. DMARCプラットフォームがサポートすべきこと

DMARCbis対応は、ドメイン所有者だけの問題ではありません。DMARCを管理または監視するプラットフォームも適応する必要があります。

DMARCbis対応プラットフォームは以下をサポートすべきです:

• RFC 9989コアプロトコル動作。
• DNSツリーウォークベースのポリシー発見。
• np、psd、tの解析と解釈。
• pct、rf、riなどの歴史的タグの認識。
• RFC 9990集約レポートの取り込みと分析。
• 有効な場合のRFC 9991失敗レポートの処理。
• 認証とアライメントの明確な区別。
• サブドメインと委任されたドメイン全体の可視性。
• 受信者実装の進化に伴う更新された適合動作。

プラットフォームが更新されたタグやレポート動作を解釈できない場合、セキュリティチームは重要な認証変更に関する可視性を失う可能性があります。

IX. Skysnag Protectがどのように役立つか

Skysnag Protectは、受信者実装の進化に伴い、更新されたレコード分析、レポートの可視性、ポリシー監視をサポートすることで、組織がDMARCbisに備えるのを支援します。

プラットフォームは、組織が以下を行うのを支援するように設計されています:

• DMARC実施態勢を監視する。
• SPFおよびDKIMアライメントを追跡する。
• 正当および不正な送信元を特定する。
• ドメインとサブドメイン全体で可視性を維持する。
• 集約レポートの動作を解釈する。
• 更新されたDMARCタグ処理をサポートする。
• DNSツリーウォークベースのポリシー発見に備える。
• 継続的なDMARC管理における手動の複雑さを軽減する。

業界がRFC 9989、RFC 9990、RFC 9991を採用するにつれて、組織は不要な運用の混乱を強制することなく、標準に対応するツールを必要とします。

X. 移行と適合性の考慮事項

DMARCbisは新しいプロトコルではありません。10年以上の運用経験に基づいた、より明確で標準トラック版のDMARCです。

組織は、この更新を構造化されたレビューポイントとして扱うべきです:

レコードをレビュー

歴史的タグ、一貫性のないサブドメインポリシー、不足しているレポートアドレス、ポリシー展開に関する時代遅れの前提がないか確認します。

送信者をレビュー

すべての正当な送信者がアライメントされたSPFまたはアライメントされたDKIMに合格できることを確認します。これは、マーケティングプラットフォーム、CRM、チケットシステム、ヘルプデスクツール、その他のサードパーティサービスにとって特に重要です。

レポートをレビュー

集約レポートが正しく処理されていること、および失敗レポートが適切なプライバシーとアクセス制御で処理されていることを確認します。

ベンダーをレビュー

メールセキュリティベンダーに、DNSツリーウォークポリシー発見と更新されたタグ解釈を含むRFC 9989、RFC 9990、RFC 9991をサポートしているかどうかを尋ねます。

XI. 最後に

DMARCbisは同じDMARCですが、より明確で、より正式で、メールが実際にどのように動作するかとより良く整合しています。

RFC 9989、RFC 9990、RFC 9991の公開は、ドメイン所有者がレコードを見直し、送信者のアライメントを検証し、サブドメインのカバレッジを確認し、ツールが現在の標準に対応していることを確認する良いきっかけです。

ブランド保護、フィッシング防止、メール信頼に責任を持つ組織にとって、この変更は破壊的ではありません。実装品質を改善する機会です。

XII. 重要なポイント

• RFC 9989は、コアDMARCプロトコル仕様としてRFC 7489を置き換えます。
• RFC 9990は、DMARC集約レポートを定義します。
• RFC 9991は、DMARC失敗レポートを定義します。
• 既存のDMARCレコードは依然としてv=DMARC1を使用します。
• DNSツリーウォークは、ポリシー発見のための公開サフィックスリストへの依存を置き換えます。
• RFC 9989は、np、psd、tのアクティブなサポートを導入します。
• pct、rf、riは現在、歴史的タグです。
• DMARCbisは、DMARCの基本的な目的を変更するのではなく、明確性と実装の一貫性を改善します。
• 組織は、レコード、サブドメイン、送信者、レポート、ベンダーの準備状況を見直すべきです。

メール認証プログラムをDMARCbisに整合させる準備はできていますか? Skysnag Protectを で探索してください。