成長する企業では、メール管理者を増やすよりも早く、送信サービスを蓄積します。財務部門は請求書発行を追加し、マーケティング部門はキャンペーンを追加し、製品チームは通知を追加します。有用なロードマップは、そのコレクションを所有するインベントリに変え、整合性のある認証を確立し、正当な送信が理解された場合にのみポリシーを改善します。
責任のある在庫から始める
すべてのドメインと送信フローにビジネス オーナーと技術オーナーを割り当てます。従業員のメール、カスタマー サポート、トランザクション アプリケーション、マーケティング、スキャナー、モニタリング、休眠ブランドが含まれます。誰が権威DNSを制御するか、誰が各送信者を設定できるか、誰が変更を承認できるかを記録します。レポートに含まれるすべてのものに信頼を与えるのではなく、既知の正当なトラフィックを説明のないトラフィックから分離します。
アクティブなルートごとに、代表的な受信メッセージのサンプルを保存し、From、エンベロープ ドメイン、署名ドメイン、および信頼できる受信者の結果を特定します。製品とプランの制限を記録します。この第 1 段階の成果物は、単なるリストではなく、所有者と証拠のギャップがあるビジネス フローのリストです。 SPF が含まれます。
正当なアイデンティティを機能させる
現在のファーストパーティの指示とアカウント生成のDNS値を使用して、各送信者でサポートされているドメイン認証を構成します。関連する各所有者で 1 つの有効なSPFポリシーを保持し、その検索依存関係を監視します。整列を確立する DKIM サポートされている場合は、署名が運用ルートに残ることを確認します。無関係なプロバイダー ドメインのパスだけでは証明するのに十分ではありません。 アライメント.
重要なフローを変更する前に、管理されたテスト プロセスを使用してください。パスワードのリセットと支払いの領収書には、週刊ニュースレターとは異なる回復計画が必要になる場合があります。ボリュームの少ないルートは重要ではないと考えないでください。交換、再ルーティング、または明示的に受け入れられた一時的な例外に関するビジネス上の決定により、サポートされていない ID の制限を可視化したままにしておきます。
観察を利用してポリシーの変更を決定する
DMARC 認証されたドメインを表示されている From ドメインに接続します。そのポリシーとレポート メカニズムは、オペレータが障害を理解し、受信機の処理を要求するのに役立ちますが、受信機の決定はローカルなままであり、レポートは完全な一覧表ではありません。レポートをアプリケーション所有者、 DNSレコード、および制御されたメッセージ テストと組み合わせます。
適用を強化する前に、前進基準を定義します。つまり、正当なフローの特定、調整されたサンプルの通過、原因不明の障害の調査、オンコールの所有者、およびテストされたロールバックです。監視の任意の日数を、季節ごとまたは四半期ごとのワークフローが安全であるという証拠にしないでください。すべての名前が同じように動作すると仮定するのではなく、サブドメインと組織ドメイン ポリシーの関係をレビューに含めます。
明示的ゲートによるシーケンスの拡張
ロードマップの例: まず、3 つの重要なフローの一覧を作成し、 DNS所有者を解決します。次に、各フローを認証し、受信とリセットをテストします。次に、観察された失敗をレビューし、元に戻せる変更計画を使用して意図したポリシーを試行します。最後に、新しい送信者の承認と定期的な退職チェックを追加します。これは計画例であり、すべての組織が 4 つのステップで完了するというスケジュールや約束ではありません。
各ゲートについて、所有者、必要な証拠、阻止者、決定日を記録します。別のルートが通過したからといって、ルートを進めることはできません。合併、新しいドメイン、プロバイダーの移行を新しい証拠イベントとして扱います。重要なサービスが調整できない場合は、承認されたビジネス プランなしでサービスをより厳格なポリシーにさらす前に、その依存関係を解決してください。
メンテナンスを日常的な責任にする
新しいアプリケーションは、起動前に送信ドメインと認証所有者を識別する必要があります。サービスが廃止された場合は、未使用のセレクター、 SPF認証、およびプロバイダー アクセスを確認します。アクティブなルートまたは送信中のメッセージによって引き続き必要とされる信頼を維持します。存在を記録するだけでなく、予期しない認証の変更を監視します。
残留リスクについてロードマップを正直に保ちます。 DMARC 、侵害された正規アカウントによる認証済みの不正行為の送信を阻止したり、類似ドメインによる欺瞞を排除したりするものではありません。ドメイン認証とアカウント セキュリティ、メッセージ フィルタリング、およびスタッフの確認手順を組み合わせます。未知の部分がまだ見える状態で、検証済みのフローと埋められた証拠のギャップとして進捗状況を報告します。
拒否する前に送信者の義務を尊重する
RFC 9989セクション 7.4 ドメイン公開が必要です p=reject 有効なDKIM署名を適用し、 DMARC通過をSPFのみに依存しないようにします。セクション 8 には、調整されたSPFおよびDKIMを含む完全参加要件が別途記載されています。したがって、単一メッセージの受け渡し調整メカニズムは、完全な展開準備標準ではありません。セクション 7.4 では、間接的なフローについても警告し、メーリング リストに投稿する可能性のあるユーザーをホストするドメインを拒否しないことを推奨しています。段階的な観察ガイダンスは、実際の景気循環や影響を受ける経路の確認に代わるものではありません。