Reject（拒否）ポリシー到達後の対応

p=reject の後はどうなるのか？

この記事をお読みの方で、DMARCポリシーを p=reject まで引き上げることに成功した方がいらっしゃれば、まずは心からお祝い申し上げます！あなたは、自社のインターネットドメインを保護するための知識と意識を手に入れたのです。
自社のドメインを漏れなく洗い出し、自社に代わってメールを送信しているベンダーをすべてリストアップし、それぞれのサービスの管理者を特定し、DMARCコンプライアンス（準拠）を達成して、自社のメール送信フットプリント（利用実態）を深く理解できた今、おそらく次のような疑問を抱いているのではないでしょうか。「さて、次は一体何をすべきなのだろう？」

DMARCの導入プロジェクトが現在どのような進捗であれ、「p=reject というポリシーに到達した瞬間から、DMARCの維持・管理（メンテナンス）という次のステージが始まる」という点を知っておくことは非常に有益です。DMARCは「一度設定すれば終わり（Set-it-and-forget-it）」のプロジェクトではありません。メールプログラムの安全性を維持し、サイバー犯罪者の先手を打ち続けるためには、DMARCレポートを継続して監視することが不可欠です。

組織に代わって送信されるメールの「変化」を明確かつ継続的に追跡する手段がなければ、p=reject の環境下では、気づかないうちに行われた変更が原因でメールの不達エラー（配信エラー）を引き起こす可能性があります。dmarcianの「DMARC管理プラットフォーム」を利用すれば、常に死角をなくし（常に明かりが灯った状態にし）、十分なアラート機能と可視性をいつでも手元に確保できます。

メールの送信パターンの変化だけでなく、SPF、DKIM、DMARCレコードの「健全性」も監視し続けなければなりません。なぜなら、p=reject ポリシーの運用中にレコードの変更やエラーが発生すると、受信トレイへの到達率（インボックス配置）の低下や、最悪の場合はメールの完全なバウンス（不達返送）につながるためです。

なぜ「可視性」が重要なのか

DMARCの強制適用ポリシー（Enforcement Policy）に到達した後も、当社のDMARC管理プラットフォームを使い続けるべき理由として、以下の点が挙げられます。

• SPFレコードの定期的なチェック：
  「SPF Surveyor（調査ツール）」を活用し、組織に代わってメール送信を許可されているIPアドレスやネットワークブロック（ネットブロック）が、現在も実際に使用されているかどうかを確認して、SPFレコードを最新の状態に保ちます。すでに利用していないベンダーや、過去に誤って追加された記述がないか、レコードの内容を定期的に見直すことは優れたアプローチです。これは「過剰認証（Over-authentication）」と呼ばれ、受信側のメールサーバー（レシーバー）からは嫌われる傾向にあります。
  
  
• SPF変更の可視化とコントロール：
  組織内のDMARCプロジェクト責任者の承認なしに、SPFレコードが変更されないよう管理します。予期せぬ変更が発生した際には、dmarcianのプラットフォームからアラート通知を受け取れるように設定が可能です。
  
  
• 定期的なDKIM鍵ローテーションの監視：
  セキュリティを最適な状態に保つため、DKIM鍵は定期的にローテーション（更新）する必要があります。そのメール送信元の重要度に応じて、数ヶ月ごと、あるいは1年ごとのローテーションが推奨されます。（※詳細はこちらの記事を参照）
  
  
• DMARCデータの定期的なチェック：
  ビジネスが成長するにつれて、正規の新しいメール送信元が必ず追加されます。また、このDMARCデータセットを活用することで、「利用ベンダーの集約機会の検討」「メール配信量の変化の追跡」「特定ベンダーにおけるコンプライアンスの退行（未準拠への逆戻り）」「予期せぬ配信パターンの検知」といった、別の調査を行うことも可能です。
  
  
• レポーティングとアラート：
  自社ドメインの利用状況や悪用（なりすまし）に関するレポートを送信するよう、dmarcianを設定します。当社のDMARC管理プラットフォームは、こうした問題が発見された際にアラートを通知するため、メールプログラムへの影響を最小限に抑え、自社に代わって送信するすべての送信元に対してベストプラクティスが適用・維持されている状態を担保できます。まだ「Alert Central」でアラートを設定していない場合は、今すぐ設定することをお勧めします。当社のすべての有料プランで、無制限のアラート設定をサポートしています。
  
  
• 組織内のインシデント管理：
  DMARCに関連すると疑われるメールの配信トラブルが発生した場合、問題の特定と解決策の確認を行えます。多くの場合、一般的なサポート窓口では限定的または不完全なエラー追跡しかできませんが、DMARCデータをフィルタリングすることで、問題がどの範囲まで及んでいるのか、より包括的な全体像（フルピクチャー）を把握できます。
  
  

DMARCの維持・管理（メンテナンス）

組織におけるDMARCのメンテナンス上の問題は、多くの場合、新しいベンダーの導入（オンボーディング）や契約終了（オフボーディング）、あるいはベンダーとの関係変更によってそのベンダーのメール送信挙動が変わったタイミングで発生します。

誰が組織に代わってメールを送信しているかを明確に追跡する手段がない場合、これらの変更は簡単に見落とされてしまいます。そして、すでに p=reject に移行している場合、メールの到達性に重大な悪影響を及ぼすことになります。当社のDMARC管理プラットフォームは、そのような事態を防ぐために、常にシステム全体の視認性を確保します。

DNSに必要な変更を加えるといった「技術的な側面」がある一方で、DMARCの運用の大半は、ドメインを p=reject に引き上げた後も機能し続ける「社内コミュニケーション」と「強固な業務プロセス（体制）」を構築することにあります。

結論として、一度 quarantine（隔離）や reject（拒否）による強制適用を達成した後は、DMARCコンプライアンスを維持し、ポリシー適用に伴う潜在的なリスクを最小限に抑えるための「継続的な取り組み」が必要不可欠です。DMARCプロジェクトのこのフェーズ（維持・管理）は、予定されている変更だけでなく、予期せぬトラブルに対して組織として備えることに焦点を当てています。さらに、新しいベンダーを導入する際には、最初からプロセスにDMARCの組み込みが確実に行われるような「業務フロー」を確立しておく必要があります。

私たちがサポートします
メールセキュリティのエキスパート集団であるdmarcianは、「ドメインセキュリティを通じて、メールとインターネットをより信頼できるものにする」というミッションを掲げ、お客様の組織のドメイン状況を評価し、長期にわたってDMARCの実装と管理をサポートいたします。

さらに詳しく議論を続けたい方は、ぜひ dmarcian Forum へお越しください。