DMARCのquarantineとrejectの違いと選び方

DMARCのrejectはquarantineより安全か

DMARCのrejectは、ドメインを直接なりすますメールに対して、より強い処理を求めるものです。ただし、どのドメインにとっても自動的に安全な選択になるわけではありません。利点は、失敗したメッセージがユーザーに届きにくくなることです。代償は、正規のメールがDMARCに失敗したときや、メーリングリストの挙動でアライメントが崩れたときの影響が大きくなることです。

RFC 9989は、古い導入アドバイスが見落としがちな重要な制限を加えています。メーリングリストに日常的にメールを送る一般ユーザーを抱えるドメインは、拒否が相互運用性の問題を招くため、通常はp=rejectを公開すべきではありません。RFCによれば、こうしたドメインはp=noneでレポートを収集し、次にp=quarantineを使い、残る失敗とメーリングリストへの影響を評価してから、より厳しい要求を検討すべきです。（RFC 9989、汎用メールドメイン）

DMARCポリシーはどの値に設定すべきか

ドメイン所有者が正規の送信経路をまだ洗い出している段階や、ポリシー強化による相互運用性への影響を予測できない段階では、DMARCをp=noneに設定します。重要な送信元がアライメントの取れたSPFまたはDKIMで合格するようになったら、疑わしいものとしての扱いが根拠に合う場合はp=quarantineを、残る失敗の拒否や破棄を求めても問題ない場合はp=rejectを選びます。ユーザーがメーリングリストに日常的に送信する汎用ドメインは、相互運用性のリスクを許容できると根拠で示せない限り、rejectを公開せず、通常はquarantineにとどめるべきです。（RFC 9989、汎用メールドメイン）

quarantineとrejectの選び方

DMARCのquarantineとrejectは、ドメインの実際のメールストリームに関する根拠をもとに選びます。

1. ドメインのメールを棚卸しする。DMARC集計レポートを使い、表示上のFromアドレスにそのドメインを使って送信しているサービスをすべて特定します。
2. 実際のメッセージでアライメントを検証する。メールヘッダー分析ツールで、重要なストリームごとに代表的なメッセージの認証結果を確認します。公開DNSレコードだけではアライメントを証明できません。
3. 相互運用性のリスクを洗い出す。一般ユーザーが、メーリングリストや転送サービスなど、メッセージや認証結果を変えうる経路で送信していないか確認します。
4. 処理の要求を選ぶ。疑わしいものとしての扱いが根拠に合えばquarantineを使います。rejectは、ドメインの用途と残る失敗から見て拒否を許容できる場合に限ります。
5. 変更後も監視を続ける。新しいベンダーや設定の変更により、どちらのポリシーでも正規の失敗が生じることがあります。

たとえば、あるドメインがメールボックスプロバイダー、サポートプラットフォーム、請求書発行アプリケーションから送信しているとします。最初の2つがアライメントの取れたDKIMで合格していても、請求書アプリケーションにアライメントの取れていないSPF合格しかない場合、所有者がそのストリームを受け入れるか廃止しない限り、請求書のストリームを危険にさらさずに強いポリシーを求められる状態ではありません。請求書の経路を修正するか、意図的に廃止するまで監視を続けます。メーリングリストに送信するユーザーもいるドメインなら、rejectを許容できる要求と判断する前に、RFC 9989の相互運用性に関する警告を検討してください。

RFC 9989のテストフラグで導入はどう変わるか

RFC 9989のt=yフラグは、ドメイン所有者がテストしている間、公開されたポリシーを適用しないよう受信側に求めます。想定される一段階のフォールバックは、p=quarantine; t=yならnone、p=reject; t=yならquarantineです。DMARCレポートは引き続き生成され、受信側はローカルの裁量を保持します。（RFC 9989、tテストフラグ）

テストフラグは、旧来のpctタグが担っていた導入時の役割の一部を置き換えますが、割合によるサンプリングではありません。RFC 9989でpctは削除されました。pct=10付きで厳しいポリシーを公開し、すべての受信側がその割合を一貫して適用すると考えないでください。（RFC 9989、pctの削除）

現在の構文の確認にはDMARCレコード生成ツールを、DNSで公開されている内容の検証にはDMARCチェックを使ってください。どちらのツールも、すべての本番送信元のアライメントを証明したり、受信側の最終処理を予測したりはできません。

レコードを確認し、次に実際のメールを確認

まずは無料のDMARCチェックで、ドメインが公開しているポリシーを確認します。次に、レコードを変更する前に、集計レポートの根拠と、重要な本番ストリームごとのヘッダーを照らし合わせます。公開レコードだけでは、ポリシー強化の準備ができているとは判断できません。

PalisadeのDMARC Agentは、DMARC集計レポートのデータを優先度付きのワークフローに変えます。送信元の特定、認証とアライメントの問題の調査、ポリシー強化までのより安全な道筋の管理に役立ちます。最終的な処理を決めるのは引き続き受信側です。Palisadeは配信を保証せず、メッセージを自らブロックすることもありません。

根拠

出典と参考資料

• RFC 9989：Domain-Based Message Authentication, Reporting, and Conformance