SPFメール認証設定方法中小企業

SPFレコードの設定方法｜書き方と確認の手順

2026年4月19日ドメイン番人約 6 分で読めます

この記事でわかること

SPFレコードの構文と、include・~all・-all の意味
Google Workspace や Microsoft 365 などサービス別の具体的な設定値
設定の反映確認方法と、10ルックアップ上限でつまずかないためのチェック

「メールが急に届かなくなった」「Gmail側で迷惑メール扱いされるようになった」というご相談の多くは、SPFレコード（エスピーエフ、Sender Policy Framework）の設定ミスが原因です。SPFはDNSにTXTレコードを1行追加するだけの仕組みですが、構文と上限の理解を飛ばして書くと、かえって配信性を落としてしまいます。本記事では、SPFレコードの書き方と設定手順を、実際に使われている値の例とともに順に整理します。SPF・DKIM・DMARCの3つの位置づけから見直したい方は、先にSPF・DKIM・DMARCの違いをわかりやすく解説をご一読ください。

SPFレコードの構文と書き方

SPFレコードは、ドメイン直下（@）に1つだけ公開するTXTレコードで、値は v=spf1 で始まり、末尾の all 修飾子で終わるのが基本形です。

SPFレコードの構成要素

値の中身は、左から順に「この送信元を許可する」という機構（mechanism）を並べ、最後に「それ以外をどう扱うか」を決める修飾子を置きます。主な機構は次のとおりです。

機構	役割	DNSルックアップ
`ip4:` / `ip6:`	IPアドレスや範囲を直接列挙	消費しない
`a` / `mx`	ドメインのAレコード・MXサーバーを許可	それぞれ1回消費
`include:<domain>`	他ドメインのSPFを取り込み	1回＋取り込み先の消費分
`exists:<domain>`	指定ドメインが解決できれば許可	1回消費
`redirect=<domain>`	評価を別ドメインのSPFへ委ねる	1回＋委譲先の消費分

末尾の修飾子は運用段階で使い分けます。新規に公開するときや既存メールフローの全容を把握できていない段階では、いきなり -all（hardfail）にせず、まずは ~all（softfail）で始めるのが安全です。Googleも自社Workspace向けの例として ~all を案内しています（Set up SPF｜Google Workspace Help）。構文と上限はRFC 7208に定められています（RFC 7208｜Sender Policy Framework）。

補足として、1つのドメインにSPFレコードを2行以上書くとPermErrorとなり、SPF評価が丸ごと失敗します（RFC 7208 §3.2）。既存レコードがある状態で新しいサービスを足すときは、必ず1行に統合してください。

サービス別の設定例

利用しているメール送信サービスごとに、include: で指定すべきホスト名は決まっています。推測で書かず、各サービスの公式ドキュメントに従ってください。

サービス	include に書くホスト名	備考
Google Workspace	`_spf.google.com`	推奨末尾は `~all`（公式ヘルプの例）
Microsoft 365（Exchange Online）	`spf.protection.outlook.com`	公式は `-all` を例示
Resend	`_spf.resend.com`	送信用サブドメイン側に設定するケースもあり
さくらインターネット	`spf.sakura.ne.jp`	契約プランで変わる場合あり

Google Workspaceのみを使う場合

ホスト名: @
種別: TXT
値: v=spf1 include:_spf.google.com ~all

Microsoft 365のみを使う場合

ホスト名: @
種別: TXT
値: v=spf1 include:spf.protection.outlook.com -all

Google WorkspaceとResendを併用する場合

ホスト名: @
種別: TXT
値: v=spf1 include:_spf.google.com include:_spf.resend.com ~all

複数サービスを組み合わせるときの考え方は、「どのサーバーから何のメールが出ているか」を洗い出すところから始めます。会計システムの通知、マーケティングツール、CRMからの自動送信など、普段意識していない送信元が漏れやすいので、社内ヒアリングと送信ログの確認をセットにしてください。

設定手順と反映確認

SPFレコードの設定は、DNS管理画面にログインできれば15分程度で完了します。

SPFの受信側判定フロー

ステップ1｜現状のSPFを確認する

まず既存のSPFレコードがあるかを確認します。お使いのPCで次のコマンドを実行します。

nslookup -type=txt example.co.jp

v=spf1 ... で始まる行があれば、その1行だけを編集対象にします。2行以上見つかった場合は統合が必要です。

ステップ2｜DNSにTXTレコードを追加または編集する

Cloudflare、お名前.com、Xserverなど、ご利用のDNS管理画面でTXTレコードを追加または編集します。既存レコードに新しいサービスを足す場合は include: をスペース区切りで追記します。

ステップ3｜反映を待つ（通常数分から数時間）

DNSの変更はTTLに従ってキャッシュが切れたあとに反映されます。通常は数分から数時間、長くても48時間以内には世界中から引けるようになります。

ステップ4｜送信テストと判定結果の確認

Gmail宛てにテスト送信し、受信したメールの「メッセージのソース」を表示すると、ヘッダーに spf=pass (...) のような行が見えます。ここが pass になっていれば設定成功です。softfail や fail のときは、送信元IPがSPFに含まれていないか、構文エラーが考えられます。

10ルックアップ上限とよくあるつまずき

SPF運用で最も多いトラブルは、DNSルックアップが上限の10回を超えてPermErrorになるケースです。RFC 7208 §4.6.4は、1回のSPF評価で消費できるDNSルックアップを10回以内に制限しており、超過した瞬間にSPF全体が無効化されます。

10ルックアップ上限の数え方

数え方で気をつけるべきは、include: した先のレコードが内部でさらに include を持っていると、その分も合算される点です。_spf.google.com のように1つのincludeが内部で4つ以上消費するケースもあり、メール送信サービスを3〜4種類束ねるとすぐに上限に届きます。加えてRFC 7208 §4.6.4は、NXDOMAINや空回答となる「void lookup」が2回を超えた場合もPermErrorとすると規定しています。

上限に近づいたときの対処は、次の順で検討します。

使っていないサービスの include: を削除する
小規模な送信元は include: の代わりに ip4: で直接列挙する
それでも収まらなければSPF flattening（動的にip4へ展開するサービス）の利用を検討する

もうひとつ頻出するのが、SPFだけに頼ってなりすまし対策ができたつもりになる誤解です。SPFは転送やメーリングリストで失敗しやすく、From欄のドメインとの一致（アラインメント）も保証しません。同じドメインから送られる正規メールでも迷惑メール扱いされることが増えてきたら、DKIMとDMARCまで整える段階に入っています。具体的な手順はDMARC設定方法を徹底解説にまとめています。

まずは自社のSPFを確認しましょう

要点を整理します。

SPFは1ドメイン1レコード、v=spf1 ... ~all（または -all）の形で公開する
利用中の送信サービスをすべて include: で列挙し、公式のホスト名を使う
DNSルックアップは合計10回まで。超えるとSPF全体がPermErrorで失敗する
運用開始時は ~all で様子を見て、送信源が固まってから -all への切り替えを検討する

無料のドメイン診断ツールで、自社ドメインのSPFレコードの有無・内容・ルックアップ数をまとめて確認できます。設定の書き換えに不安がある方は、お問い合わせフォームから現状をお知らせください。専門家が内容を確認したうえで、手順と反映タイミングをお伝えします。