表示ラベルの新しいブランド名は、From アドレスの新しいドメインの変更と同じではありません。後者はアイデンティティを変更します。 DMARC アライメント 評価されます。したがって、完全に有効な古いドメインの署名は、新しくブランド化されたメッセージの役に立たなくなる可能性があります。コミュニケーション チームが所有していないトランザクション アプリケーションを含め、発売の発表前に ID の移行を計画します。
ID フィールドを分離する
ルートごとに、表示されている From アドレスをキャプチャします。 封筒の差出人, DKIM d= domain and セレクタ、および返信先アドレス。表示名はプレゼンテーションです。 Reply-To は返信を指示します。どちらもDMARCで使用される認証済み識別子の代わりにはなりません。 RFC 9989 アライメントを定義します。 RFC 6376 署名 ID とセレクター検索を定義します。
1 つの会社が両方を所有しているからといって、古いブランド ドメインと新しいブランド ドメインが一致していると想定しないでください。厳密な位置合わせでは、ドメイン名が一致する必要があります。緩和された調整では、企業買収のリストではなく、プロトコルの組織とドメインの関係が使用されます。次の例では、厳密なDKIMアラインメントを想定し、1 つの署名を分離します。 DMARC検出を実装したり、メッセージ全体の結果を決定したりすることはありません。
カットオーバー前に新しいドメインを確立する
在庫マーケティング、従業員へのメール、請求書、パスワードのリセット、サポート チケット、および低頻度のアラート。それぞれについて、実際のアカウントに対して生成された値を使用して、プロバイダーがサポートする新しい送信 ID と必要なDNSを構成します。制御されたテスト メッセージから信頼できる受信者の結果を取得します。認証とビジネス ワークフローの両方を確認してください。DMARC DMARC通過するが壊れたリンクが含まれるリセット メッセージは準備ができていません。
返信と古いアドレスのパスを文書化して保管してください。古いドメインでのメールの受信を継続することと、送信送信者の承認を継続することは別です。古い ID が必要な期間と、古いセレクターで署名された遅延メッセージをどのように処理するかについて合意します。最後に新しく生成されたメッセージが切り替わったからといって、公開キーを削除することは避けてください。
4 つの仮想的な署名結果を比較する
From が oldbrand.test で、有効な署名がd=oldbrand.test:その署名は厳密に一致します。有効な古いドメイン署名を保持したまま、From のみを newbrand.test に変更します。厳密に一致しなくなりました。 d=newbrand.testを含む有効な署名により、この調整されたDKIMパスが復元されます。新しいドメインの署名が検証に失敗した場合、一致するドメイン テキストだけではパス パスを提供できません。これらは想定された入力と手作業による比較であり、実行されたコードや暗号検証ではありません。
別の有効な整列署名、または整列された署名 SPF pass はメッセージレベルのDMARCルールを満たす可能性があります。障害を宣言する前に関連するすべてのパスを検査し、受信者の性質や受信箱の配置を推測しないでください。別途、 RFC 9989 セクション 7.4 および 8 では次のことが必要です p=reject ドメインではSPFのみに依存せず、有効なDKIM署名を使用する必要があります。起動前に、リセット トランザクションと認証を確認してください。リセット リンクが切断されている場合は、パスが一致していてもビジネス障害のままです。
立ち上げを段階的に進め、回復を定義する
最初に 1 つの承認されたストリームを移動し、そのアプリケーションの結果、受信者の結果、およびレポートを監視します。 集計レポート 参加している受信機からの遅延観測であり、完全な打ち上げ監視ではありません。ビジネスにとって重要なフローの直接チェックを追加します。健全なマーケティング量では、請求書やリセットの失敗を隠してはいけません。
起動前にロールバックを定義します。以前の From ID を復元できるのは誰なのか、古い認証が有効なままかどうか、すでにキューに入っているメールはどうなるのかなどです。表示名のみを元に戻すと、位置合わせの失敗を修復できません。最後に承認されたストリームが移動し、遅延メール計画が完了したら、古い送信権限を廃止します。古いドメインの所有権と受信ルーティングの決定を、送信終了レコードとは別に保存します。