reject後の対応

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

この記事をお読みになり、DMARCポリシーを p=reject に設定できた方は、おめでとうございます！これで、ご自身のインターネットドメインを保護する方法に関する知識と意識を身につけられました。ドメインの整理、代わりにメールを送信している各ベンダーのリスト化、これらのサービスの所有者の特定、DMARCコンプライアンスの達成、そしてメールの足跡に対する理解を深めた今、次はどうすればよいのかとお考えかもしれません。

DMARC導入プロジェクトのどの段階にあっても、p=reject ポリシーに到達した時点で、DMARCの維持・管理段階p=reject ことを知っておくと役立ちます。DMARCは一度設定すれば後は放っておけるようなプロジェクトではありません。メールプログラムのセキュリティを確保し、サイバー犯罪者に先手を打つためには、DMARCレポートを監視することが不可欠です。

組織を代表して送信されるメールの送信方法における変動を、明確かつ継続的に追跡する手段がなければ、追跡されていない変更が、p=reject時の配信エラーにつながる可能性があります。dmarcianのDMARC管理プラットフォームは、常に監視体制を維持し、必要なアラートと可視性をすぐに確認できるようにします。

メールの送信パターンに加え、SPF、DKIM、DMARCレコードの状態も監視する必要があります。これらの設定に変更やエラーが生じると、受信トレイへの到達率が低下したり、p=rejectポリシー下ではメールが完全にバウンスされたりする恐れがあるためです。

可視性が重要な理由

DMARCの強制適用ポリシーに到達した場合でも、当社のDMARC管理プラットフォームを引き続きご利用いただくべき理由は以下の通りです：

• SPFレコードの定期的な確認 –SPF Surveyorを使用して、組織を代表してメールを送信する権限を持つIPアドレスやネットブロックが実際に使用されているかどうかを確認し、SPFレコードが最新の状態であることを確認してください。利用しなくなったベンダーや、過去に誤って追加されたベンダーに関するレコードの内容を見直すことは、常に良い習慣です。これは「過剰認証」と呼ばれ、受信者からは好ましく思われません。
• SPFの変更状況を可視化し、管理を徹底する – 組織内のDMARCプロジェクト責任者の承認なしにSPFが変更されないようにしてください。予期せぬ変更が発生した際に、dmarcianプラットフォームからアラートで通知を受け取れるように設定してください。
• DKIM キーの定期的な更新の監視 – セキュリティを最適化するためには、DKIM キーを定期的に更新する必要があります。メール送信元の重要度に応じて、数か月ごと、あるいは年1回といった頻度で更新を行うのが一般的です。これに関する記事はこちらです。
• DMARCデータの定期的な確認 – ビジネスの成長に伴い、正当なメールの新たな送信元がないか必ず確認してください。このデータセットは、ベンダー統合の機会の追跡、メール送信量の変動、特定のベンダーにおけるコンプライアンス違反の発生、予期せぬ配信パターンの分析など、その他の調査にも活用できます。
• レポート機能 – dmarcianを設定して、ドメインの利用状況や不正利用に関するレポートを送信するようにしてください。当社のDMARC管理プラットフォームでは、こうした問題が発見された際にアラートを受け取ることができ、メールプログラムへの影響を最小限に抑え、お客様に代わってメールを送信する各送信元においてベストプラクティスが適用・維持されていることを確認することを目的としています。Alert Centralでまだアラートを設定していない場合は、今すぐ設定することをお勧めします。当社のすべての有料プランでは、アラートを無制限に設定できます。
• 社内インシデント管理 – DMARCに関連すると考えられるメール配信の問題が発生した場合は、問題点と解決策を確認してください。多くの場合、サポート部門が得られるエラーの追跡情報は限定的または不完全です。DMARCデータをフィルタリングして問題の範囲を把握することで、より包括的な状況を把握することができます。

DMARCのメンテナンス

組織におけるDMARCの運用上の問題は、ベンダーの導入や契約終了時、あるいはベンダーとの関係の変化によってベンダーのメール送信行動が変更された際に、しばしば発生します。

組織を代表してメールを送信している人物を明確に追跡する手段がなければ、こうした変更を見逃してしまい、すでにp=rejectの状態にある場合、メールの配信率に深刻な影響を及ぼす恐れがあります。当社のDMARC管理プラットフォームなら、常に監視体制を維持できます。

DMARCを導入するには、DNSへの必要な変更など、技術的な側面も確かにありますが、作業の大部分はコミュニケーションと、ドメインを「p=reject」設定にした後も継続して運用できる強固な業務プロセスの構築に費やされます。

まとめると、隔離（quarantine）または拒否（reject）のポリシー適用を実現した後は、DMARCへの準拠を維持し、DMARCポリシーの適用に関連する潜在的な問題を最小限に抑えるための継続的な取り組みが必要です。DMARCプロジェクトのこの段階では、予期せぬ問題や計画的な変更に組織が備えられるよう準備することに重点が置かれます。さらに、新規ベンダーをオンボーディングする際には、最初からDMARCを組み込むようなビジネスプロセスを、この時点で確立しておく必要があります。

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

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