Sender Authentication Package (SAP) の変更は、新規SKUの購入・消費を伴う再構築プロセスであり、その考慮点は環境ごとに多岐に渡ります。本記事では、これらの変更に伴う Marketing Cloud Engagement (MCE) の移行前後の考慮事項について、特に「配信到達性(Deliverability)」への影響の観点から解説します。
*本記事の対象はMarketing Cloud Engagementとします。Marketing Cloud Next に含まれるMarketing Cloud Growth & Advanced Editionsは観点が異なる場合があります。
Marketing Cloud Engagement (MCE) において、SAP ドメインには「1 ビジネスユニット (BU) につき 1 つ」というシステム上の制約があります。そのため、SAP ドメインの変更は単なる設定値の上書きではなく、旧ドメイン設定の削除と新ドメインの新規セットアップを伴う再構築作業となります。SAPドメインやIPの設定状況はご利用の環境によってそれぞれ異なるため、SAPドメイン変更前後でどの点が変わるかを把握することが重要となります。特にPTRレコードの整合性確保やドメインのウォーミングアップを考慮することが重要です。
変更リクエストを行う前に、契約状況および現在の構成を確認してください。
SAP SKU: ドメインを変更するには、新規 SAP SKU の購入あるいは消費が必要です。
SSL SKU: 画像、クリックリンク、CloudPages等を保護するため、新規 SSL SKU の購入あるいは消費が必要です。
注意: SSLの設定はSAP適用完了後、さらに最大で 3〜4週間を要する場合があります。よってSAPの変更や予期せぬ手戻りなどを加味すると1-2ヶ月あるいはそれ以上など余裕を持ったスケジュールの確保を推奨します。
通常のSAP設定と同様 email.example.com のようなサブドメインを利用します。 企業のルートドメインは原則としてSAPドメインには利用できません。
もし企業のルートドメインを送信元として利用したい場合は、プライベートドメインでの利用を検討します。
削除対象のSAPドメインが、他のBUでSAPまたはPDとして利用されていないか確認します。他のBUで利用されているにも関わらず、旧SAPドメインのDNSレコードを削除してしまうと、他BUでの配信到達性や各種機能が利用できなくなる可能性があります。
受信側サーバは、接続してきた送信元の「IPアドレス」と、そのIPが名乗っている「ドメイン」が一致しているかを厳格に検証します(FCrDNS認証)。 通常、送信IPアドレスはSAPドメインを利用したホスト名がPTRレコードに設定されています。SAPドメインの変更要求だけでは通常このPTRレコードのドメインは自動的に変わりません。
そのため、SAPドメインを変更し当該ドメインのDNSレコード変更が反映された後、PTRレコードに紐づくAレコードの名前解決ができなくなり、FCrDNSの失敗によりバウンスなどが発生して配信到達性に悪影響を与える場合があります。
各BUに割り当てられている送信IPアドレスを確認し、旧SAPドメインにPTRレコードが割り当たっている場合はPTRレコードの変更をサポートケースでリクエストしてください。
1.当該BUに割り当たっている送信IPアドレスの確認方法
配信プロファイルを作成する際に、当該MIDに割り当たっているIPがプルダウンから選択できます。その際に確認できます。手順は下記をご参照ください。
URL) https://help.salesforce.com/s/articleView?id=mktg.mc_es_delivery_profiles.htm&type=5
2.PTRレコードの確認例
外部のウェブツールや、ターミナルでのDNS名前解決のコマンド(dig, nslookup等)を利用してPTRレコードを確認します。下記のような場合、PTRを新しいSAPドメインやデフォルトのドメインに変更する必要があります。このような割り当てが確認されたIPアドレスをサポートケースに申告してください。
------------
*設定例: 既存のSAP設定が old-sap.example.comの場合
・送信IPアドレス: 1.2.3.4
・PTR: mta.old-sap.example.com
------------
新ドメインへの切り替え直後は、ドメインのレピュテーションが小さい可能性があり、受信ISPにより通常よりも許容される通数が少なくなる可能性があります。また、ドメイン切り替え後に想定通りDNSレコードが更新されておらずSPFやDKIMなどがFailすると言った事例もあります。よってこれらを一定期間チェックする必要があります。
SAPドメイン変更およびDNS設定完了後、本格的な配信を開始する前にテスト送信を行い、SPF、DKIM、DMARCが正しく Pass していることを検証します。
1. テスト送信の対象範囲(送信元)
以下の送信元パターンをテストすることを推奨します。
送信元が新しい SAP ドメイン: 最も基本となるテストです。
送信元が同BU内のプライベートドメイン: SAPを変更したビジネスユニットに、別途プライベートドメインが設定されている場合、それらも送信元としてテストしてください(DKIMやDMARCアライメントへの影響を確認するため)
旧SAPドメインがPTRに割り当てられていた全IPアドレス: 旧SAPドメインがPTRレコードに割り当てられていた送信IPから送信されるようテストし、FCrDNSの検証によるバウンスが発生しないことを確認します。
2. テスト送信先(受信側)の選定
テストメールの宛先には、Gmail、Outlook.comなどの主要な一般消費者向けISP(Webメール)を使用してください。 これらを複数選定する理由は、特定のISPに起因する問題と切り分けるためです。
注意 - 企業ドメインの利用は避ける: 企業のメールアドレス宛にテストすると、社内のセキュリティゲートウェイや転送設定によってメールヘッダーが書き換わり、SPF/DKIMが「Fail」となるケースがあります。純粋なDNS設定の検証には適しません。
3. ヘッダー情報の確認(Before / After)
受信したメールのヘッダー情報を確認し、認証結果と設定の変更が反映されているかを確認します。
認証結果: Authentication-Results ヘッダーを確認し、SPF、DKIM、DMARC がすべて pass であることを確認してください。
Envelope From (Mail From) の変化: SAPの変更に伴い、バウンスメールの返送先(Envelope From)も上記のように切り替わります。ヘッダー上でこの変更が反映されていることを確認してください。
変更前: bounce.[旧SAPドメイン]
変更後: bounce.[新SAPドメイン]
[補足] プライベートドメイン利用時のDMARCアライメント
通常、プライベートドメインを送信元(Fromアドレス)に使用しても、Envelope From は SAPドメイン(bounce.[新SAPドメイン])となります。 もし、この不一致によってDMARC検証が失敗(Alignment Fail)する場合は、「マルチバウンスドメイン」機能の有効化が必要になる可能性があります。マルチバウンスドメインについては下記の記事をご参照ください。
https://help.salesforce.com/s/articleView?id=004464661&type=1
ドメインが変わるため、ISPによっては IP アドレスが同じでもウォーミングアップ(スロットリング)が必要となる場合があります。変更直後は配信量を徐々に増やす運用を行うことを検討してください。
またSAPの変更に伴い、SAPに付属する占有IPを新たにBUに割り当てる場合は、当該IPのウォーミングアップもあわせて検討が必要になります。
変更後は、Automation Studio の SQL クエリアクティビティ等を使用し、_Bounce データビューを用いるなどしてバウンスの状況を通常より慎重に監視することを推奨します。
特にバウンスが増えた場合、SMTPBounceReason の項目を精査し、下記などのDNS設定の不備やレピュテーションの不足が疑われるようなワードがないか確認します。
ワード例:
FCrDNS: 逆引き設定の不一致(PTRレコードの設定漏れを示唆)
DKIM fail / SPF fail: 認証設定の不備
Block, Reject: レピュテーション不足によるブロックを示唆
参考:
バウンスデータビューの利用方法については、以下の動画リソース等を参考にしてください。
【Salesforce サポート】Marketing Cloud | 初めてのデータビュー 〜簡単にデータビューのデータを確認するノウハウ〜
https://www.youtube.com/watch?v=UesjB6RVhlQ
送信済みの過去メール内の画像やリンクは、引き続き旧ドメインを参照します。 通常、旧ドメインのDNS設定はSalesforce側で約60日間維持されます。この期間中は、過去メールの画像表示や、購読解除等のメール内リンク遷移、OpenやClickトラッキング、RMMが機能します。
重要:
Salesforce側で設定が維持されていても、お客様側で削除・変更するドメインの DNS 設定変更(NSレコードの委任解除、もしくはセルフホストの場合は各レコード削除)を行うと、その設定が伝播した時点で即座に旧ドメインが解決できなくなります。 これにより、過去メールの画像非表示、開封・クリック計測不能、購読解除リンクのリンク切れ、RMMなどが機能しなくなります。この影響を十分に把握した上で、削除のタイミングやユーザーへの事前通知を検討してください。
Q. SAPやSSLの設定完了日時を指定したり短縮することは可能ですか
A. いいえ、原則として完了日の指定はできません。設定作業には時間を要するため、余裕を持った計画を推奨します。
Q. 新旧SAPドメインを並行稼働できますか
A. いいえ、1 BUにつき1 SAPドメインという制約があるため、並行稼働はできません。
Q. 引き続き旧SAPドメインを送信元として利用したいです
A. プライベートドメインとして別途プロビジョニングすることを検討してください。
Q. 当該SAPドメインの利用をただちに取り止めたい場合はどうすれば良いですか
A. DNS設定側で当該SAPドメインの委任を解除、もしくはセルフホストの場合は必要なレコードを削除すれば、外部から当該ドメインへのアクセスは遮断されます。ただし、これに伴い画像表示やリンク遷移、開封検知など、SAPドメインに依存する各機能も即座に利用できなくなる点を考慮してください。
特に重要なリスクとして、項目3で解説した通り、送信IPアドレスのPTRレコードがそのSAPドメインを利用している場合、DNSレコードを削除するとFCrDNS認証(逆引き認証)が失敗します。さらに、SPFやDKIMといった送信ドメイン認証の参照先も消失するため、認証失敗によりほとんどのISPでメールが拒否(ブロック)される事態が想定されます。
当該IPを利用するすべての送信に壊滅的な影響が出る可能性があるため、この点を十分に留意してください。また、万が一の事態に備え、即座にレコードを復元(切り戻し)できる準備をしておくことを強く推奨します。
Q. DNS設定変更後、反映まで何日程度かかりますか
A. DNSの伝播速度はインターネット上の各DNSサーバの状況によるため、弊社側で回答することはできません。数時間程度で終わることもあれば、数日程度要する場合もあります。DNSチェックツールや実際の配信テストを行い、伝播状況を確認してください。
Q. ドメインのウォーミングアップを行う際、推奨される配信通数や期間はどの程度ですか
A. ISPが新しいドメインからのメールをどの程度受け入れるかは、その時点でのレピュテーションや受信者のエンゲージメントなど、総合的な要素で判断されます。また、これらの判定基準は公開されていないため正確なご案内ができかねます。しかしながら、一般的な指針として、まずは「過去に開封・クリックの実績があるエンゲージメントの高いユーザー」に限定し、少量の配信から開始してください。その後、バウンス率やスパム報告率を監視しながら、徐々に配信量を増やしていく運用を推奨します。
具体的にはドキュメントも併せて参照してください。
https://help.salesforce.com/s/articleView?id=mktg.mc_es_ip_address_warming.htm&type=5
*本挙動は執筆時点のもので、予告なく変更される場合があります
*SAP/PDおよび送信IPの設定状況は環境によってそれぞれ異なるため、上記を参考に設定変更前後の状況を熟慮のうえ変更を計画してください。
SAP, Private Domain および Email 関連設定 ポイントまとめ / FAQ 集
https://help.salesforce.com/s/articleView?language=ja&id=004269074&type=1
005314220

We use three kinds of cookies on our websites: required, functional, and advertising. You can choose whether functional and advertising cookies apply. Click on the different cookie categories to find out more about each category and to change the default settings.
Privacy Statement
Required cookies are necessary for basic website functionality. Some examples include: session cookies needed to transmit the website, authentication cookies, and security cookies.
Functional cookies enhance functions, performance, and services on the website. Some examples include: cookies used to analyze site traffic, cookies used for market research, and cookies used to display advertising that is not directed to a particular individual.
Advertising cookies track activity across websites in order to understand a viewer’s interests, and direct them specific marketing. Some examples include: cookies used for remarketing, or interest-based advertising.