アカウントエンゲージメントを他のSalesforceメール製品から分離する
Salesforce Account Engagement には、独自のドメイン管理ワークフローがあります。まず、メッセージが、コアのSalesforceメールや Marketing Cloud Engagement ではなく、Account Engagement (以前は Pardot と呼ばれていた) を通じて送信されていることを確認します。別のSalesforce製品のDNSレシピは異なるコントロールを使用できるため、組織が同じベンダーを使用しているという理由だけでインポートしないでください。このガイドでは、アカウント エンゲージメントの送信ドメインの検証について説明します。 DKIM およびオプションのサポート支援カスタム リターン パス。
各ビジネス ユニット、ブランド、およびアカウントで使用される対象の From ドメインをリストします。キャンペーンおよび自動化設定によって選択された実際の送信者を含めます。ユーザーのメールボックス アドレスに表示されるドメインは、すべてのアカウント エンゲージメント ルートに対して自動的に構成されるわけではありません。共有ドメインのレコードを変更する前に、マーケティング所有者とDNS管理者を割り当てて、一緒にインベントリを確認します。
受け入れの目標は、調整された通過認証メカニズムを使用して制御された受信メッセージです。ドメイン所有権の検証、 DNS公開、およびグリーン管理ステータスは、有用な中間証拠となります。特定のキャンペーンが意図した ID を使用したこと、または受信サーバーがその認証を受け入れたことを単独で証明するものはありません。
ルートDNSを編集する前にデフォルトのSPFパスを理解する
Salesforce's アカウントエンゲージメントDNSガイダンス アカウントエンゲージメントメールが通過することを示します SPF 制御された送信インフラストラクチャを通じて送信されるため、デフォルト設定に対して顧客によるSPF変更は必要ありません。製品SPF Salesforce DMARC 報告。最初に実際のルートと評価された ID を確認します。
SPF SMTPを認証します メール送信元 ID、個別の処理あり HELO、 下 RFC 7208。その結果は次のものとは異なります アライメント From が表示されます。プロバイダー ドメインのSPFチェックが成功すると、調整されていないSPFと共存できます。別のドメインのポリシーを変更しても、メッセージが使用するエンベロープ ドメインは変わりません。
組織の他のサービスに必要なSPFポリシーを保持します。個別に承認されたカスタム セットアップでポリシーの変更が必要な場合は、その所有者で、ネストされた DNS クエリ用語やプロトコル ルックアップ制限を含む 1 つの完全なポリシーを確認してください。 2番目を作成しないでください SPFレコード または、無関係の送信者を削除して、未検証の要件を受け入れる余地を作ります。
所有権とDKIM別のレコードとして検証する
ドメイン管理を使用して、目的の電子メール送信ドメインとその予想されるDNSエントリを特定します。の DNSガイダンス ドメインの検証キーとその DomainKey を区別します。検証値により、送信の所有権が確立されます。 DKIM値はメッセージ署名をサポートします。ワークシートでは、どちらかの目的を扱うのではなく、両方の目的を保持します。 TXTレコード 交換可能な証拠としてSalesforce値が含まれています。
実際のアカウントから値をコピーします。 DNS変更する前に、完全なレコードの所有者、タイプ、値、および指示の日付を保存してください。別の Account Engagement アカウントまたは別のサービスがすでに同じ所有者に依存していないかどうかを確認します。競合するレコードを上書きしたり、別の顧客の値を再利用したり、レコードを変更したりしないでください。 セレクタ 発明された名前に。アカウントの取り決めが衝突する場合は、サポートされている解決策についてサポートに問い合わせてください。
電子メール送信ドメインをトラッカー ドメインとは区別してください。 Salesforce 、これら 2 つの機能に同一のドメインを使用しないことを明示的に警告します。ブランドの追跡ホスト名は、たとえ両方が親を共有している場合でも、From ドメインと同じものではありません。インベントリの依存関係を個別に追跡するため、認証作業によってアセット URL やキャンペーン リンクが不用意に変更されることはありません。
文書化されたワークフローを通じて DomainKey を公開する
Salesforce's DKIM実装手順 アカウントエンゲージメント管理者の役割が必要です。 Lightning アプリケーションで、[アカウントエンゲージメント設定]、[ドメイン管理] の順に開きます。代替のアカウントエンゲージメントインターフェイスでは、文書化された開始点は管理者です。 [電子メール送信ドメイン] で、選択したドメインの [予想されるDNSエントリ] を開き、公開用の DomainKey 値をTXTとしてコピーします。
そのアカウントとドメインに対して表示されている所有者と値を使用します。現在の記事では、レコードが追加されてから署名が有効になるまでに最大 24 時間かかると記載されています。これはプロバイダーのタイミング ガイダンスとして扱い、すべてのDNSキャッシュまたはレシーバーが同時に更新されることを保証するものではありません。公開時間を記録し、予想される状態になるまで待ってから、新しいテストを判断します。
正確な完全修飾所有者を含むパブリックDNS応答を確認します。 DNS編集者はゾーン名をホスト フィールドに追加し、フルネームを入力すると重複したサフィックスを作成することがあります。入力フォームを信頼するのではなく、結果として得られた回答を確認してください。ドメイン管理エラーとその詳細を保存して、サポートが言い換えステータスではなく実際の障害を調査できるようにします。
カスタムリターンパスが必要かどうかを決定する
Salesforce's DMARCサポート記事 では、整列されたDKIM通常のDMARCパスとして説明し、デフォルトの DKIM が リターンパス ドメインが表示されている From と一致しません。また、サポート支援によるカスタム リターン パス リクエストについても文書化されています。規定されている制限は、メッセージごとに選択される可変ドメインではなく、ビジネス ユニットごとに 1 つの固定カスタム リターン パス ドメインです。
このオプションをリクエストする前に、ビジネス要件を特定してください。 DKIMだけでなくSPF調整も必要な組織は、サポートを受けて実際のドメインの配置と調整モードを評価する必要があります。無関係なブランドに送信しているビジネス ユニットは、1 つの固定リターン パスがすべての From ドメインに対応できると想定すべきではありません。観察された ID とサポートされている構成によってその設計上の疑問が解決されるまで、その設計上の疑問は解決しないでください。
サポート ケースから正確なDNSレコードを取得し、 DNS所有者に競合と依存関係を確認してもらいます。この記事では、ユニバーサル カスタム リターン パス ターゲットやアクティベーション スイッチは提供しません。推測されたレコードを公開したり、別の製品のバウンス ドメイン設定をコピーしたりすると、要件を満たさずに作業ルートが中断される可能性があります。
実際のメッセージ フローを通じて選択した送信者をテストします
実質的に異なるそれぞれの送信ドメインとビジネス ユニットのルートを通じて、無害な制御されたメッセージを送信します。計画されたキャンペーンまたはオートメーションと同じ送信者の選択を使用します。キャンペーン参照、メッセージ ID、UTC 時間、および外部テスト受信者を記録します。プレビュー機能またはテスト機能が運用環境とは異なるパスを使用している場合は、それを代表的な証拠として扱う前に、その違いを解決してください。
信頼できる受信システムで、From、 Return-Path 、およびすべてのDKIM署名ドメインとセレクターをキャプチャします。 RFC 6376 公開検証キーを見つけるために使用される d= 値と s= 値を定義します。観察された署名ドメインと構成された送信ドメインを比較します。メッセージが予期しない送信者または別のルートを使用している場合でも、 DNSレコードは正しい可能性があります。
適用する RFC 9989 実際の結果に。 DMARC整列した通過を通過できます DKIM署名 または、調整されたSPFを渡します。どのメカニズムが結果を提供したか、およびどの位置合わせモードが適用されたかを記録します。 SPF認証、 SPFアライメント、 DKIM認証、およびDKIMアライメントを別のフィールドに保持します。これにより、単一の緑色のステータスによって未テストの要件が隠蔽されることがなくなります。
すべての制御を変更するのではなく、障害のある境界のトラブルシューティングを行う
送信ドメインが検証されていない場合は、その検証キーと正確なDNS所有者を予想されるDNSエントリと比較します。予想されるアクティベーション期間を過ぎてもDKIM見つからない場合は、選択した From ドメインとアカウントを確認し、ドメイン管理エラーを確認します。署名が失敗した場合は、セレクターとパブリック値を確認し、署名後にメッセージを変更するダウンストリーム システムを検査します。
SPFが合格したにもかかわらずDMARC失敗した場合は、アライメントと、その送信者に対してアライメントされたDKIM構成されているかどうかを調査します。デフォルトのSPF成功をDMARC成功を約束するものとして扱わないでください。カスタム リターン パスが関係している場合は、観察されたエンベロープ ID を、固定のビジネス ユニット設定およびサポートが提供する指示と比較します。代表的な失敗メッセージを診断用に保存します。
組織のDMARCポリシーとレポート送信先を既存の所有権の下に維持します。 Salesforce記事では、Account Engagement がそれらを収集するのではなく、外部DMARCモニタリングの必要性について説明しています。 失敗レポート。 DNS認証作業は、報告先を黙って置き換えたり、無関係な送信者に対する強制力を低下させたりするべきではありません。提案されたポリシーの変更をメールおよびセキュリティの所有者と個別に確認します。
アカウントエンゲージメントドメインワークシート
- アカウント、ビジネスユニット、ブランド、送信ワークフロー: ____。
- 送信元アドレスを選択し、電子メール送信ドメインを構成しました: ____。
- 別のトラッカー ドメインとその既存の依存関係: ____。
- 期待されるDNSエントリ: ____ からの検証キーとDKIMレコード参照。
- パブリックDNS回答、公開時間、管理ステータス: ____。
- デフォルトまたはサポートによるカスタム リターン パス設計: ____。
- カスタムリターンパス制限と関連する場合のサポート確認: ____。
- メッセージ ID、UTC 時間、From、 Return-Path 、 DKIM ID をテストします: ____。
- 信頼できる認証結果と調整されたDMARCメカニズム: ____。
- 例外、監視所有者および承認されたリカバリ: ____。
アライメントなしでSPF成功した架空の例
架空のケースのみ: AE-01 は、North のビジネス ユニットがnews@example.orgとして送信し、South のビジネス ユニットがnews@example.netとして送信すると想定しています。 bounce.example.orgで提案されている固定カスタム リターン パスは、緩和されたSPFアライメントの下で最初のパスと一致する可能性がありますが、無関係な 2 番目のパスと一致するとは想定できません。 DKIM署名とSPF結果は不明なままであるため、どちらのルートもDMARC判定をアサートしていません。マーケティングおよびメールの所有者は、ルートSPF編集を要求する前に、ビジネス ユニットの設定を分離し、選択した From ドメインごとに調整されたDKIM検証する必要があります。すべてのアイデンティティと取り決めは発明されたものです。サポート ケース、 DNSクエリ、またはメッセージは実行されませんでした。
完了を生きた証拠に結び付けておく
文書化されたワークフローでは、実際のテナントの権限、生成された値、カスタム リターン パス機能は検証されません。これらのアカウントのチェック、ライブDNSとヘッダーの検証、視覚的なレビュー、および SME による人間の承認は保留中です。このガイドは未公開であるため、組織のキャンペーンが本番環境で認証されていることを証明するものとして提示してはなりません。
通過メッセージを施行の準備から切り離す
RFC 9989セクション 7.4 では、 p=reject公開するドメインに有効なDKIM必要であり、間接メールの相互運用性についての注意が必要です。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。