SPFレコードのチェックと作成

SPFレコードをチェックする方法

1. 上の入力欄にドメインを入力します。メールアドレスをそのまま入力しても構いません。ツールはドメイン部分だけを使います。
2. 「SPFレコードをチェック」をクリックします。公開DNSから現在のレコードを読み取ります。受信サーバーが読むのと同じレコードです。
3. まず概要を確認します。レコードが有効か、警告があるか、壊れているかがわかります。
4. 問題がある場合は、問題の一覧を確認します。それぞれに変更すべき点が書かれています。
5. その下で、レコードの各部分の意味と、それぞれが使うDNSルックアップの数を確認できます。includeを開くと、その先のサービスが許可している内容を確認できます。

アドレスバーのリンクを開くと、同じSPFチェックがもう一度実行されます。同僚やDNSの管理会社に送ることができます。注意点が1つあります。受信サーバーは、メールを送ったサーバーのIPアドレスに対してSPFを確認します。このツールには確認するメールがないため、レコード自体をチェックします。送信サーバーごとに内容が変わるSPFマクロを使った部分は評価できません。

SPFレコードとは

SPFレコードは、ドメインのDNSに登録するTXTレコードです。そのドメインのメールを送ってよいサーバーを一覧にしたものです。SPFはSender Policy Frameworkの略で、ルールはRFC 7208に定められています。Google Workspaceを使うドメインには、次のようなレコードがよく設定されています。

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

v=spf1 は、これがSPFレコードであることを示します。include:_spf.google.com は、Google自身の一覧にあるすべてのサーバーを許可します。~all は、それ以外のサーバーからのメールを疑わしいものとして扱うよう受信サーバーに伝えます。

メールが届くと、受信サーバーはバウンスアドレス（Return-Path）からドメインを取り出します。そのドメインのSPFレコードを読み、送信サーバーのIPアドレスが一覧にあるかを確認します。SPFは、受信トレイに表示される差出人（From）アドレスは確認しません。そのため、SPFはDKIMやDMARCと組み合わせて使います。3つの関係はSPF・DKIM・DMARCの解説をご覧ください。

2024年2月から、Gmailはすべての送信者にSPFまたはDKIMを求めています。大量送信者には両方を求めています。Yahooも同じルールです。

SPFレコードの各部分の意味

SPFレコードは、スペースで区切った項目の並びです。受信サーバーは左から順に読み、送信サーバーに最初に一致した項目で止まります。

どの部分にも、一致したときの結果を決める修飾子を先頭に付けられます。+ はpass（合格）で、既定値のため通常は書きません。- はfail（失敗）、~ はsoftfail（ソフトフェイル）、? はneutral（中立）です。そのため、同じallでも、レコードの末尾は -all、~all、?all のように変わります。

名前の大文字と小文字は区別されません。Include: も include: と同じように動きます。RFC 7208は、すべてのレコードをallまたはredirectで終えることを推奨しています。どちらもない場合、一覧にないサーバーの結果はneutralになります。

DNSルックアップの上限は10回

include、a、mx、ptr、exists、redirectは、それぞれ受信サーバーにDNSルックアップを1回行わせます。RFC 7208が認める合計は10回です。include先でのルックアップも数えるため、1つのincludeで数回分を使うことがあります。ip4、ip6、allはルックアップを使いません。10回を超えるレコードでは、受信サーバーは処理を止めてpermerrorを返し、SPFは失敗します。

この上限にはすぐに達します。よく使われるincludeのコストを公開DNSで測定したところ、Google Workspaceは1回、Microsoft 365は1回、Salesforceは2回、Mailgunは5回、Freshdeskは7回でした。Google Workspaceを使う会社がMailgunとFreshdeskを追加すると、それだけで13回必要です。.com、.net、.org、.seのSPFレコードを調べた2024年の研究では、6.5%が10回を超えるルックアップを必要としていました。そのうち83.7%は、わずか2つのホスティング事業者のレコードのincludeが原因でした。

コストは変わることもあります。Googleのincludeは2025年12月まで4回のルックアップを使っていました。この月にGoogleはネストしたincludeを1つの一覧に置き換えました。今でも4回と書いているSPFの解説や生成ツールがあります。上のチェッカーは、実行するたびに実際の回数を数えます。

上限を超えても、すべてのメールが失敗するとは限りません。Microsoftが指摘しているように、受信サーバーは最初に一致した項目で止まります。前の方に書かれたサーバーからのメールは合格し、後ろの方に書かれたサーバーからのメールは失敗することがあります。問題が不規則に見えるため、レコード全体の回数を数えてください。

上限はもう1つあります。何も見つからなかったルックアップを空のルックアップ（void lookup）と呼びます。たとえば、もう存在しないドメインへのincludeです。RFC 7208は、これが2回あった時点で受信サーバーは処理を止めるべきだとしています。

