Salesforceではセキュリティ向上のため、Spring ’26（2026年3月）のアップデートにてメールドメイン検証が厳格化されます。これまで検証なしで送信できていた環境でも、要件を満たさないドメインからのメール送信が制限されるようになります。
本番環境での対応はもちろんですが、実はこのアップデートに伴い、テスト環境である「Sandbox」の運用において大きな課題が発生することが分かっています。
Sandboxをリフレッシュすると、設定したDKIM鍵が更新され、サーバー側でDNSレコードを再設定する必要があるのです。
要注意！SandboxリフレッシュでDKIM設定は消滅する
Salesforceサポートに確認したところ、非常に厄介な仕様が判明しました。Sandboxをリフレッシュすると、本番環境の設定が丸ごと上書きされるため「Sandbox専用に設定していたDKIM鍵」が消滅してしまうのです。
DKIMを設定するには、Salesforceで生成した固有の鍵（CNAMEレコード）をDNSサーバーに登録する必要があります。つまり、Sandboxをリフレッシュするたびにシステム部門やDNS管理者にDNSレコードの更新を依頼し、反映を待たなければなりません。スピード感が求められる開発やテストにおいて、これは現実的な運用とは言えません。
毎回DNSを更新するのは非現実的？Sandboxでの対処法3選
DNSの都度更新を避けるため、Sandbox環境では以下の3つのいずれかの方法でメールテストを実施することをおすすめします。
対処法1：テスト用にGmailなどの「検証免除ドメイン」を使用する
まずは、最も手軽な方法として、ドメインの疎通確認以外のメールテストにおいて、Gmailなどのフリーメールアドレスを送信元として使用することです。
これらのドメインはすでに外部で検証・管理されているため、Salesforce側でのドメイン検証作業自体が不要になります。純粋なメールテンプレートのレイアウト確認や、送信フロー（Apexやフロー）の動作テストだけであれば、この方法で十分対応可能です。
対処法2：未検証ドメイン用の「代替ドメインオプション」を有効化する
次に、公式ナレッジ（Article 005316090等）でも言及されている「未検証ドメインからメールを送信するための代替ドメインオプション」を利用する方法です。
「設定」の「送信」の「Use a substitute email address for unverified domains」というオプションが該当の設定です。
これを有効化すると、未検証のドメインから送信された場合でも、Salesforceが自動的に検証済みのSalesforceドメイン（*.salesforce.comなど）を送信元のエンベロープアドレスに付与してメールを配信してくれます。テストメールの送信元アドレスの見た目は少し変わってしまいますが、DNSをいじることなく確実にメールを届けることができます。
また、DKIMがPASSしなかった送信メールに対してSalesforceが代理で送信するという動きになるため、DKIM設定と併用して行うことも可能です。
内部のメールなどでしか利用していない場合は、送信先のメールアドレスの見た目が変わるのみなので、有効かと思います。
対処法3：「承認済みメールドメイン」機能で素早く検証を済ませる（運用コストは高い）
自社ドメインの送信元アドレスをそのまま使ってテストしたい場合の最適な回避策です。
DKIMの設定・維持は複雑ですが、Salesforceの「承認済みメールドメイン（Authorized Email Domains）」機能を使えば、比較的簡単にドメインを検証できます。管理の簡単なTXTレコードをDNSに1つ置いておくか、特定のメールアドレスで確認メールを受信してリンクをクリックするだけで済みます。DKIMレコードをリフレッシュのたびに発行・書き換えるよりも圧倒的に運用コストが下がります。
ただし、これもサンドボックスのリフレッシュのたびに再設定が必要です。検証キーに組織IDが含まれるため、サンドボックスがリフレッシュされるたびにDNSのTXTレコードを更新しなければなりません。
もし「1秒もかけずに、DNS更新も一切せずにテストを再開したい」という場合は、やはり対処法1（Gmail等の検証免除ドメインの活用）や対処法2（代替ドメインオプション）が最も現実的な選択肢となります。
【承認済みメールドメインを設定した際のイメージ】
上記のようにSalesforceにて設定した場合は、サンドボックスのリフレッシュのたびにDNS側で上記画像の「確認コード」の値を更新します。
つまり、サンドボックスが更新されると、サンドボックス環境のIDが変わり、承認済みメールドメインの確認コードの値も切り替わるため、その検証を行う必要があるのです。
まとめ：自社の運用に合わせたSandboxテスト方針を決めよう
Spring ’26のメールドメイン検証厳格化に向けて、Sandboxでのテスト運用方針も早めに見直す必要があります。
「簡易テストはGmailで」「本格的なテストは代替ドメインオプションまたは承認済みメールドメインで」など、自社のセキュリティ要件やテストの目的に合わせて、現場に負担の少ない最適な対処法を選択してください。
- おすすめ度☆2：対処法1 テスト用にGmailなどの「検証免除ドメイン」を使用する
- サンドボックス環境にて本番と違うGmailメールアドレスを設定する手間がある
- もしくは検証用のGmailを設定したユーザーを作成する必要がある
- おすすめ度☆3：対処法2 未検証ドメイン用の「代替ドメインオプション」を有効化する
- セキュリティ要件として問題ない場合は推奨
- 対処法1と違い検証用のユーザーや検証用のGmailメールアドレスを用意する必要はない
- おすすめ度☆1：対処法3 「承認済みメールドメイン」機能で素早く検証を済ませる
- セキュリティ要件がある場合はこちらの方法を推奨
- ただし対処法1や2と違い設定の手間は大きい
エビデンス・参考ナレッジ
本記事の執筆にあたり参照した公式資料およびニュースは以下の通りです。
- 未検証のメールアドレスからのメールの送信の準備 (Article 000381186)
Spring ’26で必須となるメールドメイン検証の概要と、未検証ドメインを利用した際の代替ドメインの挙動について記載された公式ドキュメントです。 - メール送信の要件に関する FAQ
ドメイン検証に関するよくある質問がまとめられており、「承認済みメールドメイン」を利用した回避策の考え方についても解説されています。