手順を選択する前に CMS 導入を確認してください
Optimizely CMS はアプリケーション メッセージを作成しますが、構成されたトランスポートがアプリケーション メッセージを送信します。まず、影響を受けるワークフローを処理する CMS バージョン、ホスティング モデル、環境、メール統合を記録します。 DXP 上で実行される CMS、自己ホスト型インストール、および独自のサードパーティ製リレーを備えたアプリケーションは、CMS を共有すると想定できません。 SPF または DKIM 構成。 Optimizely Campaign は別個の製品であり、そのマーケティング メール ドメイン レコードを CMS 通知に借用してはなりません。
このガイド用に取得したファーストパーティ DXP 電子メール サーバー ページには、「DXP for CMS 12 および Commerce 14」というラベルが付けられています。これは、クラウドについて説明しています。 トランザクションメール サービス、SendGrid を利用したSMTP構成、およびサポート支援によるドメイン認証プロセスです。この記事では、そのルートを具体的な実装ブランチとして使用します。別の CMS バージョン、ホスティング層、またはカスタム統合に適用するには、対応する現在のドキュメントと展開の証拠が必要です。一般カタログ ラベル Optimizely CMS は、ここで確立された構成範囲よりも広いです。 DXP 電子メールサーバーの構成
構成を編集する前に、アプリケーション所有者、展開オペレーター、メール管理者、およびDNS所有者の名前を指定します。プロジェクト通知、コンテンツ承認メッセージ、または明示的に設定された別のアプリケーション電子メールなど、どのワークフローが成功を実証するかについて合意します。合成コンテンツと制御された受信者を使用します。マーケティング ニュースレターは、両方の製品に同じベンダー名が付いているという理由だけで、CMS 通知テストの適切な代替品とはなりません。
アプリケーションイベントからリレーまでのメッセージを追跡する
ルートをイベントの作成、アプリケーションのディスパッチ、 SMTP送信、プロバイダーの配信、受信者の認証に分割します。各段階でどのような証拠が得られるかを記録します。アプリケーションが通知を生成または送信しない場合、 SPFを編集しても通知を作成できません。 SMTP資格情報を拒否した場合、メッセージは受信者が評価する段階にまだ達していません。 DMARC.
Optimizely の CMS 13 プロジェクトのドキュメントでは通知のディスパッチについて別途説明しており、電子メール通知用にSMTP設定を構成する必要があると記載されています。これは、実際のインストールが CMS 13 である場合のトリガーとディスパッチ段階のチェックをサポートします。 CMS 12 の展開に同一のジョブのデフォルトがあることや、DXP SMTP例が変更されずに適用されることは確立されていません。バージョン化されたスニペットを混合するのではなく、構成手順をインストールされているバージョンに合わせてください。 CMS 13 プロジェクトの通知
すべての環境について、効果的なランタイム構成と、展開中に上書きされる可能性のあるソース ファイルを区別します。ステージングの成功は、設定の欠落または異なる From アドレスによって引き起こされる実稼働の失敗と共存する可能性があります。通常のエンジニアリング プロセスを通じて、サニタイズされた設定とアプリケーション ログを収集します。 SMTP認証情報、API キー、または無関係な運用上の秘密を証拠パケット内で公開しないでください。
制御された展開を通じて文書化された DXP トランスポートを構成する
DXP ガイドには、電子メール構成は標準構成変換によって自動的に適用されないと記載されています。ここでは、DXP 管理ポータルを介して電子メール サービス資格情報を取得し、アプリケーションにSMTP設定を提供する方法について説明します。この例には、アプリケーション通知 ID 設定とトランスポート設定が含まれています。デプロイされたバージョンと環境に対してサポートされている構成メカニズムを使用し、結果として得られる有効な値を確認します。 DXP 電子メールサーバーの構成
認証情報の作成、保存、ローテーションを、個別に制御されたセキュリティ操作として扱います。承認された有効な資格情報がすでに存在する場合、このガイドでは新しい資格情報は必要ありません。公開記事、リポジトリの例、 DNSレコード、またはサポートのスクリーンショットにシークレットを貼り付けないでください。代わりに、承認されたシークレット ストアと責任のあるオペレーターを参照してください。テスト時に、展開ログとエラー報告に資格情報が出力されないことを確認します。
文書化された DXP サービスは、自動トランザクション Web サイト通信用です。このガイドでは、独自のカスタム HTML テンプレートの使用など、他のSendGrid機能を必要とする顧客に、個別にサブスクライブしたアカウントまたは別のSMTPプロバイダーを案内します。 DXP SMTPへのアクセスが顧客管理のSendGridアカウントへの無制限のアクセスであると想定するのではなく、使用目的を確認してください。別のアカウントには、独自の所有権とドメイン認証手順があります。
送信ドメインごとに認証を要求する
文書化された DXP ルートについては、送信側ドメインの Optimizely に連絡して、送信者認証のアクティブ化についてサポートを求めてください。同じガイドには、メール送信ドメインごとにDKIM要求する必要があり、追加のDNSレコードが必要であると記載されています。何かを公開する前に、環境の正確なレコード セットとアクティブ化計画を取得してください。ユニバーサルなし セレクタ, CNAME ターゲット キーまたは秘密キーは製品名から派生できます。 DXP ドメインとDKIM構成
関連する通知で使用される、表示されているすべての From ドメインをリストします。マルチサイト アプリケーションまたは個別に構成されたワークフローが異なるドメインを使用する場合は、どの認証構成がそれぞれをカバーするかをサポートに問い合わせてください。企業のプライマリ ドメインを検証すると、すべてのサブドメインまたは代替ブランドが自動的にアクティブ化されるとは考えないでください。 DNS公開後に送信者側のアクティブ化を誰が確認する必要があるかを記録します。
DXP ページには、サンプルSPFポリシーが含まれています。これらは、運用ドメインの完全な処方箋ではなく、ドキュメントの例として扱ってください。実際のエンベロープ所有者を決定し、他の承認された送信者を保持し、そこで 1 つの有効なSPFポリシーを維持します。認可をマージする前に、再帰検索の制限を評価します。構成されたトランスポートが文書化された DXP サービスと異なる場合は、代わりにそのトランスポート自体の現在の指示を取得してください。 SPF RFC 7208
提供された各DKIMレコードを、提供されたタイプの正確な所有者で公開します。計画された移行中にアクティブなセレクターを保持し、保存する前にCNAME競合を解決し、秘密キーをDNS外部に保持します。権威サーバーにクエリを実行して、結果の名前と値を確認します。 DNSエディターのプレビューだけでは十分ではありません。パブリック レコードは、実際の送信メッセージが対応する署名 ID を使用する場合にのみ検証をサポートします。 DKIM RFC 6376
送信者 ID とDMARCポリシーの調整を維持する
テスト前に、意図した表示される From アドレスに同意します。正しいSMTPホスト名と有効な資格情報は、アプリケーションが承認された From ドメインを使用していることを証明するものではありません。有効な通知 ID とアプリケーション レベルのオーバーライドをトランスポート構成とは別に記録します。ビジネス上の決定なしに受信者が無人のメールボックスに誘導されないように、返信処理を確認してください。
表示されているドメインの現在のDMARCポリシーを検査し、承認された適用を維持します。 アライメント そしてレポート構成。少なくとも 1 つの通過するSPFまたはDKIM ID が該当するモードで一致する場合、 DMARC成功します。プロバイダー所有の署名ドメインは、組織の表示される From ドメインと一致しなくても、暗号化検証に合格できます。サポートされている送信者認証ルートを調べる前に、ドメイン全体のポリシーを弱めて応答しないでください。 DMARC RFC 9989
アプリケーションの接続、プロバイダー認証、および受信トレイの配置は、個別の受け入れ結果です。メッセージが送信されたことを示す CMS ログは、最終メールボックスからの受信ではありません。 DMARCを通過した受信メッセージは、他の理由でフィルタリングされる可能性があります。 1 つの成功したレイヤーによって他の場所で未解決の問題が隠蔽されないように、変更レポートでこれらの区別を保持してください。
再利用可能な CMS および DXP ルート ワークシート
導入環境ごとに、および実質的に異なる送信 ID ごとに個別のコピーを作成します。
- CMS バージョン、ホスティング モデル、プロジェクト、環境: ______。
- 正確なワークフロー、合成トリガー、および予想される受信者: ______。
- 構成ソース、展開リビジョン、および有効なランタイム設定: ______。
- トランスポートプロバイダー、アカウント所有者、および承認されたシークレット参照のみ: ______。
- 表示される差出人、表示名、返信先、およびエンベロープの期待値: ______。
- DXP の適用性と各送信ドメインを確認するサポート ケース: ______。
- 発行されたDNS所有者、タイプ、値、およびアクティブ化要件: ______。
- 既存のSPFおよびDMARCポリシーと承認された変更セット: ______。
- 信頼できる回答、クエリ時間、プロバイダーの検証ステータス: ______。
- ディスパッチ、 SMTP送信、およびプロバイダー配信の証拠: ______。
- 受信メッセージ From、エンベロープ、すべてのDKIM d=/s=ペアおよび信頼できる結果: ______。
- ロールバック展開、 DNS復元計画、人間による受け入れ: 保留中。
本番通知障害の架空診断
この例は架空のものです。チームはステージングでの承認通知のテストに成功し、アプリケーションをデプロイします。運用メッセージは、別の表示可能な From ドメインを使用します。 SMTP送信は成功しますが、独立した受信者は、運用ドメインと一致しない有効なプロバイダー署名を報告します。チームは、Campaign DKIMターゲットも Optimizely に属しているため、 DNSにコピーすることを提案しています。
提案された診断では、有効な運用アイデンティティと DXP サポート リクエストの対象となるドメインを比較します。このシナリオには、ステージング ID のみが含まれていました。修正計画は、運用送信ドメインに対してサポートされている認証構成を要求し、発行されたレコードを公開して、実際の承認ワークフローを再テストすることです。キャンペーン レコードを借用しても、DXP 署名者がそれを使用しているとは証明されません。これは実際に動作した例であり、ライブ テストや顧客の展開に関する主張ではありません。
変更されたレイヤーで回復する
アプリケーションがメッセージの送信を停止した場合は、 DNSを元に戻す前に、デプロイメント設定とトランスポート設定を比較してください。ドメインの検証が失敗した場合は、サポートが発行した所有者を信頼できる回答と比較します。認証は成功したが配信に失敗した場合は、送信者のアクセス許可を不必要に拡大せずに、プロバイダーと受信者の応答を検査します。重複した通知を識別できるように、再試行する前に証拠を保存します。
ロールバックでは、すべての資格情報をローテーションしたり、ゾーン全体をリセットしたりするのではなく、影響範囲の狭い展開またはDNS変更を復元する必要があります。置き換えられたセレクターを廃止するのは、メール所有者が、アクティブなルートまたはキューに入れられたルートにそれらのセレクターが必要ないことを確認した場合に限られます。文書化された DXP ブランチは確立されていますが、より広範な CMS バージョンの適用性、テナント固有の設定、サポートが発行した値、ライブDNS 、受信メッセージ、視覚的なレビュー、および SME による承認は保留中です。このガイドでは、アプリケーション構成、資格情報、 DNSレコード、ライブ ワークフローは変更されていません。
トランスポートセキュリティをコピーされた例から遠ざける
公開ページには構成ファイルのサンプルが混在しており、SSL を無効にしたコード設定が含まれています。この記事では、その設定やバージョンが一致しないスニペットは承認されません。デプロイメント所有者に、資格情報を公開せずに、実際のランタイムでサポートされているトランスポートとTLS動作を確認してもらいます。架空のケースでは、プロバイダーの署名だけでは、指定されていないSPF結果は決まりません。
ポリシーのロールアウトからメッセージの受け入れを分離する
整列されたSPF結果が合格すればメッセージ評価を満たすことができますが、それだけではドメイン全体を拒否するように移動することは正当化されません。 RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject そして、間接メールの相互運用性について警告します。ポリシー所有者が施行を承認する前に、すべての正当な送信者と間接ルートをインベントリします。この記事では、 DNS変更、テナントの操作、受信メッセージのテストは実行されていません。