出版 p=reject これは政策のマイルストーンであり、終わりではない DMARC 操作。送信サービスが変更され、新しいアプリケーションが登場し、受信者は独自の処理決定を保持します。集計レポートは、認証のリグレッション、新たに観察されたソース、要求されたポリシーと報告された処理の違いを特定するのに役立ちます。
ポリシー変更後もレポートの構成と監視を継続します。適合性は依然としてドメインの使用状況によって異なります。 RFC 9989 §7.4 ユーザーがインターネット メーリング リストに投稿できるドメインの拒否に対して警告し、有効な拒否ドメインを使用する必要があります。 DKIM のみに依存するのではなく SPF。証拠は、参加している受信者とその観察によって制限されたままです。拒否ポリシーは、すべてのなりすましの試みがブロックされたこと、またはすべての正当なメッセージが配信されたことを証明するものではありません。
方針、評価、処分を分けて読む
参考文献: RFC 9989 §4.7, RFC 9989 §5.4, RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11.
公開されたポリシーは、 DMARCに失敗したメールに対するドメイン所有者が要求した処理を表します。評価では、認証されたSPFまたはDKIM識別子が作成者のドメインと一致するかどうかが尋ねられます。報告された性質は、受信者の報告された DMARC 関連の処理を説明し、指定された場合にはオーバーライド情報も含みます。
これらのフィールドを 1 つのステータスにまとめてはいけません。 記録 disposition none と一緒にp=rejectを表示しても、自動的に不正な形式になるわけではありません。メッセージが渡されたか、受信側の処理が要求されたアクションと異なる可能性があります。ポリシーだけから推測するのではなく、調整された結果と利用可能な理由を調べてください。 RFC 9989 受信者の裁量権を維持し、 RFC 9990 集計フィールドを定義します。
正当なルートのリグレッションに注意する
参考文献: RFC 9989 §5.3.5.
アプリケーションと所有者のインベントリを維持します。現在の観測値と予想される正体を比較し、変化したものを調査します。 セレクタ, リターンパス ユーザーがメールの紛失を報告する前に、ドメインを作成するか、ドメインを作成してください。長期間にわたって表示されない可能性がある、少量の季節ルートを含めます。
例示的なケース: 以前に検証された課金アプリケーションが新しいプラットフォームに移行し、調整された状態が失われる DKIM署名。 SPF引き続き無関係なサービス ドメインを通過します。適用可能な有効なポリシーと完了したチェックが想定されます。この合成例では、別の調整された通過パスがないと、メッセージはDMARC失敗します。有効な対応策は、サポートされている送信者 ID を修復することです。強制により今後のオンボーディングが不要になったと想定するのではありません。
継続する不正な障害を解釈する
不正な送信者は、施行後も From のドメインを使用し続ける可能性があります。レポートには、観察された失敗した認証とそのトラフィックの受信者の処理を示すことができます。永続的な障害の量だけでは、強制が効果的ではないことを証明するわけではありません。コントロールは、到着し続けるトラフィックを拒否している可能性があります。
逆に、すべての失敗を攻撃の防止が確認されたものとしてカウントしないでください。帰属、意図、受信者の範囲、および実際の処理には証拠が必要です。レポート数は観察数であり、報告された処理は完全な下流配信監査ではありません。
例外と不足している補償範囲を調整する
参考文献: RFC 9990 §3.1.6, RFC 9990 §4, RFC 9989 §5.3.8.
失敗したメールが要求されたポリシーとは異なる処理を受けた記録を確認します。指定されたオーバーライドの理由と、関連する転送または仲介の動作を調査します。すべての受信者が同じローカル ポリシーを適用する、またはすべての例外に十分な説明があるとは想定しないでください。 集計レポート.
レポート パイプライン自体を確認します。宛先の所有権、必要な場合は外部承認、取り込みエラー、提供元の受信者の変更などです。施行後のサイレント ダッシュボードは、収集の問題を反映している可能性があります。重要なルートに対して管理されたテストを継続し、配信を調査するときに受信者の証拠をアプリケーション ログと比較します。
施行後の運用リズムの維持
新しい送信者のオンボーディング、定期的なインベントリ レビュー、 DNS変更、レポートのトリアージに対する責任を割り当てます。一時的なポリシーの緩和には、承認および失効プロセスを使用します。提案された変更がサポートされている原因に対処しており、無関係な送信者に不必要に影響を与えていないことを確認します。
正当なルートをテストし、不明な情報源を調査し、受信者の逸脱を調査し、報告のギャップがまだ存在することを確認して、各レビューを終了します。 p=reject後の目的は維持され、説明可能な認証範囲になります。ポリシー文字列だけではその保証を提供できません。
結論と次のアクションを結びつける
架空のプラットフォームの移動の場合は、未調整のDKIMとは別に、無関係のサービス ID の下に生のSPFパスを保持します。今後サポートされる署名修復は、影響を受けるルートでテストする必要があります。報告された none の処理は、認証が回復したこと、または受信トレイがメッセージを受信したことを証明するものではなく、証拠を処理したままになります。