MailData

p=reject後の運用

p=reject後の運用

2024年2月22日
著者: Ahona Rudra
翻訳: 逆井 晶子

この記事はPowerDMARCのブログ記事 Life After p=reject の翻訳です。
Spelldataは、PowerDMARCの日本代理店です。
この記事は、PowerDMARCの許可を得て、翻訳しています。


多くのドメイン所有者は、メール認証のプロセスは「p=reject」を適用して終わると勘違いしがちです。
しかし実際には、p=rejectを設定した後の運用こそが、ドメインのメールセキュリティ全体の強化にとって重要なフェーズです。
スプーフィングやフィッシング攻撃を防ぎ続けるためには、排除を達成した後に始まるメールセキュリティ戦略をしっかりと構築することが不可欠です。

p=rejectとは?

DMARCポリシーには、次の3つの適用モードがあります。

p=none
特に対策を取らない
p=quarantine
DMARC認証に失敗したメールを隔離
p=reject
DMARC認証に失敗したメールを拒否

rejectポリシーはDMARCの中でも最も厳しい設定であり、これによりドメイン所有者はスプーフィングやフィッシングメールをユーザの受信トレイに届く前にブロックすることができます。
ドメインをメールベースの攻撃から守るには、p=rejectが適切な選択肢と言えるでしょう。

どうすればp=rejectを適用できるか?

多くのドメイン所有者は、早急に認証をenforcementにしたいと考えがちですが、これは推奨されません。
その理由を以下で説明します。

reject適用時のリスク

推奨される実践方法

rejectポリシーにはいくつかの注意点がありますが、メール詐欺を防ぐ効果は確かです。
安全にrejectに移行するための方法を見ていきましょう。

p=noneから始める

まずenforcementを適用するのではなく、柔軟で負担が少ない「p=none」から始めるのが理想的です。
このポリシーは攻撃から守るためには役立たないものの、導入段階の監視ツールとして非常に効果的です。

DMARCレポートを有効化する

メール送信状況を監視することで、プロトコルの設定ミスによる不要な配信トラブルを防ぐことができます。
また、エラーを素早く特定し、修正するのことにも役立ちます。
DMARCレポートは、メール認証の有効性を把握するために非常に有用です。

メール認証が万能ではないにしても、セキュリティ対策としては強力なツールです。
DMARCレポートを利用すれば、自分の施策が機能しているか、または対策を修正する必要があるかを見極めることができます。

レポートには2種類あります。

集計レポート(RUA)
送信元のIPアドレスや組織のドメイン、地理的位置などを追跡するためのもの。
フォレンジックレポート(RUF)
スプーフィングなどの問題が発生した際に警告を提供するもの。

SPFとDKIMをDMARCと一緒に設定する。

DMARC導入では、他のセキュリティ対策と連携させることが重要です。
セキュリティ専門家は、DMARCとSPF、DKIMを併用することで、誤検知や不要なDMARCエラーを防ぐことを推奨しています。
また、望ましくないDMARC失敗を防ぐこともできます。

DMARCは、SPFまたはDKIMのいずれかが認証に合格する必要があります。
この仕組みにより、rejectポリシーを安全に運用することが可能になります。
仮にSPFが失敗してもDKIMが成功すれば、あるいはその逆でも、認証が成立するため、安心してrejectポリシーを適用することができます。

送信元をすべて把握する

SPFレコードに送信元を正確に反映していない場合、DMARCの失敗を招く原因になります。
自社のメール送信元(サードパーティのベンダーやGmail、Microsoft O365、Yahoo Mail、Zohoなど)を正確にリスト化することが重要です。
これは、SPFをDMARCと組み合わせて使用している場合に特に重要です。
送信元を追加または削除するたびに、SPFレコードも同じ変更を反映する必要があります。

p=reject後の運用まとめ

p=reject適用後も、メール認証の監視は非常に重要です。
これにより、セキュリティ対策の効果を維持するだけでなく、運用面での改善点を見つける手助けにもなります。
DMARCアナライザーは、p=noneからrejectへのスムーズな移行をサポートし、配信トラブルの回避やプロトコルの更新、トラブルシューティングを一つのプラットフォームで簡単に実行することに役立ちます。