Proofpoint Blog 第58回次世代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 をご覧いただくか、プルーフポイントの担当者までお問い合わせください。元の記事を読む