SPFレコードとは？ 書き方・設定手順・確認方法まで完全ガイド

Last Updated on 2025.05.30

メールの正当性を証明し、迷惑メールとして誤判定されるリスクを減らすために、SPF（Sender Policy Framework）レコードの設定はもはや必須の対策です。GmailやOutlookなど主要なメールサービスでは、SPFが正しく設定されていないメールを拒否するケースが増えています。本記事では、SPFレコードの概要から、SPFの仕組み、SPFレコードの構成要素と記述方法、具体的な設定手順と確認方法まで、企業の情報システム担当者やエンジニア向けにわかりやすく整理して解説します。

SPFレコードとは？

SPFレコードとは、送信元ドメイン認証の一種であるSPF（Sender Policy Framework）を設定するために必要なDNSレコードです。

SPFは、そのドメインを使用してメールを送信するメールサーバーの情報（IPアドレスなど）を公開することで、受信側がメールの送信元サーバーの正当性を確認できるようにする仕組みです。

近年、Gmailなどの主要メールサービスでは、SPFやDKIMなどの送信ドメイン認証を実装していないドメインからのメールは、迷惑メールとして扱うようになっています。SPFレコードについては、未設定・認証失敗の場合は以前から迷惑メールとして扱われる可能性がありましたが、特に2024年2月に改定されたGmailの送信者ガイドラインで明確にSPFまたはDKIMの認証設定が必須とされました。

メールサーバー管理者やシステム担当者にとって、SPFの理解と適切なSPFレコードの設定は、自社のメールを正常に運用するために欠かせない知識となっています。

SPFレコードを設定すべき理由

SPFが必要とされる背景、設定すべき理由としては以下のようなものがあります。

迷惑メールとして扱われ、メールが届かなくなるリスクがある

GmailやOutlook、iCloudなどの主要メールサービスでは、SPFをはじめとした送信ドメイン認証の導入が実質的に必須となっています。特にGoogleは、2024年のガイドライン改定により、全ての組織に対してSPFまたはDKIMによる認証と、5,000通以上配信する組織についてはDMARCのアライメントの対応を必須化しました。SPFが未設定のままでは、正当なメールであっても相手に届かないリスクが高まります。

自社のドメインが「なりすまし」に利用されるリスクがある

SPFレコードを設定することで、第三者が自社ドメインを偽装して不正にメールを送信する「なりすまし」を抑止でき、ブランドの信頼性を守ることにつながります。自社ドメインの不正利用を放置してしまうと、自社のドメインがスパムの発信元として扱われ、ブラックリスト登録や正規メールの到達阻害といった悪影響も生じかねません。

DMARCのベースとしても必要

SPFは、DMARCを機能させるために必要な要素でもあります。DMARCは、ヘッダFromのドメインと、SPFまたはDKIMのいずれかで認証したドメインが一致（アライメント）しているかを確認する認証方式です。SPFが正しく設定されていなければ、DMARCによる認証も失敗してしまいます。現在ではSPF・DKIMに加えてDMARCを必須としているメールサービスも増えているため、DMARCに対応する上でも必須だと言えます。

SPFの仕組み

SPFの認証プロセスは以下のような流れとなります。

1. ドメイン「example.com」を送信元としてメールが送信される
2. 受信側のメールサーバーはメールを受け取ると、送信元ドメイン「example.com」のDNSサーバーにSPFレコードを問い合わせる
3. 受信側メールサーバーは、受け取ったメールの送信元サーバーのIPアドレスと、SPFレコードに記載されているIPアドレス（許可されているサーバー情報）を照合する
4. 照合結果に基づいて、メールの正当性を判定する
   • 一致する場合：SPF認証成功（Pass）
   • 一致しない場合：SPF認証失敗（Fail、SoftFail、Neutralなど）

SPFレコードの構成要素

SPFレコードはDNSにTXTレコードとして登録します。SPFレコードを構成する要素は以下のとおりです。

バージョン指定（version）

SPFレコードの先頭には、バージョン識別子を必ず記述します。これはSPFレコードであることを示す定型的な書き出しであり、省略や変更はできません。現在の仕様では、SPF v1（v=spf1）が唯一指定できるバージョンです。

メカニズム（mechanisms）

メカニズムは、どの送信元（IPアドレスやドメイン）を許可または評価の対象とするかを定義するためのものです。SPFレコードには複数のメカニズムを並べることができ、上から順に評価されます。利用できるメカニズムには以下があります。

メカニズム	内容	例
ip4	指定したIPv4アドレスからの送信を指定	ip4:203.0.113.0/24
ip6	指定したIPv6アドレスを指定	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 など

限定子（qualifiers）

限定子は、メカニズムの前に付けることで、その対象について「許可／拒否」の意図を示すための記号です。指定がなければ +（許可）がデフォルトになります。

修飾子	意味	判定結果
+（省略可）	Pass	許可
–	Fail	拒否（正規でない送信元）
~	SoftFail	原則拒否だが、柔軟に扱う（※迷惑メールとして扱われることが多い）
?	Neutral	許可・拒否を判定しない

修飾子（modifiers）

修飾子は、SPFレコードに追加の制御情報を与えるための「key=value」形式のパラメータです。RFC 7208では以下の2つが定義されています。

修飾子	内容	例
redirect=	他のドメインのSPFレコードに処理を移譲	redirect=_spf.example.net
exp=	SPF評価がFailだった場合に返す説明用メッセージを定義（実装例は少ない）	exp=explain.example.com

これらの構成要素を組み合わせて、自社のメール送信環境に最適なSPFレコードを定義します。正しい構文と適切な設定要素の選択が、効果的なメールセキュリティの実現には不可欠です。

