主なポイント
- 新しい標準により、公開済みのDMARCポリシーを慎重に見直すことが求められます。
- ポリシー継承の動作が大きく変更されるだけでなく、「組織ドメイン（organizational domain）」の判定方法も変更されます。
- 送信者に対する要件が厳格化されるため、組織にはDMARCの完全な適用と、すべてのメール送信元に対する可視性の向上がこれまで以上に求められます。
メール認証は次の段階へと進みつつあります。ドメイン保護やフィッシング対策の基盤として長年利用されてきたDMARCは、新たな仕様策定を通じてアップデートが進められています。これらの変更は、長年残されてきた課題を解消するとともに、現代のメールエコシステムとの整合性を高め、大規模環境においてもより信頼性の高いポリシー適用を実現することを目的としています。
セキュリティ部門や製品部門のリーダーにとって、これは単なる標準仕様の更新ではありません。ドメイン保護を強化し、なりすましのリスクを低減するとともに、可視性を向上させる絶好の機会です。ここでは、押さえておくべきポイントをご紹介します。
DMARC の仕様が約10年ぶりに改訂
2026年5月、DMARCの仕様は約10年ぶりに大きく改訂されました。これまで広く利用されてきたRFC 7489に代わり、以下の3つのRFCが新たな標準仕様として公開されています。
- RFC 9989：DMARC本体の仕様
- RFC 9990：DMARC Aggregate Reporting（集計レポート）
- RFC 9991：DMARC Failure Reporting（失敗レポート）
多くの企業では既存のDMARCレコードはそのまま利用できます。今回の変更は、既存設定を大きく変更するものではなく、標準仕様の明確化やレポート形式の改善、実装の一貫性向上が中心です。
RFC 9989：DMARC本体の仕様
新しい仕様は、従来のDMARC RFC 7489を基盤としつつ、曖昧だった動作を明確化し、受信側での解釈を標準化するとともに、10年以上にわたる運用経験を反映した改善を取り入れています。
SPF/DKIMのアライメントやDMARCポリシー適用という基本原則は維持される一方で、RFC 9989では、以下の点に重点を置いてDMARCを進化させています。
- レポート機能の改善：一貫性、構造、プロバイダーによる解釈について、より明確な要件を定義します。
- サブドメインのなりすまし対策の強化：組織ドメインのより正確な取り扱いや、サブドメインポリシーの適用方法を改善します。
- 組織ドメイン検出の標準化：一貫性のない実装やプロバイダー固有の検索動作への依存を低減します。
- アライメント判定ロジックの明確化：特に、緩和（relaxed）アライメントと厳格（strict）アライメントの取り扱いを明確にします。
- 間接的なメール配送経路への対応を一貫化：メール転送、メーリングリスト、その他の中継配送経路について、より一貫した取り扱いを実現します。
- 実装上の曖昧さを低減：メールボックスプロバイダー、送信者、セキュリティベンダー間での実装のばらつきを抑えます。
RFC 9990：DMARC Aggregate Reporting（集計レポート）
DMARC RFC 9990は、一般的にRUAタグに関連付けられている集計レポート（Aggregate Reporting）を定義した仕様です。
主なポイントは以下のとおりです。
- 集計レポートが独立したRFCに：RUAレポートはDMARC本体の仕様から切り離され、RFC 9989とは独立して進化できるようになりました。
- レポート形式がより整理され、一貫性が向上：RFC 9990ではXML名前空間とスキーマが正式に定義され、レポートの解析や標準化が容易になりました。
- レポートにはDMARC RFC 9989に対応した新しい情報が追加：discovery method、np、testingなどの新しいフィールドが追加され、RFC 9989で導入された変更内容が反映されています。
- レポートの運用上の有用性が向上：DKIMの結果を報告する際にはDKIMセレクターの記載が必須となり、レポートIDも正式に規定されました。また、各レポートは1つのDMARCポリシードメインのみを対象とします。
- PSDレポートがサポート：これまで実験的な位置付けだったPublic Suffix Domain（PSD）レポートが、集計レポートの標準仕様に組み込まれました。
RFC 9991：DMARC Failure Reporting（失敗レポート）
DMARC RFC 9991は、RUFタグに関連付けられている失敗レポート（Failure Reporting）を定義した仕様です。
主なポイントは以下のとおりです。
- 失敗レポートが独立したRFCに：RUFレポートはDMARC本体の仕様から分離され、専用の標準化文書（Standards Track）として公開されました。
- RUFレポートではメッセージ単位の詳細情報を取得可能：集計レポートとは異なり、失敗レポートはDMARC認証に失敗した個々のメッセージを調査するために設計されています。
- レポート形式がより明確に定義：RFC 9991ではARFベースの失敗レポート構造が更新され、DMARC認証失敗時の必須項目および任意項目が定義されています。
- 外部の送信先は検証が必要：サードパーティーのRUF送信先では、集計レポートと同様の一般的な検証モデルが適用されます。
- プライバシー保護と悪用防止が重視：RUFレポートにはヘッダー情報、メッセージ本文、個人データが含まれる可能性があるため、RFC 9991では慎重な運用、情報のマスキング、安全な転送、レート制限の重要性が強調されています。
注目すべき主な変更点
DMARC RFC 9989では、メールボックスプロバイダーごとのDMARCポリシーの解釈や適用方法のばらつきを抑えることで、ポリシー評価の一貫性が向上します。これにより、送信者にとって認証結果がより予測しやすくなり、受信環境によって認証結果が異なるという一般的な問題も軽減されます。
また、アライメントの定義も見直され、組織ドメインの照合方法、サブドメインポリシーの継承方法、複雑なメールフローにおけるアライメント評価について、より明確な指針が示されています。これらの明確化は、複数のドメインやサードパーティーのメール送信サービスを管理する大規模企業にとって特に重要です。
レポート機能も改善されています。DMARC RFC 9989では、集計レポートと失敗レポートの両方について、フォーマットや要件を標準化することで、プロバイダー間の相互運用性を向上させています。その結果、不正な形式や一貫性のないレポートが減少し、自動化や分析をより効果的に実施できるようになります。
さらに、この仕様では、間接的なメール配送経路に関する長年の課題にも対応しています。これまでメール転送サービスやメーリングリストはDMARC認証を妨げる要因となっていましたが、DMARC RFC 9989では中継事業者向けのより適切な指針が示され、こうしたメールフローでも認証情報が維持される可能性が高まります。
最後に、DMARC RFC 9989では国際化への対応も強化されています。国際化ドメイン名（IDN）の利用が拡大する中、更新された仕様では非ASCIIドメインの取り扱いがより明確に定義され、グローバルなメールエコシステム全体で、より信頼性の高い認証を実現します。
なぜ今これが重要なのか
Google、Yahoo、Apple、Microsoftなどの主要なメールボックスプロバイダーは、送信者に対する要件を強化し、認証およびポリシー適用に対する期待水準を引き上げています。その結果、組織には、より厳格なDMARCポリシーの採用、rejectポリシーによる完全適用への移行、SPFとDKIMの両方で適切なアライメントの確保、さらに組織を代表してメールを送信するすべてのシステムを包括的に可視化することが、これまで以上に求められています。
DMARC RFC 9989は、この流れをさらに加速させるでしょう。長年残されてきた仕様上の曖昧さを解消するだけでなく、受信側での解釈をより統一することにもつながります。その結果、コンプライアンスと運用成熟度に対する要求水準はさらに高まります。認証失敗はより可視化され、プロバイダー固有の挙動に左右されにくくなります。また、これまで受信側の実装の違いによって「問題なく動作していた」設定も、サブドメインポリシーの不備が受信側のばらつきによって隠されなくなるため、期待どおりに機能しなくなる可能性があります。
日本でもDMARCへの対応が加速
DMARCの重要性が高まっているのは、グローバル市場だけではありません。日本でも、2026年6月に改定された「政府機関等の対策基準策定のためのガイドライン」において、DMARCによる送信ドメイン認証が基本対策事項として位置付けられました。これにより、政府機関等ではメールのなりすまし対策としてDMARCの適切な導入・運用が求められることになります。
この動きは政府機関だけにとどまりません。政府調達やサプライチェーンとの取引を行う企業を含め、日本企業全体においても、DMARCをはじめとするメール認証への対応がこれまで以上に重要になっています。DMARC RFC 9989への対応は、こうした国内の要件への備えという観点からも重要な取り組みといえるでしょう。
組織が直面する課題
DMARCは広く普及しているものの、多くの組織では、その効果を十分に発揮できない運用上の課題が依然として残っています。代表的な課題の一つは、すべてのメール送信元を十分に可視化できていないことです。その結果、ドメインを代表してメールを送信するすべてのシステムを特定し、適切に認証することが困難になります。この可視性の不足により、多くの組織ではrejectポリシーによる完全適用へ自信を持って移行することが難しくなっています。
また、サードパーティーの送信者への対応も複雑さを増しています。複数のベンダーにまたがってSPFとDKIMのアライメントを適切に維持することは容易ではありません。さらに、多くのチームはDMARCレポートを正しく解釈し、それを具体的な改善アクションへと結び付けることに苦労しており、継続的な最適化や迅速な対応の妨げとなっています。加えて、メール転送やSaaSを利用したメールフローでは認証が失敗するケースも多く、その原因を特定して解決することは必ずしも容易ではありません。
こうした課題は、可視性、分析、制御を一元的に提供するとともに、従来のDMARCと将来のDMARC RFC 9989の両方の観点からDMARCポリシーの状況を把握できる、プラットフォームベースのアプローチの必要性を示しています。
日本企業への影響は？
多くの企業にとって、今すぐDMARCレコードを書き換える必要があるわけではありません。
現在広く利用されている以下のタグは引き続き有効です。
v=p=sp=rua=ruf=adkim=aspf=fo=
例えば、次のようなDMARCレコードもそのまま利用できます。
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
そのため、すでにDMARCを適切に運用している組織であれば、直ちに大きな設定変更が必要になるケースは多くありません。
実務上の主な変更点
今回の仕様変更で特に押さえておきたいポイントは、次の3点です。
1. DMARCが正式な標準仕様になった
これまでDMARC（RFC 7489）はInformational RFCという位置付けでしたが、RFC 9989ではIETFのProposed Standard（標準化仕様）となりました。
今後は政府調達、各種ガイドライン、監査などでも引用される機会が増えることが予想されます。
2. 一部のタグが非推奨に
従来利用できた以下のタグは非推奨となりました。
pct=rf=ri=
例えば、段階的にDMARCを適用するために利用されてきたpct=20などの設定は、今後見直しを検討することが望まれます。
3. 新しいタグが追加
RFC 9989では、新たに以下のタグが追加されています。
np=psd=t=
これらはサブドメインやPublic Suffix Domain（PSD）への対応などを強化するためのものですが、現時点では利用している企業はまだ多くありません。
プルーフポイントによる支援
DMARC RFC 9989では、メール送信元の把握やサブドメイン管理、レポート分析など、運用面での重要性がさらに高まります。プルーフポイントは、DMARC RFC 9989に対応した統合的なDMARC管理ソリューションを提供しています。
すべての送信元の検出と資産管理
プルーフポイントは、正規・非正規を問わず、お客様の組織を代表してメールを送信しているすべてのサービスを特定します。これにより、以下を実現できます。
- シャドーITによるメール送信元の排除
- SPF/DKIMの適切なアライメントの確保
- なりすましリスクの低減
ポリシー適用までを支援
以下の機能により、「p=none → quarantine → reject」への移行を安心して進められます。
- リスクベースの推奨事項
- シミュレーションと影響分析
- 段階的かつ管理された展開戦略
高度なレポート機能と分析
DMARCレポートを実用的なインサイトへと変換します。
- 標準化された集計レポート
- 脅威の特定と送信元の分類
- 経営層向けダッシュボード
サードパーティー送信者の管理
プルーフポイントは、SaaSやメールサービスベンダーの導入およびガバナンスをシンプルにします。
- アライメントの検証
- ポリシーの適用
- 継続的な監視
メール認証だけでは防げない脅威にも対応
DMARCだけでは、すべてのなりすまし攻撃を防ぐことはできません。プルーフポイントは以下の機能を組み合わせることで、より包括的な保護を提供します。
- 表示名を悪用したなりすましの検知
- 類似ドメイン（Lookalike Domain）対策
- BEC（ビジネスメール詐欺）および高度なフィッシング攻撃対策
DMARC RFC 9989と今後の仕様変更への対応
DMARCが今後も進化を続ける中、プルーフポイントは以下を実現します。
- 新しい標準への迅速な対応
- さまざまな環境で一貫したポリシー解釈
- セキュリティチームの運用負荷の軽減
2026年、組織が準備すべきこと
DMARC RFC 9989への移行に備え、DMARC設定を見直すための計画を今から策定しましょう。
1. DMARC RFC 9989の仕様を確認する
- DMARC RFC 7489からの主な変更点は、こちらのサマリーで確認できます。
2. DMARCポリシー構成を再確認する
- 組織ドメインとサブドメインのポリシーを監査する
- 意図しないポリシー継承の不備を特定する
- 期待するポリシー適用結果と整合していることを確認する
3. すべてのメール送信元を棚卸しする
- 把握していない、または許可されていない送信者を特定する
- すべてのベンダーでSPF/DKIMのアライメントを検証する
- シャドーITを排除または是正する
4. より厳格なアライメント判定に備える
- 一貫した評価基準で現在の認証成功率・失敗率をテストする
- ポリシー適用（quarantine/reject）のシナリオをシミュレーションする
5. レポート機能と分析機能を強化する
- 利用中のツールが標準化されたDMARC RFC 9989レポートに対応できることを確認する
- 異常検知とトレンド分析を自動化する
6. 間接的なメール配送経路を検証する
- メール転送、メーリングリスト、SaaSワークフローをテストする
まとめ
DMARC RFC 9989はDMARCの基本的な枠組みを大きく変えるものではありません。しかし、実装のばらつきを正当化する余地をなくし、DMARCのベストプラクティスの普及をさらに加速させるでしょう。AI時代では、攻撃はかつてない規模とスピードで展開されています。そのため、脅威が組織内へ侵入する前に阻止することが、これまで以上に重要になっています。攻撃者がAIを活用して巧妙ななりすましキャンペーンを展開するケースが増える中、メール認証は、ドメインのなりすましやその他のなりすまし型攻撃を防ぐための重要な対策として、大きな役割を果たします。
今からDMARC運用を最新化する組織は、進化する送信者要件に対応しやすくなるだけでなく、移行期間中もビジネスに不可欠なメール配信を維持し、ますます高度化する攻撃への防御力を強化できます。現代のコミュニケーション環境を保護するために設計された統合プラットフォームであるプルーフポイント Collaboration Securityは、信頼できるデジタルアイデンティティの確立、メール認証の適用、そしてメールやコラボレーションチャネル全体におけるなりすましリスクの低減を支援します。
詳細はこちら
Email Fraud Defenseでは、プルーフポイントがDMARCの導入を簡素化し、メール認証を強化するとともに、ポリシー適用までの取り組みをどのように加速できるかをご紹介しています。
プルーフポイントが、AIによって大規模化する脅威や、メールおよびデジタルコミュニケーション全体に及ぶ高度ななりすまし攻撃から組織をどのように保護しているかについては、Proofpoint Collaboration Securityをご覧いただくか、プルーフポイントの担当者までお問い合わせください。