DNSルックアップを10回以内に減らす方法

1. もう使っていないサービスのincludeを削除します。
2. サービス側が求めなくなったincludeを削除します。Mailchimp、Postmark、Brevo、Klaviyoはメインドメインにincludeを必要としません。SendGridとAmazon SESはサブドメインに設定します。一覧はこの下にあります。
3. 自社のサーバーは、aやmxではなくip4とip6で書きます。RFC 7208はこの書き方を推奨しており、IPアドレスはルックアップを使いません。
4. 一部のメールは、news.example.comのようなサブドメインから送ります。サブドメインごとに独自のレコードがあり、それぞれ10回まで使えます。

SPFフラット化（flattening）を提供するサービスもあります。includeを、その先にあるIPアドレスに置き換える方法です。ルックアップは減りますが、事業者がアドレスを変えても、フラット化したレコードは追随しません。Microsoftは、安定していて公開されたIP範囲を持つサービスだけをフラット化し、Microsoft 365自体はフラット化しないよう勧めています。また、少なくとも四半期ごとに結果を確認するよう勧めています。

Google Workspace、Microsoft 365などのSPF include一覧

各サービスの設定ガイドに記載されたincludeの値と、それぞれが使うDNSルックアップの回数です。回数は2026年10月12日に公開DNSで測定しました。サービスを設定するときは、そのサービスのガイドから値をコピーしてください。地域やアカウントによって値が変わる場合があります。

HubSpotはアカウントごとに専用のincludeを発行します。末尾はhubspotemail.netです。HubSpotのメール設定からコピーしてください。ルックアップは1回です。

通常はincludeが不要なサービス

SPFは差出人（From）アドレスではなく、バウンスアドレスに対して確認されます。多くの送信サービスは、自社のバウンスアドレスか、お客様のドメインのサブドメインを使うようになりました。それらのincludeをメインドメインに書いても、ルックアップを消費するだけです。

• Mailchimp. Mailchimpのドメイン設定で求められるのは、現在はDKIMとDMARCのレコードだけで、SPFは求められません。
• Postmark. Postmarkは、SPFはもう必要ないとしています。Postmark自身のバウンスアドレス、またはPostmarkを指すReturn-Pathレコードを使って送信します。
• Brevo. Brevoは、専用IPアドレスから送信する場合を除き、SPFは必要ないとしています。
• Klaviyo. Klaviyoは、通常SPFレコードを追加する必要はないとしています。
• SendGrid. SendGridのドメイン認証では、em1234.yourdomain.comのように自動で作成されるサブドメインにSPFが設定されます。
• Amazon SES. SESで必要なのは、bounce.yourdomain.comのようなカスタムMAIL FROMサブドメインを使う場合だけです。既定ではSES自身のバウンスアドレスを使います。

チェッカーは、レコードにこれらのincludeを見つけると指摘します。

SPFレコードを作成する方法

上の「作成」タブでSPFレコードを生成できます。メールを送っているサービスにチェックを入れると、レコードを作成し、ルックアップ数を数えます。ドメインにすでにレコードがある場合は、先にそれを読み込んでください。既存のレコードを置き換えずに、追加する形で作成できます。手順は次のとおりです。

1. ドメインのアドレスでメールを送るサービスをすべて書き出します。メールボックスのサービスだけでなく、ニュースレター、CRM、ヘルプデスク、請求、Webサイトのフォームも考えてください。DMARCレポートを見ると、忘れていた送信元がわかります。
2. 各サービスのincludeを設定ガイドで確認するか、ツールでチェックを入れます。自社のメールサーバーは、IPアドレスで書きます。
3. 末尾を ~all にするか -all にするかを選びます。違いは次のセクションで説明します。
4. ドメイン自体に1つのTXTレコードとして公開します。多くのDNS管理画面では、この名前を@と呼びます。v=spf1で始まるレコードがすでにある場合は、2つ目を追加せずにそのレコードを編集します。
5. 数分待ってから、SPFチェッカーでもう一度ドメインをチェックします。

サブドメインは親ドメインのレコードを使わないため、メールを送る名前ごとにレコードが必要です。メールを一切送らないドメインやサブドメインにも、v=spf1 -all を設定してください。RFC 7208は、これを確立されたベストプラクティスとしています。その名前をかたって合格するメールを他人が送れなくなります。英国NCSCは、こうしたドメインにp=rejectのDMARCレコードとNull MXレコードも追加するよう勧めています。

255文字を超えるレコードは、同じTXTレコードの中で複数の文字列に分ける必要があります。受信サーバーは文字列をスペースなしでつなげるため、スペースは文字列の間ではなく、文字列の中に入れてください。長い値の扱いはDNS管理会社によって異なるため、確認してください。

~all と -all：どちらの末尾を使うべきか

