ADVERTISEMENT

【Salesforce】通知メールが迷惑メールに入る時の確認ポイント

【Salesforce】通知メールが迷惑メールに入る時の確認ポイント
🛡️ 超解決

Salesforceから送信される通知メールが、受信者の迷惑メールフォルダに振り分けられてしまう問題は、多くの企業で発生しています。営業活動のリード通知やケースの更新通知など、重要な連絡が届かないと業務に支障が出るため、早期に原因を特定して対策を講じる必要があります。この記事では、Salesforceの通知メールが迷惑メールに入る原因を、送信元ドメインの認証設定から受信側の設定まで多角的に解説し、具体的な確認ポイントを整理します。会社のIT管理者やユーザー自身が何を確認し、どのような対応をすべきかを明確にします。

【要点】この記事で確認すること

  • 最初に見る場所: Salesforceのメール設定画面で使用中の送信元ドメインを特定し、そのドメインのDNSレコード(SPF、DKIM、DMARC)を確認する。
  • 切り分けの軸: 問題が送信元(Salesforce側)にあるのか、受信側(OutlookやGmailなどのメールクライアント)にあるのかを、メールヘッダーの認証結果(Authentication-Results)で判断する。
  • 注意点: Salesforceからのメールはデフォルトでsalesforce.comドメインから送信されますが、自社ドメインを使用する設定(カスタム差出人アドレス)の場合は、自社ドメインのDNS設定に問題がある可能性が高い。会社のメールシステムに影響を及ぼす変更(SPFレコードの編集など)は、必ずIT管理者と相談してから行ってください。

ADVERTISEMENT

通知メールが迷惑メールに入る主な原因

Salesforceの通知メールが迷惑メールフォルダに振り分けられる原因は、大きく分けて送信元ドメインの認証設定の不備、メールの内容や送信パターン、受信側のフィルタリングポリシーの3つです。最も多いのは、送信元ドメインに対してSPF(Sender Policy Framework)やDKIM(DomainKeys Identified Mail)、DMARC(Domain-based Message Authentication, Reporting & Conformance)が正しく設定されていないケースです。これらの認証技術は、メールが正規の送信元から送られたことを証明するもので、設定が欠けていると受信側でなりすましメールと判断されやすくなります。また、Salesforceから送信される大量の一斉通知メールは、送信パターンがスパムと類似するため、受信側のアルゴリズムに引っかかることもあります。さらに、受信側のメールクライアント(OutlookやGmailなど)が独自のポリシーで迷惑メールと判定する場合もあります。これらの原因を切り分けるには、メールヘッダーの詳細を確認するのが有効です。

原因 症状 対策
SPFレコード未設定または範囲不足 メールヘッダーでfailと表示される DNSにSalesforceのSPFレコードを追加する
DKIM署名未設定 メールヘッダーでfailまたは署名なし SalesforceでDKIM鍵ペアを生成しDNSに公開鍵を登録する
DMARCポリシーが厳しすぎる SPF/DKIMが部分的に失敗するとDMARC違反で迷惑メール扱い DMARCポリシーをp=noneから徐々に厳しくする
送信元ドメインが一般ドメイン(gmail.com等) 送信ドメインの評判が悪く、多くの受信サーバーでブロックされやすい 自社ドメインを使用する設定に変更する
メール内容がスパム判定されやすい 特定のキーワードやURLが多く含まれる メールテンプレートを簡潔にし、リンクを減らす

送信元ドメインの認証設定(SPF、DKIM、DMARC)の確認

迷惑メール判定の最たる原因は、送信元ドメインの認証が正しく行われていないことです。ここでは、各認証技術の役割と確認手順を説明します。

SPFレコードの確認手順

SPFは、そのドメインからメールを送信することを許可されたIPアドレスやサーバーをDNSに宣言する仕組みです。Salesforceからのメールを許可するには、自社ドメインのDNSにSalesforceのSPFレコードを含める必要があります。具体的には、include:_spf.salesforce.comという記述を追加します。確認手順は以下の通りです。

  1. コマンドプロンプトやターミナルでnslookup -type=TXT あなたのドメイン名を実行し、SPFレコードが存在するか確認します。
  2. SPFレコード内にinclude:_spf.salesforce.comが含まれているか確認します。含まれていない場合は、DNS管理画面で追加が必要です。
  3. SPFレコードが長すぎないか(10回のルックアップ制限)も確認します。Salesforce以外にも複数のサービスを含めると制限を超える可能性があるため注意が必要です。
  4. 変更後、反映までに最大48時間かかる場合があるため、テストメールを送ってヘッダーを確認します。

