Salesforceから送信されるメールとDMARCの仕組み

Salesforce経由で自社ドメインからメールを送信することはできますが、それだけでは、そのメールが本当に自社から送られたものだという証明にはなりません。その証明の役割を担うのがDMARCです。DMARCはメールセキュリティの標準規格で、GmailやOutlookなどのメールプロバイダーは、メッセージがドメイン所有者の許可を得て送信されたものかどうかをこの仕組みで確認します。各Salesforce製品で短い認証設定を完了するまでは、Salesforceを使って送信するメールはこのチェックに失敗し、迷惑メールフォルダーに入るか、受信を拒否されるおそれがあります。

解決方法は公式に詳しく文書化されていますが、複数のSalesforce製品にまたがっており、それぞれ設定手順が異なります。このガイドでは、初期設定のSalesforce構成のどこに認証の抜けがあるのか、そしてSales Cloud、Account Engagement(旧Pardot)、Marketing Cloud Engagementのそれぞれでどのように解消するのかを説明します。

このガイドの内容

• SalesforceのメールはなぜそのままではDMARCに合格しないのか
• Salesforceはどのようにあなたに代わってメールを送信するのか
• 初期設定のSalesforceでDMARCアライメントが崩れる原因は何か
• Salesforce向けにDKIMとSPFを設定する方法
• SalesforceのメールがDMARCに合格しているか確認する方法
• 実務上のまとめ

SalesforceのメールはなぜそのままではDMARCに合格しないのか

Salesforce経由で送信する場合、メールは自社のシステムから出ていくわけではありません。Salesforceのサーバーがメッセージを作成し、Fromアドレスに自社ドメインのアドレスを載せた状態で受信者に配信します。これらのサーバーはSalesforce自身のドメイン上で動作し、Salesforce自身の設定を使用しており、送信者側が管理できる範囲の外にあります。

GmailやOutlookなどのメールプロバイダーは、Fromアドレスだけを信用することはありません。Fromアドレスには誰でも好きなアドレスを入力できるためです。代わりに技術的な証拠を確認します。どのサーバーがメッセージを配信したのか、そしてどのドメインがそのメッセージを保証したのか、という点です。

DMARCは、受信者に表示されるFromアドレスのドメインと、メッセージを認証したドメインが一致しているかどうかを判定します。両者が一致していれば、受信サーバーはそのメールが正当な送信者から送られたものだと判断できます。この一致はアライメント(整合性)と呼ばれ、初期設定のSalesforce構成ではDMARCアライメントは成立しません。メッセージはSalesforceとして認証される一方で、表示されるのは自社ドメインの名前だからです。

その後に何が起こるかは、自社のDMARCポリシーによって決まります。p=noneではメールは届き、失敗はレポートに記録されるだけです。p=quarantineやp=rejectでは、受信サーバーはアライメントの取れていないメールを迷惑メールフォルダーに送るか受信を拒否し、キャンペーンは受信トレイに届かなくなります。

Salesforceはどのようにあなたに代わってメールを送信するのか

すべてのメールには2つの送信者アドレスが含まれています。Fromアドレスは受信者に表示されるアドレスです。リターンパスは、配信失敗の通知、いわゆるバウンスが送られる非表示のアドレスです。DMARCのSPFチェックが見るのはリターンパスです。SPFアライメントが成立するには、リターンパスのドメインがFromドメインと一致している必要があります。

Salesforceが代わりに送信する場合、メッセージはSalesforceのメールサーバーから出ていき、初期設定ではリターンパスに自社ドメインではなくSalesforceが運用するドメインが使われます。これはプラットフォームとして通常の動作であり、送信者側で何も設定しなくてもバウンス処理が機能する仕組みです。同時に、初期設定のままでは自社のドメインが認証されないままになることも意味します。

各Salesforce製品は、それぞれ独自のインフラから送信し、認証設定も個別に持ちます。Sales CloudはチームがCRMから送信するメールを扱います。Account Engagementはマーケティングオートメーションとナーチャリングキャンペーンを担当します。Marketing Cloud Engagementは大量配信のキャンペーン送信を処理します。1つの製品を設定しても、他の製品には反映されません。

初期設定のSalesforceでDMARCアライメントが崩れる原因は何か

ここで重要になるのは2つのアドレスです。受信者に表示されるFromアドレスと、配信失敗の通知が送られる非表示のリターンパスです。DMARCがSPFの合格として認めるのは、リターンパスが自社ドメインを使っている場合だけです。初期設定のSalesforceでは、この条件が満たされることはありません。

Account Engagementを例に取ります。そのメッセージのリターンパスはSalesforceが所有するドメイン上にあり、Salesforce公式のDMARCサポートドキュメントにあるとおり、bounce.s7.exacttarget.comのようなアドレスが使われます。受信サーバーがSPFチェックを実行すると、確認されるのは自社ドメインではなくこのSalesforceのドメインです。チェック自体は合格するかもしれませんが、証明しているのは別のことです。保証されるのはSalesforceのドメインであり、自社ドメインは証明されないままです。DMARCはこれを失敗として扱います。

Sales Cloudでも同じ不一致が起こり得ます。Bounce ManagementまたはEmail Security Complianceを有効にすると、SalesforceのSPFとDKIMに関するFAQに記載されているとおり、SalesforceはリターンパスをSalesforceドメイン上のバウンス追跡アドレスに置き換えます。ドメインが一致しなくなり、同じ理由でDMARCのSPFチェックは失敗します。

