グループ全体の電子メール ポリシーでは、各子会社が実装の異なる部分を管理しながら、望ましい結果を記述することができます。あるチームが登録を所有し、別のチームがDNSを実行し、ローカル ベンダーがアプリケーション メールに署名する場合があります。効果的な調整は、本社がすべての領域を変更できると想定するのではなく、これらの当局をマッピングし、比較可能な証拠を収集することから始まります。
ドメインとサービスマップを構築する
各子会社について、法人または事業体、ドメイン、権威あるDNSオペレーター、レジストラの連絡先、地元の事業主、およびインシデントの連絡先を特定します。各送信サービスをそのアカウント、目的、重要度、From ドメイン、エンベロープ ドメイン、 DKIM ドメイン、 セレクタ そして最後の認可されたテスト。類似した名前の会社間で混同される可能性がある略語に依存するのではなく、正確な名前を保存します。
DNS委任により、ゾーン境界で管理責任が分割されます。親ドメインが中央で保持されているからといって、すべての子ゾーンが中央チームによって運営されているわけではありません。 RFC 1034ではゾーンと委任について説明しています。実際の信頼できる記録とアクセス記録を使用して、実装を決定します。 DNS概念。登録、 DNS操作、およびサービスの承認は、別個のインベントリ フィールドにする必要があります。
共通の証拠契約を確立する
すべてのローカル チームに、同じ最低限の証拠 (現在の構成、承認された代表者のメッセージ、信頼できる受信者の認証結果、承認の参照、およびサービスの責任者) を依頼します。観察時間とルートを記録します。応答したドメインのみを対象としたグループ全体の成功率を報告することによって、欠落している子会社を平均化しないでください。
DMARC ポリシーの発見と 識別子のアライメント 企業の所有権図ではなく、プロトコルのルールに従います。個別の登録ドメインは、同じ親会社が所有しているというだけの理由でポリシーを共有しません。サブドメインの動作は、該当するポリシー検出ルールと記録に基づいて評価する必要があります。 RFC 9989。本社の結論をコピーするのではなく、テストされたアイデンティティごとに正確に効果的なポリシーを文書化します。
2 つの子会社の証拠を別々に保管する
子会社 A がその請求ルートに対して現在認可されたテストを行っており、子会社 B が同じプロバイダーを使用しているため、コピーされた A サンプルを提供しているとします。 B の企業とDNS所有者は名前が挙げられていますが、実際の顧客アカウント、身元、ルートは未確認のままです。共有プロバイダー ラベルは、A のメッセージ証拠を B に適用するものではありません。
グループ全体で検証された範囲ではなく、現在の請求ルートのサンプルを使用して子会社 2 社のうちの 1 社を報告します。 B の認定オペレーターに独自の構成と代表的なメッセージの証拠を問い合わせてください。 B が現在のウィンドウ内にデータを生成できない場合は、欠落データを失敗または成功としてカウントするのではなく、名前付き証拠ギャップを保持します。これらは架空の報告書の決定であり、実際の子会社、署名、所有権の決定ではありません。
右境界での座標変更
グループの目標に対して 1 つの変更レコードを使用し、独立して運用されているゾーンまたはサービスごとにスコープ指定されたローカル変更を使用します。承認者、導入期間、復旧計画、検証所有者を記録します。サプライヤーの公開能力 記録 は、施行ポリシーを選択する権限があることを証明するものではありません。緊急連絡先を最新の状態に保ち、緊急の現地変更後に中央チームが証拠を受け取る方法を定義します。
明示的な例外と期限を含めて、ドメインおよび重要なサービスごとの進捗状況をレポートします。誰も監視しない共有メールボックスに置き換えるのではなく、ローカルの所有権を維持する集中ビューを維持します。権限の変更に応じて、買収、売却、サプライヤーの変更、サービスの移行を確認します。完成とは、単に一貫性のある政策文書を作成するだけでなく、対象範囲内の各子会社が証拠に裏付けられた国家と責任ある運営者を有することを意味します。
不足している報道を隠さずに報告する
対象範囲内のドメインと重要なワークフロー、現在の証拠を含むサブセット、および特定のギャップを述べます。ローカル所有者の名前はテスト アーティファクトの代わりにはなりません。各ギャップを実際に収集または修正できるオペレーターに割り当てます。