SPFレコードとは？
SPFレコード（Sender Policy Framework、RFC 7208）は、そのドメインのメールを送信してよいサーバーを列挙した、ドメイン上のTXTレコードです。メールが届くと、受信側のサーバーはエンベロープ送信者のドメイン（表示上のFromアドレスではなくReturn-Path）のSPFレコードを調べ、送信元IPがリストに含まれているかを確認します。
1つのドメインに設定できるSPFレコードは1つだけです。v=spf1 で始まるレコードが2つあると、すべてのSPFチェックがPermErrorで失敗します。そのため、新しいサービスを追加するときは、レコードを増やすのではなく既存のレコードを編集します。2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMを、大量送信者にはSPF、DKIM、DMARCのすべてを求めています。
SPFレコードを作成する方法
メールボックスのプロバイダー、メルマガ配信やトランザクションメールのサービス、ヘルプデスク、CRM、さらにドメインからメールを送るサーバーやWebサイトも含めます。1つでも漏れていることが、SPFが失敗する最も多い原因です。
上のリストから各プロバイダーを選び、その他のincludeドメインを追加し、自社サーバーをIPv4またはIPv6アドレスで入力します。mxは、受信用のメールサーバーが送信も行う場合にだけ使います。
最初は ~all（ソフトフェイル）が一般的です。リストに漏れがないと確信できたら -all（フェイル）に切り替えます。ルックアップ数のカウンターにも注意してください。10回以下に収める必要があります。
ホストを @（またはメールを送信するサブドメイン）にしたTXTレコードとして追加し、既存の v=spf1 レコードは置き換えます。その後、SPFチェッカーで確認しましょう。
Advertisement
SPFレコードの書き方：構文の解説
SPFレコードは、左から右へ順に読まれる項目のリストです。送信元IPに最初に一致した項目が結果を決めます。
バージョンタグです。必ず最初の項目に置く必要があり、受信側はこれによってTXTレコードをSPFと認識します。
include:_spf.google.com のように、別ドメインのSPFレコードに含まれるすべてを許可します。そのレコード内のルックアップもすべて、自分の上限に加算されます。
1つのアドレスまたはCIDR範囲を許可します。例：ip4:203.0.113.10、ip6:2001:db8::/48。DNSルックアップは発生しません。
ドメインのA/AAAAレコード、またはMXホストのIPを許可します。便利ですが、それぞれルックアップを1回消費し、mxは内部でさらに最大10回のクエリが発生することがあります。
それ以外のすべてのサーバーをどう扱うかを指定します：ソフトフェイル、フェイル、ニュートラルのいずれかです。誰でもあなたのドメインとして送信できてしまう +all は、絶対に公開しないでください。
redirect= はチェック全体を別ドメインのレコードに委ねます。exists: は一部の大規模送信者がマクロと組み合わせて使います。ptr は低速で、RFC 7208では公開しないよう定められています。
~allと-allの違い：ソフトフェイルかフェイルか
-all は、リストにないサーバーからのメールがSPFに失敗（fail）したことを受信側に伝え、多くの受信側はそのメールを拒否します。~all ではソフトフェイルになります。受信側はそれだけを理由に拒否すべきではありませんが、疑わしいメールとして扱うことがあります。?all はニュートラルで、保護効果はありません。
GoogleのWorkspace向け手順では ~all が、MicrosoftのMicrosoft 365の例では -all が使われており、どちらでも機能します。DMARCを公開すると、失敗したメールの扱いはDMARCポリシー（p=quarantine または p=reject）で決まります。そのため、転送された正当なメールを拒否しないよう ~all のままにし、強制はDMARCに任せるドメインも多くあります。メールをまったく送信しないドメインでは、v=spf1 -all を公開してください。
Advertisement
SPFレコードの記述例
自分の環境に最も近いものをコピーするか、上の作成ツールで独自のレコードを作成してください。どれもドメインに設定する1つのTXTレコードです。
v=spf1 include:_spf.google.com ~allv=spf1 include:spf.protection.outlook.com -allv=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~allv=spf1 include:zohomail.com ~allv=spf1 mx ip4:198.51.100.0/24 ip6:2001:db8::/48 -allv=spf1 -allDNSルックアップ10回の上限
RFC 7208では、1回のSPFチェックで行えるDNSルックアップは10回までです。include、a、mx、ptr、exists、redirect はそれぞれ1回を消費し、includeしたレコード内のこれらの項目も1回ずつ数えられます。ip4、ip6、all は消費しません。11回目のルックアップが必要になったチェックはPermErrorで停止し、DMARCではSPFの失敗として扱われます。また受信側は、void lookup（存在しない名前や、レコードを返さない名前）を2回までしか許可しないことになっています。
プロバイダーによって消費する回数は異なります。2026年10月5日に、入れ子のルックアップも含めて各includeを数えた結果です：
_spf.google.com と spf.protection.outlook.com はIP範囲を直接記載しています。Amazon SES、Brevo、Mailjet、Zendesk、Fastmailも1回です。
それぞれ、独自のレコードをもう1つ参照しています。
ホスティングのメールボックスは、複数のincludeを連鎖させていることがよくあります。
このうち1つにいくつかのサービスを加えるだけで、上限をすべて使い切ることがあります。
Advertisement
ルックアップ数が多すぎるSPFレコードを修正する方法
使っていないサービスを削除する。 古いメルマガ配信ツールや試用アカウントがよくある原因です。
`a` と `mx` を `ip4`/`ip6` に置き換える。 自社サーバーのアドレスが固定されている場合に有効です。
大量配信のメールをサブドメインに移す。 news.example.com のようなサブドメインは独自のSPFレコードを持ち、10回のルックアップも別枠になります。
そもそもincludeが必要か確認する。 多くの送信サービスは独自のバウンスドメインを使うため、SPFは相手側のドメインで合格し、DMARCのアライメントはDKIMで満たされます。
SPFフラット化には注意する。 includeをコピーしたIPリストに置き換える方法は、プロバイダーがIPを変更するまでは機能しますが、変更されると予告なくメールが失敗し始めます。
SPFでよくある間違い
同じドメインに2つのSPFレコードがある（プロバイダーごとに1つなど）。1つに統合してください。
インターネット全体を許可してしまう
+allを使っている。レコードを間違った名前で公開している。SPFはエンベロープ送信者のドメインでチェックされ、サブドメインには継承されません。
allの後ろにメカニズムを追加している。受信側はそれらを評価しないため、その送信元は許可されません。送信元を書き忘れている。たとえば、お問い合わせフォームのメールを送るWebサーバーなど。
古いSPFレコードタイプ（タイプ99）を使っている。RFC 7208で廃止されたため、TXTのみを公開してください。
Advertisement
SPF、DKIM、DMARCは連携して機能する
SPFだけでは、読者に表示されるFromアドレスのなりすましは防げません。DKIMは各メッセージに署名し、DMARCはその両方を表示上のFromドメインと結び付け、失敗したときの対処を受信側に伝えます。3つすべてを設定しましょう：