SPFレコードの例:Google Workspace、Microsoft 365、送信サービスの場合

要点まとめ

1. 1つのレコードで複数の送信元に対応 社内メールをあるプロバイダーで運用し、アプリケーションのメールを送信サービス経由で送る場合は、どちらも同じSPFレコードで許可する必要があります。
2. Google Workspaceのみの場合 Googleは、Workspaceにinclude:_spf.google.comを使用するよう案内しています。
3. Microsoft 365のみの場合 Microsoftは、Exchange Onlineにinclude:spf.protection.outlook.comを使用するよう案内しています。
4. Google Workspaceと送信サービスの併用 Googleのincludeの隣に、送信サービスのincludeを追加します。
5. Microsoft 365と送信サービスの併用 考え方は同じです。
6. 自社サーバーをIPアドレスで追加する Webアプリケーションや古いメールサーバーなど、メールを送信するサーバーを運用している場合は、そのアドレスをip4で記述します。

1つのレコードで複数の送信元に対応

社内メールをあるプロバイダーで運用し、アプリケーションのメールを送信サービス経由で送る場合は、どちらも同じSPFレコードで許可する必要があります。送信元ごとにincludeを追加し、先頭のv=spf1と末尾のallはそれぞれ1つだけにします。

以下の例では、GoogleとMicrosoftが公開しているinclude値を使用しています。プロバイダーが値を変更することがあるため、公開する前に最新のドキュメントで確認してください。

Google Workspaceのみの場合

Googleは、Workspaceにinclude:_spf.google.comを使用するよう案内しています。Google経由でのみ送信するドメインでは、次のレコードを公開します。

v=spf1 include:_spf.google.com ~all

独自ドメインでGmailを使う場合も、これが適切な出発点になります。

Microsoft 365のみの場合

Microsoftは、Exchange Onlineにinclude:spf.protection.outlook.comを使用するよう案内しています。Microsoft 365経由でのみ送信するドメインでは、次のレコードを公開します。

v=spf1 include:spf.protection.outlook.com ~all

移行期間中に両方のプロバイダーを使う場合は、後述のとおり組み合わせ、移行が完了したら古いほうを削除してください。

Google Workspaceと送信サービスの併用

Googleのincludeの隣に、送信サービスのincludeを追加します。レコードは1つにまとめ、末尾の前に両方のincludeを置きます。

v=spf1 include:_spf.google.com include:YOUR_SPF_HOST ~all

YOUR_SPF_HOSTは、MigoSMTPのダッシュボードに表示される値、または利用している別のサービスの値に置き換えてください。

Microsoft 365と送信サービスの併用

考え方は同じです。includeを2つ、レコードは1つです。

v=spf1 include:spf.protection.outlook.com include:YOUR_SPF_HOST ~all

送信サービスはDKIMでも認証してください。SPFのアライメントが取れない場合でも、DKIM署名でDMARCにパスできるようになります。

自社サーバーをIPアドレスで追加する

Webアプリケーションや古いメールサーバーなど、メールを送信するサーバーを運用している場合は、そのアドレスをip4で記述します。CIDR形式で範囲を指定することもできます。

v=spf1 include:_spf.google.com ip4:203.0.113.10 include:YOUR_SPF_HOST ~all

管理しているアドレスだけを記述し、サーバーを廃止したら削除してください。

その他のメールボックスプロバイダー

Zohoなど、ほかのプロバイダーも独自のinclude値を公開しており、データセンターごとに値が異なる場合もあります。ブログ記事ではなく、必ずお使いのリージョンに対応するプロバイダー自身のヘルプページから値をコピーしてください。

基本の形は変わりません。レコードは1つ、送信元ごとにincludeを1つ、末尾は1つです。

ルックアップ数を確認する

includeはそれぞれ1回のルックアップとして数えられ、プロバイダーのincludeの中にさらにincludeが含まれていることもあります。GoogleとMicrosoftのレコードは、それぞれ内部で複数のルックアップを使用するため、いくつかのサービスと組み合わせると、思ったより早く上限の10回に達することがあります。

当社の無料チェッカーや、ほとんどのSPFテストツールがルックアップ数を数えてくれます。上限に近い場合は、使っていない送信元を削除するか、メールの種類ごとに別のサブドメインから送信し、それぞれに専用のレコードを持たせることを検討してください。

サブドメインから送信する

多くのチームは、mail.yourdomain.comのようなサブドメインからマーケティングメールやトランザクションメールを送信しています。サブドメインにはルートとは別の独自のSPFレコードを設定でき、各レコードを短く保ち、ルートをすっきりさせられます。

DMARCはサブドメインにも適用されるので、サブドメインのメールについてもアライメントを確認してください。

コマンドラインでレコードを調べる

DNSクエリで、どのドメインのSPFレコードも読み取れます。LinuxとmacOSではdig、Windowsではnslookupを使用します。どちらもルートのTXTレコードを表示し、SPFのレコードはv=spf1で始まります。

dig +short TXT yourdomain.com

v=spf1で始まるレコードが2つある場合は、1つに統合してください。1つもない場合は、公開してください。DNSの管理画面には、まだ反映されていない値が表示されていることがあるため、変更のたびにクエリを再実行してください。

ルックアップ数の計算例

たとえば、レコードにinclude:_spf.google.com、include:YOUR_SPF_HOST、ip4:203.0.113.10が含まれているとします。ip4はルックアップを消費しません。includeは1つにつき1回で、さらにそのプロバイダー自身のレコード内にあるルックアップも加算されます。したがって、レコード内にさらに3つのincludeを持つプロバイダーは、合計で4回かかります。

各includeの合計を足してください。10回以下であれば問題ありません。10回を超える場合、SPFはすべての受信者に対して失敗するため、公開する前に送信元を減らすか、一部のメールをサブドメインに移してください。

空白期間なしでプロバイダーを切り替える

ある送信サービスから別のサービスに移行するときは、新しいincludeを追加している間も古いincludeをレコードに残しておき、新しいサービスから少量を送信して様子を見ます。古いincludeを削除するのは、古いサービスから何も送信されなくなってからにしてください。

早く削除しすぎると、古いサービス経由で送信されるメッセージがSPFに失敗します。DNS、キー、テンプレートについても、当社の移行ガイドで同じ重複運用の手順を解説しています。

SPFだけでは不十分な場合

SPFはエンベロープ送信者のみをチェックし、転送されると機能しなくなります。そのため、受信側はDKIMやDMARCも確認します。SPFにパスしても、DKIM署名もDMARCレコードもないレコードは、部分的にしか認証されていません。

3つともすべて設定してください。DMARCレコードを安全に公開し、レポートを読む方法は、当社のDMARCガイドで解説しています。

参考資料と出典

• RFC 7208: Sender Policy Framework (SPF)
• Google Workspace: Define your SPF record
• Microsoft: Set up SPF to help prevent spoofing

MigoSMTPで実践:ヘルプセンターの記事

• SPFのpermerrorと10回のルックアップ上限を解消する
• MigoSMTPで送信ドメインを認証する:SPF、DKIM、DMARC
• 送信ドメインを検証する:DNSレコードと反映

関連ガイドとツール

• SPFレコードチェッカー:レコードを検索し、DNSルックアップ数を数えます。
• SPFレコードジェネレーター:送信元からレコードを作成します。
• DMARCの設定方法:p=noneから始めて、安全にrejectへ移行します。