DKIM署名の有効化手順

DKIMは、送信者がメールにデジタル署名を付与し、受信側がDNSに公開された公開鍵で検証する仕組みです。SalesforceでDKIMを有効にするには、まずSalesforce側で鍵ペアを生成し、公開鍵をDNSにTXTレコードとして登録します。手順は以下の通りです。

  1. Salesforceにログインし、[設定] > [メール] > [DKIM鍵] に移動します。
  2. [新規] をクリックし、使用するドメインを選択して鍵の長さ(通常1024ビット)を指定し、鍵ペアを生成します。
  3. 生成された公開鍵のTXTレコード情報(セレクタと値)をメモします。
  4. 自社ドメインのDNS管理画面で、セレクタ名をサブドメインとしたTXTレコードを追加します。例: salesforce._domainkey.あなたのドメイン
  5. DNSに反映されたら、SalesforceのDKIM鍵画面で[アクティブ化]をクリックします。
  6. テストメールを送信し、メールヘッダーにDKIM-Signatureが含まれ、dkim=passとなることを確認します。

DMARCポリシーの確認

DMARCは、SPFとDKIMの検証結果に基づいて受信側のポリシーを指示する仕組みです。DMARCレコードが厳しいポリシー(p=rejectなど)に設定されていると、SPFやDKIMがわずかに失敗しただけでメールが拒否または迷惑メール扱いになります。最初はp=noneで運用し、なりすましメールがないことを確認してからp=quarantinep=rejectと段階的に厳しくするのが一般的です。DMARCレコードは_dmarc.あなたのドメインというTXTレコードで確認できます。すでにDMARCレコードが存在する場合は、ポリシーを確認し、必要に応じて緩和します。Salesforceのメール送信に支障がないよう、SPFとDKIMが完全に合格している状態でDMARCポリシーを設定することが重要です。

Salesforce側のメール設定を確認する手順

認証設定の前に、Salesforce自体のメール設定が適切かどうかを確認します。以下は基本の確認手順です。

  1. [設定] > [メール] > [メール配信の設定] を開き、[送信元のメールアドレス] で使用されているドメインを確認します。デフォルトはsalesforce.comですが、組織によってはカスタムドメインが設定されている場合があります。
  2. [設定] > [メール] > [メールの送信] で、[送信者の表示名] や [返信先アドレス] が正しいか確認します。
  3. [設定] > [メール] > [メールのセキュリティ] では、[許可されたメールドメイン] や [メール送信の制限] が設定されています。不要な制限がかかっていないか確認します。
  4. [設定] > [メール] > [メールの送信履歴] で、実際に送信されたメールのステータス(配信成功、バウンスなど)を確認します。バウンスが多い場合は、受信側サーバーに拒否されている可能性があります。
  5. カスタム差出人アドレスを使用している場合は、[設定] > [メール] > [カスタム差出人アドレス] で設定を確認し、DNSに必要なMXレコードやSPFレコードが追加されているか確認します。

受信側(Outlook/Gmail等)でできる対処

送信元の設定が適切でも、受信側のメールクライアントで迷惑メールと判定されることがあります。ここでは、受信者が自分でできる対策を紹介します。

Outlook(Exchange Online/オンプレミス)の場合

Outlookでは、[迷惑メールオプション] で送信元アドレスを [差出人セーフリスト] に追加することで、以降のメールが迷惑メールフォルダに移動しなくなります。また、Exchange Onlineを利用している組織では、管理者がスパムフィルタのポリシーを調整することで、特定のドメインからのメールを許可リストに追加できます。ただし、個人で設定できるのは自分のOutlookのみであり、組織全体のポリシーは管理者に依頼する必要があります。

Gmailの場合

Gmailでは、受信した迷惑メールを開き、[迷惑メールではない] ボタンをクリックすることで、学習機能が改善されます。また、フィルタを作成して特定の送信元のメールを [受信トレイ] に移動することも可能です。ただし、GSuite(Google Workspace)を使用している組織では、管理者がスパムフィルタのホワイトリストにドメインを追加できます。