大手の事業者の間でも意見は分かれており、それぞれに理由があります。

• Googleは ~all を推奨しています。
• 大手メールボックス事業者や送信者が加盟する業界団体M3AAWGは、レコードを ~all で終えるべきだとしています。また、DMARCの確認が終わるまでSPFのfailを理由に拒否しないよう、受信側に求めています。
• Microsoftは、DKIMとDMARCも設定していることを条件に、-all を推奨しています。

-all のリスクは、一部の受信サーバーがDMARCを確認する前に、配信の途中でメールを拒否することです。2026年のDMARC標準であるRFC 9989は、こうしたメールはDMARCレポートに表れないと指摘しています。そのため、問題を見つけにくくなります。

実際には、メールを送るドメインでは ~all のほうが安全です。すべての送信元をまだ洗い出している段階では特にそうです。DMARCがquarantineまたはrejectであれば、失敗したメールの扱いはいずれにしてもDMARCが決めます。メールを一切送らないドメインには -all を使います。すべてのサーバーを合格させる +all は絶対に使わないでください。レコードがないのと同じ扱いになる ?all も避けてください。

SPFチェック結果の意味

受信サーバーは、SPFチェックの結果を独自の言葉で表します。spf=passやspf=softfailのようにメールヘッダーに表示されるほか、DMARCレポートにも表示されます。

よくあるSPFレコードのエラーと修正方法

2023年に人気ドメイン1,200万件を調べた調査では、56.5%にSPFが設定されており、SPFレコードの2.9%にエラーがありました。最も多いエラーは、SPFレコードのない名前を指すincludeやredirectでした。2番目に多かったのは、ルックアップ数の超過です。

1つのドメインにSPFレコードが2つある

新しいサービスの設定ガイドに「このTXTレコードを追加してください」とあり、古いレコードの横に追加してしまうとよく起こります。レコードが2つあるとpermerrorになります。1つにまとめてください。v=spf1を1つだけ先頭に置き、すべてのincludeとIPアドレスを並べ、最後にallを1つだけ書きます。

存在しない先を指すinclude

includeがSPFレコードのないドメインを指していると、レコード全体がpermerrorで失敗します。入力ミスのこともあれば、サービスが終了したり、includeを変更したりしたこともあります。削除するか、サービスの現在の値に置き換えてください。

末尾が +all、?all、またはallがない

+all はインターネット上のすべてのサーバーを許可するため、レコードは何も保護しません。?all やallがない場合はneutralの結果になり、受信サーバーはレコードがないのと同じように扱います。レコードの末尾は ~all か -all にしてください。

レコードにptrがある

RFC 7208は、ptrを使うべきではないとしています。遅く、ルックアップを1回使い、DNSに問題があるときは他の仕組みより信頼性が下がります。対象のサーバーをip4とip6で書いて置き換えてください。

入力ミス

コロンの後のスペース、一部が欠けたIPv4アドレス、SPFにない単語は、どれもpermerrorの原因になります。目立たないミスもあります。等号を使った include=example.com は不明な設定として読み飛ばされるため、そのサービスは許可されません。チェッカーはこれらをすべて指摘します。

SPFの解説でよく見られる3つの誤り

• 「SPFレコードに大文字は使えない」。RFC 7208は、名前の大文字と小文字を区別しないとしています。
• 「SPFレコードは最大255文字」。255文字の上限は、文字列1つごとの上限です。長いレコードは複数の文字列に分けます。RFC 7208が求めているのは、DNSの応答全体を約450バイト未満の小さいサイズに保つことだけです。
• 「includeは10個まで使える」。上限が数えるのはDNSルックアップです。include先でのルックアップも数えます。

SPFはメール認証の一部です

SPFの合格には限界があります。同じ2023年の調査では、34.7%のドメインが100,000を超えるIPアドレスからのメールを許可していました。また、誰かがメールを転送すると、転送サーバーはレコードにないため、SPFは失敗します。

DKIMはメール自体に署名するため、通常は転送後も有効です。DMARCは、SPFまたはDKIMが差出人（From）アドレスと同じドメインで合格したかを確認し、どちらも合格しなかったときの扱いを受信サーバーに伝えます。多くの送信サービスは自社のバウンスドメインでSPFに合格しますが、そのドメインは差出人アドレスと一致しません。サービス側でReturn-Pathをカスタム設定すると解決します。残りの2つのレコードはDKIM生成ツールとDMARC生成ツールで設定し、MXレコード確認ツールでドメインのメールの受信先を確認してください。

また、認証は存在しないアドレスには役立ちません。そうしたアドレスへのメールはバウンスし、バウンス率が高いと到達率が下がります。1件ずつならメールアドレスチェッカー、リスト全体ならメールアドレスの一括検証で確認できます。チームと共有できる短い定義は、用語集のSPFレコードをご覧ください。