症状：Salesforceのテストメールが送れない。
最短の確認：実際に使われた送信ドメインと認証状態を調べ、未認証なら有効なDKIMキーまたは検証済みの承認済みメールドメインを設定します。 受信確認用アドレスは到着を調べるためのもので、ドメイン認証の代わりにはなりません。
Salesforce管理者は組織、ユーザー、送信元アドレスの設定を確認します。
開発者はApexやFlowなどの処理とメールログを調べます。
QA担当者は、送信された証拠と受信した証拠を分けて記録します。
最終更新：2026年10月24日。 Salesforceの公式ヘルプとリリース情報で、認証方式、適用範囲、Sandbox、メールログの確認点を照合しました。組織による適用状況や設定の展開には差があるため、公開資料に加えて対象組織の現在の設定を確認してください。
管理者は「ユーザー確認」と「ドメイン認証」を分けて調べる
ユーザーのメールアドレスが確認済みでも、Fromに使う送信ドメインの認証が済んだとは限りません。Salesforceの送信ドメイン認証要件を確認し、対象組織と送信方式にどの要件が適用されるかを見ます。すべてのメール機能に同じ条件が一律に当てはまると考えず、例外や一時的な適用状況は公式資料と組織内の表示を照合してください。
まず、問題を次の状態に分けます。
- 処理が動いていない： Apex、Flow、通知などが実行されず、送信要求そのものが発生していません。
- 送信が拒否・破棄された： Salesforce側で送信できず、未認証ドメインに関するエラーなどが記録される場合があります。
- 送信後に受信できていない： 送信処理は進んでも、テスト用受信箱に見当たらない状態です。迷惑メール判定や宛先、受信側の条件など、別の確認が必要です。
この区別をしないまま「テスト用アドレスが悪い」と判断すると、設定不備の調査が遅れます。Salesforceが示すドメイン確認の考え方は、ユーザーのメール確認とドメイン認証の違いでも確認できます。
送信元の棚卸しは「代表アドレス」だけで終わらせない
管理者は、対象組織で実際に利用されるFromアドレスを集めます。ユーザーのメールドメイン、組織全体の送信元アドレス、Email-to-Case、Experience Cloudなどを確認し、どの処理がどのドメインを使うか記録します。
Salesforceの送信に使われるメールドメインの特定手順に沿って、設定画面で使用状況を確認します。親ドメインが認証済みでも、別のサブドメインを送信元に使っているなら、そのドメインの状態も個別に照合してください。例示用のドメインや過去の猶予措置を、自組織の現在の設定と取り違えないことが重要です。
DNS担当者は「DKIM」と「承認済みメールドメイン」を選ぶ
Salesforceの公式資料で示される認証方法は、有効なDKIMキーを使う方法、または検証済みの承認済みメールドメインを使う方法です。詳細はドメイン認証の注意点を読み、対象組織で利用できる方式を判断します。SPFやDMARCの設定はメール送信の認証・ポリシーに関係しますが、このドメイン認証要件の代替として扱わないでください。
- DNSを管理でき、既存のDKIM運用がある場合は、Salesforce側で有効なDKIMキーが登録・有効化されているかを確認します。
- DKIMを使わない場合は、承認済みメールドメインの設定条件と検証状態を担当者間で確認します。Salesforceの承認済みメールドメインの設定手順に記載された手順と、組織に表示される値を照合してください。
- DNSレコードの追加や変更を依頼するときは、対象ドメイン、必要なレコード値、反映確認の担当者を明記します。値や画面の場所を過去のメモから転記せず、現在の公式手順を基準にします。
Sandbox担当者は本番の認証状態を流用しない
Sandboxでテストメールが送れない場合も、Sandbox自身の送信元と認証状態を確認します。本番組織で設定済みだからSandboxも送れる、と決めつけるのは危険です。Salesforceの資料ではSandboxにもドメイン認証の確認が必要とされているため、対象のSandboxで実際に使うFromアドレスから点検を始めます。
Sandboxが別の送信元アドレスやサブドメインを使うなら、それを棚卸しに含めます。代替の送信元アドレスを使う設定が利用可能かどうかは、組織の現在の状態と公式文書で確認してください。テストを通すために本番の保護設定を緩めるのではなく、Sandbox側の設定を整えるのが安全です。
開発者とQAは「処理」「ログ」「受信」を別々に記録する
開発者は、メール送信に関係するApex、Flow、通知、リマインダーなどが実際に動いたか確認します。次に、実行時に指定されたFromアドレスのドメインを棚卸し結果と照合し、Salesforceのメールログに失敗が記録されているかを調べます。
Salesforceのメールエラーに関するリリース情報で未認証ドメインに関連するエラー表現を確認し、ログに同じ原因を示す記録がないか探します。ログの一つのエラーだけで、すべての送信失敗を説明できるとは限りません。メールログの形式と項目を参照し、送信元、宛先、結果を処理の実行記録と突き合わせます。ログの取得条件や制約も、メールログに関する考慮事項で確認してください。
QAは、Salesforceが送信を試みた記録を確認してから、管理されたテスト用受信先で到着と本文の表示を確かめます。次のチェック項目を完了するまでは、「未送信」と「受信できない」を同じ障害として扱わないようにします。
- [ ] 対象の組織とSandboxを特定し、再現する処理を記録した
- [ ] ユーザー、組織全体の送信元、各自動化で使うFromアドレスを確認した
- [ ] 送信に使うドメインとサブドメインごとに認証状態を確認した
- [ ] 未認証の場合はDKIMまたは承認済みメールドメインの設定を修正し、Salesforce側の状態を再確認した
- [ ] Apex、Flowなどの実行結果とメールログを保存した
- [ ] 受信先で到着、本文、リンクなどを確認し、送信側の証拠と分けて記録した
Salesforceのテストメールは受信先だけで原因を決めない
確認の要点は、送信ドメインの認証、処理の実行、Salesforceの送信結果、実際の受信を別々の証拠として残すことです。認証が未完了なら組織側の設定を直し、送信が記録されてから受信先で内容を確認します。これで、Sandboxの設定漏れを受信側の不具合と誤認するリスクを抑えられます。
認証完了後の受信確認には、テスト用受信先を分けて管理する方法もあります。Tempsenderの一時受信箱は、自社の登録・通知フローを確認するための選択肢です。受信できるか、内容を読めるかの確認には使えますが、Salesforceの送信ドメイン認証やメールログの証明にはなりません。主メールアドレスをテストデータに使わずに確認したい場合は、Tempsenderの受信サービスを利用し、メール転送を組み込む運用を検討する場合はメール転送の案内も確認できます。
よくある質問
Sandboxでテストメールが届かないとき、最初に何を確認すればよいですか？
本番組織の設定をそのまま前提にせず、Sandbox側で使われるFromアドレスのドメインと、その組織での認証状態を確認します。次に、ApexやFlowなどの処理が実行されたか、メールログに送信失敗が記録されているかを調べます。送信が試みられた証拠を確認してから、受信側の問題を切り分けます。
ユーザーのメールアドレスを確認済みなのに、Salesforceからメールが送られないのはなぜですか？
ユーザーのメールアドレス確認と、メールのFromに使うドメインの認証は別の確認です。アドレスが確認済みでも、実際の送信ドメインが未認証なら送信が拒否される場合があります。組織で使う送信元を特定し、DKIMまたは承認済みメールドメインの状態を確認したうえで、送信処理とログも調べてください。
送信ドメインはDKIMと承認済みメールドメインのどちらで認証すべきですか？
Salesforceが示す方法は、有効なDKIMキーを使う方法と、承認済みメールドメインを検証する方法です。DNSを管理でき、組織のメール認証を一元管理している場合はDKIMの設定状況を確認し、別の方法が必要なら承認済みメールドメインの要件を担当者と照合します。どちらを選ぶ場合も、対象組織の公式設定手順に従います。
メールログで、送信ドメイン認証が原因の失敗をどう見分けられますか？
ログの失敗情報に、未認証ドメインに関する拒否や恒久的な失敗を示す記録がないか確認します。ただし、単独のエラーだけで全件の原因を決めつけず、Fromアドレスのドメイン、処理の実行結果、組織の認証状態と照合してください。ログに送信の記録がなければ、まず自動化が実行されたかを調べます。
短期用の受信箱が必要ですか？
ランダムなアドレスを作成し、コピーしたら同じページでメールを待ちます。重要なアカウントには長期利用できるアドレスを使ってください。