メールの正当性を証明し、迷惑メールとして誤判定されるリスクを減らすために、SPF（Sender Policy Framework）レコードの設定はもはや必須の対策です。GmailやOutlookなど主要なメールサービスでは、SPFが正しく設定されていないメールを拒否するケースが増えています。本記事では、SPFレコードの概要から、SPFの仕組み、SPFレコードの構成要素と記述方法、具体的な設定手順と確認方法まで、企業の情報システム担当者やエンジニア向けにわかりやすく整理して解説します。
目次
SPFレコードとは、送信元ドメイン認証の一種であるSPF（Sender Policy Framework）を設定するために必要なDNSレコードです。
SPFは、そのドメインを使用してメールを送信するメールサーバーの情報（IPアドレスなど）を公開することで、受信側がメールの送信元サーバーの正当性を確認できるようにする仕組みです。
近年、Gmailなどの主要メールサービスでは、SPFやDKIMなどの送信ドメイン認証を実装していないドメインからのメールは、迷惑メールとして扱うようになっています。SPFレコードについては、未設定・認証失敗の場合は以前から迷惑メールとして扱われる可能性がありましたが、特に2024年2月に改定されたGmailの送信者ガイドラインで明確にSPFまたはDKIMの認証設定が必須とされました。
メールサーバー管理者やシステム担当者にとって、SPFの理解と適切なSPFレコードの設定は、自社のメールを正常に運用するために欠かせない知識となっています。
SPFが必要とされる背景、設定すべき理由としては以下のようなものがあります。
GmailやOutlook、iCloudなどの主要メールサービスでは、SPFをはじめとした送信ドメイン認証の導入が実質的に必須となっています。特にGoogleは、2024年のガイドライン改定により、全ての組織に対してSPFまたはDKIMによる認証と、5,000通以上配信する組織についてはDMARCのアライメントの対応を必須化しました。SPFが未設定のままでは、正当なメールであっても相手に届かないリスクが高まります。
SPFレコードを設定することで、第三者が自社ドメインを偽装して不正にメールを送信する「なりすまし」を抑止でき、ブランドの信頼性を守ることにつながります。自社ドメインの不正利用を放置してしまうと、自社のドメインがスパムの発信元として扱われ、ブラックリスト登録や正規メールの到達阻害といった悪影響も生じかねません。
SPFは、DMARCを機能させるために必要な要素でもあります。DMARCは、ヘッダFromのドメインと、SPFまたはDKIMのいずれかで認証したドメインが一致（アライメント）しているかを確認する認証方式です。SPFが正しく設定されていなければ、DMARCによる認証も失敗してしまいます。現在ではSPF・DKIMに加えてDMARCを必須としているメールサービスも増えているため、DMARCに対応する上でも必須だと言えます。
SPFの認証プロセスは以下のような流れとなります。
SPFレコードはDNSにTXTレコードとして登録します。SPFレコードを構成する要素は以下のとおりです。
SPFレコードの先頭には、バージョン識別子を必ず記述します。これはSPFレコードであることを示す定型的な書き出しであり、省略や変更はできません。現在の仕様では、「v=spf1」が唯一指定できるバージョンです。
メカニズムは、どの送信元（IPアドレスやドメイン）を許可または評価の対象とするかを定義するためのものです。SPFレコードには複数のメカニズムを並べることができ、上から順に評価されます。利用できるメカニズムには以下があります。
| メカニズム | 内容 | 例 |
|---|---|---|
| ip4 | IPv4のIPアドレス範囲を指定 | ip4:203.0.113.0/24 |
| ip6 | IPv6のIPアドレス範囲を指定 | ip6:2001:db8::/32 |
| a | 指定したドメインのA/AAAAレコードのIPアドレスを参照 | a または a:example.com |
| mx | 指定したドメインのMXレコードのメールサーバーを参照 | mx または mx:example.com |
| include | 他ドメインのSPFポリシーを参照 | include:_spf.example.net |
| exists | 指定ドメインが存在する場合に一致させる | exists:%{i}._spf.example.com |
| all | すべての送信元を指定 | -all, ~all など |
限定子は、メカニズムの前に付けることで、その対象について「許可／拒否」の意図を示すための記号です。指定がなければ +（許可）がデフォルトになります。
| 限定子 | 意味 | 判定結果 |
|---|---|---|
| +（省略可） | Pass | 許可 |
| – | Fail | 拒否（正規でない送信元） |
| ~ | SoftFail | 原則拒否だが、柔軟に扱う（※迷惑メールとして扱われることが多い） |
| ? | Neutral | 許可・拒否を判定しない |
修飾子は、SPFレコードに追加の制御情報を与えるための「key=value」形式のパラメータです。RFC 7208では以下の2つが定義されています。
| 修飾子 | 内容 | 例 |
|---|---|---|
| redirect= | 他のドメインのSPFレコードに処理を委譲 | redirect=_spf.example.net |
| exp= | SPF評価がFailだった場合に返す説明用メッセージを定義（実装例は少ない） | exp=explain.example.com |
これらの構成要素を組み合わせて、自社のメール送信環境に最適なSPFレコードを定義します。正しい構文と適切な設定要素の選択が、効果的なメールセキュリティの実現には不可欠です。
SPFレコードは、正確な書き方を知らなければ効果が得られないばかりか、メール配信にトラブルを引き起こす可能性もあります。このセクションでは、まずSPFレコードの基本的な書式構造を解説し、次に実務で役立つ具体的な記述例を紹介します。
SPFレコードの先頭は必ず「v=spf1」から始まり、末尾は通常「all」で終わります。 SPFレコードの基本書式は、次の通りです。なお、ひとつの文字列（” ”で囲まれた部分）の最大文字数は255文字です。
ドメイン. IN TXT “【バージョン指定】【限定子】【メカニズム】:【値】”
以下の例では、特定のIPアドレス（192.168.10.1）を許可し、それ以外の送信元からのメールは拒否（Fail）することを意味しています。
XXX.co.jp. IN TXT “v=spf1 +ip4:192.168.10.1 -all
ここでは、代表的なSPFレコードの記述例をいくつか紹介します。自社のメール送信環境に合わせてカスタマイズする際の参考にしてみてください。
IPアドレスではなく、ホスト名で指定しています。このとき、省略形ではなくFDQN（ホスト＋ドメイン名）で記載することを忘れないようにしてください。
XXX.co.jp. IN TXT “v=spf1 a:www.XXX.co.jp -all”
メールを送信する可能性があるホストが属するネットワークを、CIDR方式を用いて指定します。
XXX.co.jp. IN TXT “v=spf1 ip4:198.168.10.0/28 -all”
自社サーバをIPアドレスで指定し、その他に外部サービスからの送信を許可する場合は以下のように記載します。
XXX.co.jp. IN TXT “v=spf1 ip4:192.168.10.1 include:spf.third-party.com -all”
メインのドメインにSPFレコードを設定しても、サブドメインには適用されません。サブドメインからメールを送信する場合は、SPFレコードの個別設定が必要です。
XXX.co.jp. IN TXT “v=spf1 +ip4:192.168.10.1 -all”
shop.XXX.co.jp. IN TXT “v=spf1 +ip4:192.168.10.2 -all”
Webサイトのためだけに利用しているドメインなど、メールを送信しない場合は「メールを使わない」と宣言することでなりすましを防止することができます。
XXX.co.jp. IN TXT “v=spf1 -all”
ここでは、SPFレコードを設定するための具体的な手順を解説します。
まずは、どのドメインにSPFレコードを設定する必要があるか、また、それぞれのドメインからメールを送信するサーバーは何かを整理します。
●自社で管理しているドメイン
ここではメール送信に利用していないものも含め、すべてのドメインを確認することをお薦めします。自社でメール送信に利用していなくとも、なりすましに悪用されてしまう恐れがあるからです。
●自社のメールを送信しているすべてのサーバー
ドメインごとに、実際にメール送信を行っているサーバーをリストアップします。主な例は以下の通りです。
これらの情報をもとに、どのIPアドレスやドメインをSPFで許可すべきかが決まります。
洗い出した送信元情報をもとに、SPFレコードを記述します。構文ミスを防ぐためには、専用の生成ツールの活用が効果的です。
以下のようなツールでは、IPアドレスや利用サービスのドメインを入力するだけで、構文に沿ったSPFレコードを自動で生成できます。
POWER DMARC「無料SPF生成ツール」https://powerdmarc.com/ja/spf-record-generator/
Skysnag「SPFコードジェネレーター」https://www.skysnag.com/ja/spf-generator/
SPFレコードは、ドメインのDNSゾーンにTXTレコードとして追加します。
DNSサービス（例：お名前.com、さくらのDNS、Cloudflare、Route 53 など）を利用している場合は、具体的な設定手順はサービスによって異なりますが、基本的な流れは以下の通りです。
1. 管理画面でドメインのDNS設定にアクセス
2. TXTレコードを追加
| 項目 | 内容 |
|---|---|
| レコードタイプ | TXT |
| ホスト名（名前） | 空欄（ルートドメインの場合は何も入力しなくてOK） |
| 値（内容） | SPFで指定する内容 “v=spf1 ip4:203.0.113.1 include:_spf.example.com -all” |
3. 保存・反映
✅ 注意点
以下の記事でお名前.comとAmazon Route 53での設定手順を解説しているので、必要に応じてご参照ください。
お名前.comでSPF・DKIM・DMARCのDNSレコードを設定する | ベアメールブログ
Amazon Route 53でSPF・DKIM・DMARCのDNSレコードを設定する | ベアメールブログ
SPFレコードをDNSに設定したあとは、必ず設定内容が正しく反映されているかを確認することが重要です。
設定ミスなどによりエラーが発生してしまうと、正当なメールが迷惑メールに分類されたり、受信拒否されたりする恐れがあります。
その前提として、SPFにはいくつか見落とされがちな仕様上の制限があります。確認作業を行う際にも密接に関係するため、先に注意点を整理しておきましょう。
● SPFレコードは1ドメインに1つのみ
設定のところでも触れましたが、同じドメインに複数の v=spf1 レコードが存在すると、SPF認証は必ず失敗します（PermError）。すべての許可対象を1つのレコードにまとめる必要があります。
● DNSルックアップ回数の上限（10回）
SPFでは、includeや a、mx など一部のメカニズムがDNSルックアップを行います。1つのSPFレコードで参照できるルックアップは最大10回までと定められており（RFC 7208）、これを超えるとSPFが「permerror」となり、メールが拒否される恐れがあります。
ルックアップの上限に達しやすい状況としては以下が挙げられます。
DNSルックアップ回数制限について詳しくはこちらの記事で解説しています。
SPFのDNSルックアップの回数制限とは？ 確認方法や対策を解説 | ベアメールブログ
SPFレコードの設定内容を確認する方法としては、主に3つあります。構文エラーやDNSの反映漏れを防ぐだけでなく、SPFが実際に認証に使われているかどうかも検証することが重要です。
DNSに設定されたTXTレコードが正しく公開されているかを確認する基本的な方法です。
⚫︎Windows（nslookup）
nslookup -type=TXT example.com⚫︎macOS / Linux（dig）
dig TXT example.comSPFレコードをWeb上で簡単に確認できるツールがあります。SPFの存在確認だけでなく、SPFの構文チェック、ルックアップ回数の検査、評価結果のシミュレーションなども併せて行えるため便利です。
MxToolBox「SPF Record Check」https://mxtoolbox.com/spf.aspx
Kitterman「SPF Record Testing Tools」https://www.kitterman.com/spf/validate.html
SPFの認証がメール受信時にどう評価されているかは、受信したメールのヘッダ情報から確認できます。
例：Gmailで受信したメールのヘッダ（Authentication-Results:）
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of user@example.com designates 203.0.113.1 as permitted sender)
smtp.mailfrom=user@example.com; 本稿では、SPFレコードの設定方法・記述例などについて解説してきました。メール到達率は、マーケティングや広報、顧客とのコミュニケーションの質に影響するため、きわめて重要な指標です。しかし、送信ドメイン認証が正しく機能していなければ、メール到達率は改善しません。メール到達率が思わしくない場合は、まずSPFレコードの設定を見直してみてはいかがでしょうか。