SPFレコードの書き方

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レコードの記述例をいくつか紹介します。自社のメール送信環境に合わせてカスタマイズする際の参考にしてみてください。

FDQN（ホスト＋ドメイン名）での記載例

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 “ip4:192.168.10.1 include:spf.third-party.com -all” XXX.co.jp.　IN TXT “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レコードを設定するための具体的な手順を解説します。

SPFの対象ドメインと送信サーバーを洗い出す

まずは、どのドメインにSPFレコードを設定する必要があるか、また、それぞれのドメインからメールを送信するサーバーは何かを整理します。

●自社で管理しているドメイン

ここではメール送信に利用していないものも含め、すべてのドメインを確認することをお薦めします。自社でメール送信に利用していなくとも、なりすましに悪用されてしまう恐れがあるからです。

●自社のメールを送信しているすべてのサーバー

ドメインごとに、実際にメール送信を行っているサーバーをリストアップします。主な例は以下の通りです。

• オンプレミス環境のメールサーバー
• WebアプリケーションサーバーやCMS（例：WordPress）からの通知メール
• Google WorkspaceやMicrosoft 365などのクラウドメールサービス
• 外部メール配信サービス

これらの情報をもとに、どのIPアドレスやドメインをSPFで許可すべきかが決まります。

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に設定する

SPFレコードは、ドメインのDNSゾーンにTXTレコードとして追加します。

DNSサービス（例：お名前.com、さくらのDNS、Cloudflare、Route 53 など）を利用している場合は、具体的な設定手順はサービスによって異なりますが、基本的な流れは以下の通りです。

1. 管理画面でドメインのDNS設定にアクセス

• 利用中のDNSサービスにログインし、対象のドメインを選択します。
• 「DNSレコード設定」や「レコードの編集」といったメニューに進みます。

2. TXTレコードを追加

項目	内容
レコードタイプ	TXT
ホスト名（名前）	空欄（ルートドメインの場合は何も入力しなくてOK）
値（内容）	v=spf1 ip4:203.0.113.1 include:_spf.example.com -all のようなSPFレコード

3. 保存・反映

• DNSの反映には最大で数分〜数時間かかる場合があります。
• 反映後、SPFチェックツールなどで正しく設定されたか確認します。

✅ 注意点

• 1つのドメインに複数のSPFレコード（v=spf1）を設定してはいけません。複数存在するとSPFチェックが必ず失敗（PermError）となります。
• SPFレコードの1行は255文字までという制限があり、超える場合は1つのTXTレコード内でクオートして継続記述する必要があります（複数のTXTレコードに分けるのはNGです）。

以下の記事でお名前.comとAmazon Route 53での設定手順を解説しているので、必要に応じてご参照ください。
お名前.comでSPF・DKIM・DMARCのDNSレコードを設定する | ベアメールブログ
Amazon Route 53でSPF・DKIM・DMARCのDNSレコードを設定する | ベアメールブログ

SPFレコード設定後の確認と注意点

SPFレコードをDNSに設定したあとは、必ず設定内容が正しく反映されているかを確認することが重要です。

設定ミスなどによりエラーが発生してしまうと、正当なメールが迷惑メールに分類されたり、受信拒否されたりする恐れがあります。

その前提として、SPFにはいくつか見落とされがちな仕様上の制限があります。確認作業を行う際にも密接に関係するため、先に注意点を整理しておきましょう。

SPFレコードの確認前に知っておきたい注意点

● SPFレコードは1ドメインに1つのみ

設定のところでも触れましたが、同じドメインに複数の v=spf1 レコードが存在すると、SPF認証は必ず失敗します（PermError）。すべての許可対象を1つのレコードにまとめる必要があります。

● DNSルックアップ回数の上限（10回）

SPFでは、includeや a、mx など一部のメカニズムがDNSルックアップを行います。1つのSPFレコードで参照できるルックアップは最大10回までと定められており（RFC 7208）、これを超えるとSPFが「permerror」となり、メールが拒否される恐れがあります。

ルックアップの上限に達しやすい状況としては以下が挙げられます。

• includeを多用している（例：複数の外部配信サービスを使用）
• a や mx の評価先が複雑な構成になっている
• includeの参照先にさらにincludeがある

DNSルックアップ回数制限について詳しくはこちらの記事で解説しています。
SPFのDNSルックアップの回数制限とは？ 確認方法や対策を解説 | ベアメールブログ

SPFレコードの確認方法

SPFレコードの設定内容を確認する方法としては、主に3つあります。構文エラーやDNSの反映漏れを防ぐだけでなく、SPFが実際に認証に使われているかどうかも検証することが重要です。

方法①：コマンドラインで確認（nslookup / dig）

DNSに設定されたTXTレコードが正しく公開されているかを確認する基本的な方法です。

⚫︎Windows（nslookup）

nslookup -type=TXT example.com

⚫︎macOS / Linux（dig）

dig TXT example.com

方法②：SPFチェックツールの活用

SPFレコードを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=pass：認証成功
• spf=fail：認証失敗（許可されていない送信元）
• spf=softfail：認証失敗だが強制拒否ではない（~all）
• spf=none：SPFレコードが存在しない
• spf=permerror：構文エラー、ルックアップ回数超過、複数レコードなど

まとめ

本稿では、SPFレコードの設定方法・記述例などについて解説してきました。メール到達率は、マーケティングや広報、顧客とのコミュニケーションの質に影響するため、きわめて重要な指標です。しかし、送信ドメイン認証が正しく機能していなければ、メール到達率は改善しません。メール到達率が思わしくない場合は、まずSPFレコードの設定を見直してみてはいかがでしょうか。