DMARCのポリシー変更は本当に必要なの？DMARCのポリシー変更・導入
について

はじめに

大手クラウド企業の送信ドメイン認証の義務化や、セキュリティの観点から企業や組織へのDMARC（Domain-based Message Authentication, Reporting, and Conformance）の導入ニーズはますます高まっています。
DMARCは、実際にメールの認証を強化しフィッシング攻撃やスパム、なりすましメールなどから受信者を保護するための強力な手段になります。
本ブログでは、DMARCを導入し、最終的にp=rejectに到達するまでのステップガイドを提供します。

◆DMARCポリシーとは？

DMARCは3種類のポリシーの中からいずれかを選択することで、DMARC認証に失敗したメールをどう扱うかを設定できます。DMARCポリシーはp（ポリシー）=“ポリシーの種類”で表され、 処理方法が緩めなものから順に、none(監視のみ)、quarantine(隔離)、reject（拒否）とあります。最初の導入時はp=noneで設定し、最終的にはrejectへ変更するのがDMARC導入のセオリーです。

◆そもそもp=rejectへの変更は必要なもの？

ここでDMARC導入のステップを踏む前に、DMARCポリシーをp=rejectに変更する必要があるか、原点に立ち返り考えてみましょう。
DMARCは送信元がなりすまされたメール攻撃をドメイン所有者側の責任において防ぐことができ、受信者をまもることができる素晴らしい仕組みですが、p=noneのままでは、その最大のメリットを活かすことができません。
p=noneのポリシー設定のままでは『DMARCレポートを送信する』以外のメリットがないからです。防御としては何も機能しません。 大切なお客様や取引相手が、自組織を騙ったドメインによって何らかの被害にあってしまった場合、「DMARCポリシーの変更という手段はあったのに、なぜ対策してくれなかったのか？」 と思われ、信用を失う可能性があります。
そういった事態を防ぐため、自組織のドメインを騙った攻撃メールをきちんと止めるためには、p=rejectまたはp=quarantineへご変更いただく必要があります。

また、公開情報であるDMARCポリシーは、ドメイン所有者・ドメイン所有組織のセキュリティ意識の対外的な提示にもなります。
さらに、p=rejectまたはp=quarantineへ移行したドメインではなりすましが成功しないことから、そのドメイン自体が攻撃に使われる可能性が非常に低くなるというメリットもあります。

せっかくDMARCを導入するのですから、p=rejectもしくはp=quarantineへの移行を目指しましょう！

◆DMARC導入手順

ステップ1: SPFとDKIMの設定
DMARCの導入に先立ち、まずはSPF（Sender Policy Framework）とDKIM（DomainKeys Identified Mail）を設定しましょう。これらの技術は、メールの送信元の正当性を確認するための基盤となります。DNSレコードを設定して、メールサーバーが正当なメール送信元であることを示します。

ステップ2: DMARCレコードの追加
次に、DMARCレコードをドメインのDNSに追加します。DMARCレコードは、メールの送信元の認証情報やポリシーを指定するものであり、p=rejectまでの進捗を管理する際に重要です。適切なポリシー（p=noneから始めることが一般的）を設定して、ドメインのメール認証を開始します。

ステップ3: DMARCレポートのモニタリングと分析
DMARCをp=noneで有効化したら、DMARCレポートのモニタリングが重要です。DMARCは、送信元や認証の状態に関する詳細なレポート（rua、rufレポート）を生成します。これらのレポートを分析し、正当なメール送信元と不正な送信元を把握しましょう。

ステップ4: SPF/DKIMの失敗を修正
DMARCレポートの分析に基づいて、SPFやDKIMの認証に失敗したケースを修正します。これにより、ドメインのメール送信元が正当であることを確認し、p=noneからp=quarantineへの移行を進めます。DMARCレポートの十分な解析とチューニングが済んでいるようなら、この段階でp=rejectへの移行も可能です。

ステップ5: ポリシーの強化
メール送信元の認証が安定し、問題が解決されたら、DMARCポリシーをより厳格なものに変更します。p=quarantineからp=rejectへの移行は慎重に行い、影響を最小限に抑えながら進めましょう。

まとめ

DMARCの導入は、メール送信元の信頼性を確保し、安全なメール送受信を実現するために欠かせないセキュリティ対策となります。

また、取引条件にDMARCを求める企業の中には、DMARCポリシーをp=rejectまたはp=quarantineの設定が指定されるケースもあるようです。
今後、p=noneでDMARC導入されているドメインがなりすまし攻撃に利用されているといった場合、受信側からDMARCポリシーをp=rejectまたはp=quarantineへ移行するよう、要求される可能性も考えられます。あるいは、日本よりもDMARC導入が進んでいる海外クラウド基盤や企業などで突然の要件変更もあるかもしれません。

このステップアップガイドを参考にしていただきp=rejectまたはp=quarantineへの道を確実に進み、組織のセキュリティを向上させましょう。
なお、特にDMARCレポートの解析はDMARCポリシー移行において重要な要素になりますので、自組織での運用が難しい場合は、Proofpoint EFDのご利用をご検討ください。

DMARCポリシー対策についてさらに詳細が気になる方、昨今変更されたクラウド企業の新メールポリシーへの対応にご興味がある方は、ぜひこちらのWebinarもご覧ください！