その他のメールクライアント(Thunderbird等)

多くのメールクライアントでは、送信元アドレスをアドレス帳に登録したり、ルールで受信トレイに移動する設定が可能です。まずはこれらの個人設定で回避できるか試し、効果がない場合は送信元の認証設定を見直す必要があります。

管理者が確認すべき設定項目と注意点

IT管理者またはSalesforce管理者は、以下の項目を重点的に確認し、適切な設定を行ってください。

  • 送信元ドメインのDNSレコード: SPF、DKIM、DMARCの各レコードが正しく設定されているか、外部ツール(例: MXToolbox)で検証します。SPFには include:_spf.salesforce.com が必須です。DKIMの公開鍵レコードは、Salesforceで生成したセレクタ名と一致しているかを確認します。
  • カスタム差出人アドレス: 自社ドメインを使用する場合は、そのドメインのDNSにSPFとDKIMが設定されていなければなりません。また、返信先アドレスが異なる場合は、そのドメインの設定も必要です。
  • メール送信ボリューム: 短期間に大量のメールを送信すると、受信側サーバーにレート制限されたり、ブラックリストに掲載されるリスクがあります。必要に応じて送信間隔を調整するか、Salesforceの一括メール機能(Mass Email)で制限を確認します。
  • DMARCレポートの活用: DMARCを有効にしている場合は、ruaタグで指定したアドレスに集計レポートが届きます。このレポートには、SPF/DKIMの認証結果やなりすましの試行が記録されているため、問題の診断に役立ちます。

注意: DNSの変更は即座に反映されず、伝搬に時間がかかります。変更後は数時間から48時間程度待ってから効果を確認してください。また、SPFレコードの編集を誤ると自社のメール配信全体に障害が発生する恐れがあるため、必ずバックアップを取り、影響範囲を評価してから実施してください。

よくある質問

ここでは、Salesforce通知メールの迷惑メール問題に関するよくある質問とその回答をまとめました。

  • Q. 迷惑メールフォルダから自動で受信トレイに移動させる方法はありますか?
    A. 受信側のメールクライアントでルール(フィルタ)を作成することで自動移動が可能です。ただし、根本的な原因(認証設定の不備)が解消されない限り、他の受信者には迷惑メールとして届き続けるため、送信元の設定を正すことを推奨します。
  • Q. Salesforceのサポートに問い合わせれば解決しますか?
    A. Salesforceサポートは、自社のメールサーバー設定やDNS設定については支援範囲外となる場合があります。ただし、Salesforce側のメール送信機能やDKIM設定についてはサポートを受けられます。まずは自社のIT管理者と連携し、DNSの確認を行ってください。
  • Q. 送信元ドメインをsalesforce.comのまま運用しても問題ありませんか?
    A. salesforce.comドメインは多くのメールサーバーで信頼されているため、認証設定が適切であれば問題になることは稀です。ただし、自社ドメインからの送信に比べてなりすまし防止の観点からは劣るため、重要度の高い通知には自社ドメインの使用を検討してください。
  • Q. 迷惑メール判定を回避するために、メールの内容を工夫する必要はありますか?
    A. 画像の多用や過剰なリンク、スパム的なキーワード(「無料」「今すぐ」など)は迷惑メール判定を引き上げる要因となります。通知メールのテンプレートはシンプルに保ち、必要最小限のテキストとURLに留めることをお勧めします。

まとめ

Salesforceの通知メールが迷惑メールに入る問題は、送信元ドメインのSPF、DKIM、DMARCの認証設定が正しく行われていないことが主な原因です。まずはメールヘッダーを確認して認証結果を把握し、不足している設定をDNSに追加します。受信側で一時的に対処することも可能ですが、恒久的な解決には送信元の認証強化が不可欠です。管理者はDNS変更の影響を考慮し、段階的に設定を進めてください。自社ドメインを使用する場合は特に注意が必要ですが、適切に設定すれば配信信頼性が向上します。問題が解決しない場合は、Salesforceサポートや外部のメール認証専門家に相談することを検討しましょう。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。

ADVERTISEMENT