SPFレコードにSalesforceのinclude、include:_spf.salesforce.comをすでに追加している場合もあるでしょう。これはそのまま残してください。Salesforceのサーバーが自社ドメインとして送信することを受信側に伝える役割があります。ただし、この記述はリターンパスを変更しないため、それだけではこの不一致を解消できません。

SalesforceではDKIMが確実な方法と言えるのはこのためです。DKIM署名はメッセージ自体の中に含まれて運ばれ、どのサーバーがメールを配信しても、自社ドメインに直接ひも付いています。DKIMキーを設定すれば、Salesforceはすべてのメッセージに自社ドメインとして署名し、DMARCは必要な証明を得られます。

Salesforce向けにDKIMとSPFを設定する方法

各Salesforce製品には1回限りの設定が必要で、いずれも最後に自社ドメインへ新しいDNSレコードをいくつか追加する作業で完了します。会社のDNS設定にアクセスできない場合は、このセクションを担当者に共有してください。必要な情報はすべてここに含まれています。アクセスできる場合は、以下の手順をそのまま進めてください。

設定を他の担当者に任せる場合は、SalesforceのメールがDMARCに合格しているかの確認に進むこともできます。

Sales Cloud(Salesforce経由で送信されるメール)

Salesforce Setupで、Email、DKIM Keysの順に進み、DKIMキーを作成します。2048ビットのキーを選択し、ドメインには送信に使う自社ドメインを設定してください。SalesforceはCNAMEレコードを返します。これは自社ドメインに公開する小さなDNSエントリーです。レコードが反映されたら、キーを有効化します。それ以降、Salesforceは30日ごとにキーを自動でローテーションし、メンテナンスの手間はかかりません。

Account Engagement(Pardot)

設定の流れは同じ形です。Account Engagementが送信ドメイン用のDKIMレコードを生成し、それをDNSに公開すると、以降Account Engagementは自社ドメインとしてメールに署名します。Salesforceのガイダンスはこの点について明快で、DKIMが正しく構成されていればDMARCは合格するはずだとしています。

Salesforceのドキュメントにある2つの注意点も押さえておきましょう。メール送信ドメインとトラッカードメインは分けてください。両方に同じドメインを使うと認証エラーの原因になります。また、SPFアライメントも必要な場合は、カスタムリターンパスが必要になり、Account Engagementのサポートケースを通じて申請します。

Marketing Cloud Engagement

Marketing Cloudだけは、設定変更ではなく購入が必要なケースです。Sender Authentication Packageに含まれるPrivate Domain製品が、SalesforceのPrivate Domain FAQにあるとおり、専用の送信ドメインにDKIM、SPF、DMARCの認証を適用します。多くのチームはmail.example.comのようなサブドメインを委任し、そのレコードの管理をSalesforceに任せています。組織が自前でDNSをホストする場合は、DNSチームがそれらのレコードを維持することになり、自己ホストのDNSはSalesforceサポートのトラブルシューティング対象外です。

どの製品を使う場合でも、もう1つのDNS変更で全体が完成します。自社ドメインのSPFレコードにinclude:_spf.salesforce.comを追加してください。アライメントはあくまでDKIMで確保しますが、完全なSPFレコードがあれば、Salesforceメールが通るすべての経路で基本的な認証を維持できます。

SalesforceのメールがDMARCに合格しているか確認する方法

手早いテストはメール1通で済みます。各Salesforce製品から自分が管理するメールボックスにメールを送信し、メッセージヘッダーを開いて、dkim=passと、d=の値に自社ドメインが表示されていることを確認します。署名がSalesforce所有のドメインで合格している場合は、自社ドメインのDKIM設定がまだ完了していないということです。

DNS側の状態は、以下のチェッカーで数秒で確認できます。自社ドメインが有効なDKIMレコードを公開しているかどうかが表示されます。

最終的な確認手段は、自社のDMARCデータです。DMARC集約レポートには、SalesforceのIPレンジを含め、自社ドメインとして送信しているすべての送信元が一覧され、各メッセージがアライメント付きで合格したかどうかが示されます。Salesforceのトラフィックがレポート上で失敗として表示される場合、SPFとDKIMのどちらに対処が必要かもレポートから分かります。DMARCeyeの無料プランは1ドメインをカバーし、生のレポートを、送信元と次の対応が読み取れるリストに変換します。DNSの変更が反映されるにつれて、Salesforceの送信元が失敗からアライメント済みへ変わっていく様子を確認できます。

実務上のまとめ

プラットフォームの初期設定が認証するのはプラットフォーム自身であり、自社ドメインではありません。解決方法はSalesforce自身のドキュメントに明記されています。自社ドメインとして送信するすべてのSalesforce製品でDKIMを設定し、SPFレコードにinclude:_spf.salesforce.comを残しておくことです。成否は、SPFやDKIM単体の合格ではなく、アライメントで判断してください。

必要な作業はDNSレコードを数件追加するだけで、Salesforceのメールが自社ドメインとして合格していることは、数日以内にDMARCレポートで確認できます。DMARCeyeはそれらのレポートを常時監視し、まだ対応が必要な送信元をお知らせします。