移管されたドメインには、電子メール送信者の信頼できるインベントリが付属しません。そのDNS以前の所有者が使用していたサービスを引き続き承認する可能性があり、新しい所有者はそれらのサービスの背後にあるアカウントを制御できない可能性があります。厳格な見た目 DMARC ポリシーは移行が安全であることを証明するものではありません。
この変更は、単なる連絡先詳細の変更ではなく、運用管理の譲渡として扱います。目的は、どの電子メール関係が承認されたままであるかを特定し、存続すべきではないものを置き換え、必要なビジネス メールを失わずに新しい送信ワークフローを検証することです。
ポリシーを変更する前に使用目的を確立する
ドメインが電子メールを送信するか、電子メールを受信するか、両方を行うか、または未使用のままにするかを決定します。ドメイン、権威DNS 、従業員のメール、およびアプリケーションの送信に対して責任のある所有者の名前を指定します。移行日と、引き続き動作する必要があるシステムを記録します。
編集する前に、既存のゾーンとDMARCの日付付きインベントリを保存します。 SPF、知られている DKIM セレクタ、関連する CNAME ターゲットと委任されたサブドメイン。これは回復と調査の記録であり、すべての古い権限を復元するための指示ではありません。古いゾーンを丸ごとコピーすると、新しい所有者が決して承認しなかった信頼関係を維持できます。
ここでのワークフローは運用上の推奨事項です。これは、契約上の移転義務に代わるものではなく、レジストラの移転によってメール サービス アカウントが自動的に移行またはリセットされることを前提としていません。
見かけ上のパスの背後にある権限を検査する
DMARC 、認証された ID と、表示されている From ドメインとの関係を評価します。企業が経営者を変更したことや、以前に承認されたアカウントが現在は承認されていないことはわかりません。送信者が依然として有効な署名キーを管理している場合、対応する公開キーが検出可能なままであると懸念が残る可能性があります。同様に、最近のトラフィックが観察されなかった場合でも、古いSPF認証は見直す価値があります。 RFC 9989 §5.3.5 そして RFC 9989 §5.4; RFC 6376 §3.6.2.1.
既知の送信サービスごとに、サービス アカウントの所有者、目的、送信元ドメイン、署名ドメイン、 セレクタ そして封筒のアイデンティティ。 DNS CNAMEキーの公開をプロバイダーに委任するかどうかを特定します。そのプロバイダー アカウントを現在どの当事者が管理しているかを尋ねます。 DNSのプロバイダー名はアカウントを識別したり、新しいビジネスがそのアカウントを承認したことを証明したりするものではありません。
報告先も調べてください。下 RFC 9989 §4.7 そして RFC 9990 §4、古い rua アドレスは、将来の集約データを、前の所有者が管理するメールボックスまたはサービスに送信する可能性があります。承認されたハンドオーバーを通じて必要な歴史的証拠を保存しますが、コピーされたゾーンに存在するという理由だけでレポート関係をそのまま残さないでください。
あらゆる関係について移行の決定を下す
3 つの実際的な結果を使用します。検証された所有権で保持するか、制御された構成で置き換えるか、承認された変更で廃止します。削除するのが不便だからという理由だけで、不明なサービスが保持されているというラベルを付けないでください。不確実性については指定された事業主にエスカレーションし、検討日を設定します。
保持されているサービスについては、サービスでサポートされている転送プロセスを通じて管理アクセスを確認してください。代替サービスの場合は、プロバイダーが生成した新しいDNS値と署名構成を取得します。キーの管理が不確実な場合は、古い秘密キーが秘密のままであると仮定するのではなく、キーのローテーションを計画してください。新しいセレクターと制御されたオーバーラップが使用可能な場合は、別のキーに古いセレクターを再利用することは避けてください。 RFC 6376 、セクション 3.1.
廃止する場合は、将来の不正使用とまだ転送中の正当なメッセージの両方を考慮してください。突然キーが削除されると、そのキーで署名された遅延した正当なメールの検証ができなくなる可能性があります。実際のリスクに基づいて重複または即時取り消しを選択します。キーの侵害が疑われる場合は、通常の移行よりも高速なカットオーバーが正当化される可能性があります。決定とその結果を記録します。
取得の例を見てみる
この合成シナリオでは、新しく取得したドメインは、課金サービスのDKIM CNAMEとSPFインクルードを保持します。財務チームはサービス アカウントを誰が管理しているのかを特定できません。最近の請求書はDMARCを通過しましたが、その結果は新しい会社がアカウントを承認したことを証明するものではありません。
移行所有者は、その未知のサービスの新規登録を一時停止し、財務部門からアカウントとワークフローの証拠を入手し、新しい管理された ID を使用して代替の請求システムをテストします。その後、チームは承認された変更を通じて古い信頼関係を廃止し、予期せぬ継続使用を監視します。メール配信と認証の証拠を企業の所有権記録とは別に保管します。
教訓は、アカウントの関係を解決することであり、見覚えのないトラフィックがレポートに表示されなくなるまでDMARCポリシーを下げることではありません。
管理された新しいベースラインを検証する
保持されているすべてのビジネス ルートから新しいテストを送信します。給与通知、パスワードのリセット、スケジュールされた請求書などの少量システムが含まれます。信頼できる受信者の結果と関連するDNS状態を記録します。 ～からの観察を調整する 集計レポート 在庫を確認しながら、 RFC 9989 §5.3.8 すべての受信者が報告するわけではなく、静かなワークフローが存在しない可能性があります。
保持されているすべての関係に所有者があり、説明されていないアクセス許可が文書化され、新しいベースラインがテストされたら、移行を完了します。レジストラとDNSアクセス保護、サービス アカウントのセキュリティ、トランザクション承認制御をDMARCと並行して維持します。有効なドメイン署名は、承認されたアカウントの悪用を防ぐことはできません。
限定された結論を維持する
取得した請求の例では、現在のメッセージが通過した場合でも、アカウント制御を未解決として記録します。古いレポートの宛先は別個の開示決定として扱い、削除された理由を確認せずに廃止されたキーを復元しないでください。このシナリオは架空のものです。取得、キーのローテーション、またはアカウントの転送は実行されませんでした。