Salesforce Marketing CloudのSPF・DKIM・DMARC設定。
Salesforce Marketing Cloud Engagement（旧ExactTarget）の認証は、セルフサービス型のメール配信サービス（ESP）とは仕組みが異なります。レコードを貼り付けて「verify」をクリックするだけでは完了しません。Sender Authentication Package（SAP）または簡易版のPrivate Domainアドオンを購入すると、Salesforceがアカウント専用の送信用サブドメイン（通常は専用IPも）をプロビジョニングします。そのうえで、自社側でこのサブドメインをSalesforceのネームサーバーに委任するか、Salesforceの到達率チームから渡されたSPF、DKIM、MXの正確なレコードを公開します。このガイドでは、実際のSAPの手順に沿って、SPFのinclude:cust-spf.exacttarget.comメカニズム、共有の200608 DKIM鍵と、自社ドメインとアライメントが実際に一致する、CNAMEで委任された専用鍵の違い、サブドメインの委任と自社ホスティングの比較、Reply Mail Management、自分で追加する必要があるDMARCレコードを解説します。
Salesforce Marketing Cloudを認証すべき理由
2024年2月以降、GmailとYahooは、すべての大量送信者に対し、SPFとDKIMに成功し、DMARCポリシーを満たすことを義務付けています。これらを満たしていないと、まさにオーディエンスが利用しているメールプロバイダーで、Marketing Cloudからの送信がスロットリングされたり、迷惑メールに振り分けられたりします。SAPで正しく認証すれば、共有ドメインや「via」の表示がなくなり、クリックトラッキング、画像、View-as-webpage、CloudPagesのリンクに自社ブランドが使われます。さらに、クリーンなレピュテーションを築ける専用IPを使って、SFMCから送信できるようになります。SAPでは自社ドメインのサブドメインから送信するため、SPF（サブドメイン上のエンベロープ/Return-Path）とDKIM（サブドメイン上の専用鍵）のどちらも、DMARCのアライメントを組織ドメインと一致させられます。これは多くのESPより有利な条件ですが、デフォルトの共有鍵200608ではなく専用のDKIM鍵で署名し、すべてを正しく公開していることが前提です。
Salesforce Marketing CloudにおけるSPFの実情
SFMCをSPFで認可するには、実在する有効なincludeであるinclude:cust-spf.exacttarget.comを使います。現時点で解決すると、約50個のip4範囲を並べて~allで終わる単一のフラットなレコードが返り、ネストしたincludeはありません。そのためSPFの10回のDNSルックアップのうち、消費するのはちょうど1回です。通常の「このincludeをSPFレコードに追加する」タイプのサービスとは、2つの点で異なります。1つ目に、このincludeを置く場所は専用のSAP送信用サブドメイン（例：cloud.yourdomain.com）であり、ルートドメインではありません。SFMCがルートドメインそのもので送信することはほとんどないため、ルートドメインに追加しても、たいていは何の役にも立たないルックアップが増えるだけです。2つ目に、Salesforceが推奨する構成ではサブドメイン全体をNSレコードでSalesforceに委任し、SPFレコードもSalesforceがホストするため、SPFの文字列に直接触れる機会がないこともあります。自社でDNSをホストする場合に限り、v=spf1 include:cust-spf.exacttarget.com ~allをサブドメインに自分で公開します。いずれの場合もサブドメイン独自のSPFレコードに置かれるため、ルートドメインのDNSルックアップの10回制限には影響しません。このincludeを既定でルートドメインのSPFレコードに追加すべきでないのは、このためです。
2つの設定方法
送信用サブドメインをSalesforceに委任（推奨）
- SAPサブドメイン（例：cloud.yourdomain.com）がSalesforceのネームサーバーを指すNSレコードを追加
- SPF（cust-spf.exacttarget.com）、専用のDKIM鍵、返信用のMX、トラッキング用レコードはSalesforceがホスト
- Salesforceが専用のDKIM鍵を自動でローテーションできるため、鍵の手動調整は不要
- 保守の手間が最も少なく、レコードの入力ミスも起きにくい
- そのサブドメインのSPF/DKIMを親ゾーンにも公開しないこと
SAPレコードを自社のDNSでホスト
- DNSを社内で管理し、Salesforceの到達率チームが提供するレコードをそのまま公開
- SPF：送信用サブドメインにv=spf1 include:cust-spf.exacttarget.com ~allを追加
- DKIM：Salesforceが提供するアカウント固有のCNAME（またはTXT）を公開。CNAMEをTXTに変換しないこと
- MX：返信用サブドメインにReply Mail Managementのレコードを追加
- DKIM鍵のローテーションの調整は自社の担当。管理の自由度は高まるものの、保守の手間も増える
設定手順
- 1
SAPまたはPrivate Domainの契約を確認
SFMCの認証はセルフサービスではありません。自社ドメインで認証するには、有料のSender Authentication Package（または簡易版のPrivate Domainアドオン）が必要です。Salesforceは、月間約250,000通を超える送信者向けと位置付けています。これがなければ、レコードを公開できない共有のexacttarget.comドメインから送信することになります。プロビジョニングはアカウントチームを通じて進みます。DNSと設定の部分は、依頼フォームの提出後およそ5営業日が目安ですが、契約とIP割り当てにはさらに時間がかかるため、まずここから始めてください。
- 2
専用の送信用サブドメインを決める
SAPがプロビジョニングするプライベートドメインは、自社ブランドのサブドメインです。一般的にはcloud.yourdomain.com、email.yourdomain.com、mkt.yourdomain.comなどです。アカウント内のすべてのFromアドレス、リンクと画像のトラッキングURL、View-as-webpageリンク、CloudPageで使われるため、受信トレイやブラウザーで長く目にしても問題ないサブドメインを選んでください。
- 3
委任と自社DNSホスティングのどちらかを選択
推奨は、NSレコードで送信用サブドメインをSalesforceのネームサーバーに委任する方法です。委任すると、SPF、DKIM、トラッキング、返信の各レコードはSalesforceが管理するゾーンファイルからSalesforce側でホストされ、DKIM鍵のローテーションも任せられます。もう1つは、DNSを社内で管理し、Salesforceが提供する正確なレコードを公開する方法です。委任は保守の手間が少なく、自社ホスティングは管理の自由度が保てる一方で、鍵のローテーションの調整を自社で担うことになります。
- 4
委任する場合：サブドメインのNSレコードを追加
送信用サブドメインについて、担当チームから提供されたSalesforce/ExactTargetのネームサーバーを指すNSレコードを作成します（例：cloud.yourdomain.com NS -> Salesforceのゾーンファイルにあるホスト）。そのサブドメインのSPFやDKIMを親ゾーンにも公開しないでください。委任された子ゾーンが権威を持ち、親ゾーンのレコードは無視されます。
- 5
自社でホストする場合：サブドメインにSPFレコードを公開
委任しない場合は、送信用サブドメインにTXTレコードv=spf1 include:cust-spf.exacttarget.com ~allを追加します。これはSalesforceのドキュメントに記載されている値です。~allを-allに厳格化するのは、そのサブドメインで他に送信しているものがないと確認してからにしてください。SPFのTXTレコードは必ず1つだけにし、2つ作らないでください。
- 6
DKIM鍵を公開
SAPは専用のDKIM鍵をプロビジョニングし、Salesforceは通常、送信用サブドメイン上のCNAMEレコードとして委任します。セレクターはアカウントやスタックごとに固有で、たとえば[stack]dkim1._domainkey.cloud.yourdomain.comが[stack]dkim1._domainkey.sNN.exacttarget.comを指す形です。これにより、秘密鍵の保持とローテーションはSalesforceに任せたまま、署名は自社ドメインとアライメントが一致します。古い構成では、代わりに生のTXT公開鍵を渡され、それを公開することもあります。共有の200608セレクターはexacttarget.com上の従来の鍵で、自社ドメインとアライメントが一致しません。Salesforceが提供するものをそのまま公開してください。Salesforce本体のSetup > DKIM Keysとは異なり、自分で鍵を生成することはありません。
- 7
Reply Mail Managementを設定
認証済みの返信用ドメインを設定し、購読者からの返信、不在通知のバウンス、手動の配信停止依頼がSFMCを経由して戻るようにします。これにより、返信用サブドメイン（および同様のバウンス用サブドメイン）に、Salesforceの受信インフラを指すMXレコードが公開されます。省略すると、キャンペーンへの返信は行き場を失います。
- 8
DMARCレコードを追加し、確認して有効化
SAPはDMARCレコードを作成しないため、_dmarc.yourdomain.comのTXTレコードを自分で追加します。まずv=DMARC1; p=noneから始め、ruaの受信先を指定します。SFMC SetupでプライベートドメインがActive/authenticatedと表示されていることを確認し、シードメールを送信します。ヘッダーにspf=passとdkim=passが表示され、d=ドメインとエンベロープドメインのアライメントが（exacttarget.comではなく）自社サブドメインと一致していることを確認してください。集計レポートに問題がなければ、ポリシーをquarantine、次にrejectへと引き上げます。
追加するレコード
正確な値はSalesforce Marketing Cloudのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | cloud.yourdomain.com | v=spf1 include:cust-spf.exacttarget.com ~allSAP送信用サブドメインのSPFレコード（自社ホスティングの場合）。推奨の委任モデルではSalesforceがホストするため、ここではDNSを社内で管理するアカウント向けに示しています。ここに示す送信用サブドメイン名は例で、実際の名前はアカウントごとにプロビジョニングされます。サブドメイン独自のSPFレコードに置かれるので、ルートドメインのDNSルックアップの10回制限には影響しません。 |
| CNAME | s10dkim1._domainkey.cloud.yourdomain.com | s10dkim1._domainkey.s10.exacttarget.com専用のSAP DKIM鍵。SalesforceがローテーションできるようCNAMEで委任しており、DMARCで自社ドメインとアライメントが一致するのはこの鍵です。セレクター（例：[stack]dkim1）とスタック番号（sNN）はアカウント固有なので、Salesforceが提供するとおりに公開してください。CNAMEをTXTに変換したり、ホスト名を短縮したりしないでください。 |
| TXT | <selector>._domainkey.cloud.yourdomain.com | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...DKIMの別の形式。SAPの構成によっては、CNAMEレコードの代わりに生のTXT公開鍵を渡されることがあります。セレクターはアカウント固有で、Salesforceから提供されます（アライメントが一致しない共有のデフォルトは、自社ドメインではなくexacttarget.com上の200608です）。鍵は例です。そのままコピーしないでください。 |
| MX | reply.yourdomain.com | reply.s10.exacttarget.comReply Mail ManagementのMXレコード。購読者の返信、不在通知、配信停止依頼がSFMCを経由するようにします。同様のバウンス用サブドメインのMXレコード（bounce.sNN.exacttarget.com）もプロビジョニングされます。返信用サブドメイン、スタック（sNN）、MXホストはアカウントごとに異なります。ここに示す値は例です。 |
| TXT | _dmarc.yourdomain.com | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCは自分で追加します。SAPが作成することはありません。p=noneから始め、レポートに問題がなければquarantine、rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Salesforce Marketing Cloudの設定がこの上限のうち何回を消費するかは、次のとおりです。
Salesforce Marketing Cloudは10回のルックアップのうち1回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
Salesforce Marketing Cloudには、DKIMの仕組みが2種類あります。従来のデフォルトは、セレクター200608の単一の共有鍵です。2006年に作成されたもので、プライベートドメインを持たないすべてのSFMCアカウントが使用しています。この鍵はexacttarget.comで公開され、d=exacttarget.comとして署名するため、DMARCではFromドメインとアライメントが一致しません。固定のTXTセレクターなので、ローテーションもしにくい鍵です。一方、SAPやプライベートドメインをプロビジョニングすると、Salesforceは専用のDKIM鍵を発行し、通常は送信用サブドメイン上のCNAMEレコードで委任します。セレクターはアカウントやスタックごとに固有で、たとえばs10dkim1._domainkey.cloud.yourdomain.comがs10dkim1._domainkey.s10.exacttarget.comを指す形です。これによりSalesforceが秘密鍵を保持してローテーションしつつ、署名は組織ドメインとアライメントが一致します。構成によっては、代わりに生のTXT公開鍵を渡され、それを公開することもあります。いずれの場合も正確なレコードは常にSalesforceが提供し、自分で鍵を生成することはありません。この点は、Setup > DKIM Keysで鍵を作成するSalesforce本体のSales/Service Cloudとは異なります。専用のSAP鍵は自社ドメインのサブドメインで署名するため、DMARCに成功するための最も確実な方法です。デフォルトの共有鍵200608に頼らず、ドメインとアライメントが一致する専用鍵がパッケージに含まれていることを確認してください。
DMARC
SAPはDMARCポリシーの作成も管理も行わないため、自分で公開します。_dmarc.yourdomain.comにTXTレコードを追加し、まずはv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとして、配信に影響を与えずに集計レポートを収集します。SAPでは自社ドメインのサブドメインから送信するので、SPFはそのサブドメイン上のエンベロープ/Return-Pathで、DKIMは専用のSAP鍵でアライメントを一致させられます。つまりどちらでもDMARCに成功できますが、より堅実なのはDKIMです。共有の200608鍵だけではアライメントが一致しないため（exacttarget.comとして署名します）、ポリシーを適用する前に、アカウントが専用鍵で署名していることを確認してください。サブドメインポリシーにも注意が必要です。p=rejectを設定する場合は、sp=を意図的に追加し、SAP送信用サブドメインの認証が完全に済んでいることを先に確認します。レポートで正規のSFMC（およびその他）のメールがすべてアライメント一致で成功していると確認できてから、ポリシーをp=none -> quarantine -> rejectの順に引き上げてください。
正しく設定できたか確認する
送信用サブドメインのSPFをクエリ（dig +short TXT cloud.yourdomain.com）し、include:cust-spf.exacttarget.comに解決されることを確認します。次に、共有の200608セレクターではなく、Salesforceから渡されたDKIMセレクターを確認します（例：dig +short CNAME s10dkim1._domainkey.cloud.yourdomain.com。生の鍵を渡された場合はTXTでルックアップします）。管理下のメールボックスにシードまたはテストのキャンペーンを送信し、ヘッダーを調べます。Authentication-Resultsにspf=passとdkim=passが表示され、DKIMのd=ドメインとSPFのエンベロープドメインがどちらもexacttarget.comではなく自社のサブドメインであれば（アライメント一致）成功です。Marketing Cloud Setupでは、プライベートドメインまたはSAPがPendingではなくActiveで認証済みになっていることを確認します。そのうえで、送信用サブドメインと_dmarcレコードをQualisendの送信ドメイン認証チェックとドメイン診断でチェックし、送信量を増やす前に、入力ミス、プロキシ有効のレコード、DMARCポリシーの欠落を見つけてください。
よくある注意点
- DNS設定
セルフサービスではありません。レコードを公開するだけでは送信を始められません。SAPやPrivate DomainはSalesforceのチームがプロビジョニングする有料アドオンで（フォーム提出後、DNSにおよそ5営業日、さらに契約の準備期間が必要です）、月間約250,000通を超える送信者向けと位置付けられています。SAPがなければ、認証できない共有のexacttarget.comドメインから送信することになります。
- DNS設定
製品ごとにレコードが異なります。include:cust-spf.exacttarget.comとセレクター200608は、Marketing Cloud Engagement（ExactTarget）専用です。Salesforce本体のSales/Service Cloudはinclude:_spf.salesforce.comとSetup > DKIM Keysで生成する鍵を使い、Account Engagement（Pardot）は独自のトラッカーCNAMEを使います。これらを1つのSPFレコードにまとめないでください。
- 認証失敗の原因
置く場所はルートドメインではなくサブドメインです。SAPは専用のサブドメイン（例：cloud.yourdomain.com）から送信し、include、DKIM、MXはいずれもそこに置きます。SFMCのFromアドレスが本当にルートドメインにある場合を除き、ルートドメインのSPFレコードにcust-spf.exacttarget.comを追加しないでください。ほとんどのアカウントでは、何の役にも立たないルックアップが増えるだけです。
- DNS設定
200608は共有鍵で、アライメントも一致しません。セレクター200608はMarketing Cloudの単一の共有DKIM鍵（2006年作成）で、exacttarget.comで公開されています。exacttarget.comとして署名するため、DMARCで有効な、ドメインとアライメントが一致するDKIM署名にはならず、固定のTXTセレクターなのでローテーションも困難です。ドメインとのアライメントは、SalesforceがCNAMEで委任する専用のSAP鍵によって得られます。パッケージにこの鍵が含まれていることを確認してください。
- DNS設定
委任と手動レコードは競合します。サブドメインをNSレコードでSalesforceに委任した場合、そのサブドメインのSPFやDKIMを親ゾーンにも公開しないでください。委任された子ゾーンが権威を持ち、親ゾーンのレコードは何の通知もなく無視されます。
- DNS設定
レコードは正確に公開してください。SalesforceのCNAMEレコードをTXTに変換しない、ホスト名を短縮しない、レコードをプロキシしない（Cloudflareのオレンジのクラウドは不可）。いずれも、DKIM、返信のルーティング、Return-Pathの解決が機能しなくなる原因になります。
- DNS設定
SPFのルックアップ数と修飾子。cust-spf.exacttarget.comはip4のみのフラットなレコード1つで、ルックアップは1回です（ネストなし）が、サイズは大きめです。Salesforceのドキュメントに記載されている値の末尾は~allです。-allへの厳格化は、そのサブドメインで他に送信しているものがないと確信できてからにしてください。
- DNS設定
DMARCは自分で対応します。SAPは_dmarcを作成しません。DMARCポリシーを公開していないと、GmailとYahooの大量送信者向けのポリシー適用により、Marketing Cloudの送信がスロットリングされたり、迷惑メールに振り分けられたりします。
SPFレコードを作成
Salesforce Marketing Cloudでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証Salesforce Marketing CloudのSPFに関するよくある質問
関連記事
マーケティング・ESPの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。