SPF とは — 送信元サーバーを認証してなりすましを防ぐ

SPF とは何ですか？

SPF（Sender Policy Framework）は、そのドメインのメールを送ってよいサーバーの IP を DNS の TXT レコードに列挙しておく仕組みです。受信サーバーはその一覧を引いて、実際の接続元 IP が許可されているかを照合します。差出人を確認する仕組みを持たない SMTP の欠陥を、DNS 側から後づけで補うのが役割です。

メール送信の規格（SMTP）には、差出人が本物かを確かめる仕組みが最初から入っていません。 メールサーバーに接続して「私は president@example.com です」と名乗れば、それがそのまま通ってしまいます。 SPF は、この欠陥を DNS 側から後づけで補うために作られた最初の仕組みです。

考え方は単純で、「このドメインのメールは、これらのサーバー（IP）からしか送られません」という宣言を、 ドメイン所有者が自分の DNS にあらかじめ書いておきます。受信側は届いたメールの接続元 IP をその一覧と突き合わせ、 載っていなければそのドメインを騙る偽物の可能性が高いと判断できます。宣言する場所が DNS なので、 正しい所有者だけが書けるという点が信頼の根拠になります。

SPF はどうやって検証されるのですか？

受信側はまず封筒の差出人（エンベロープ From / Return-Path）のドメインを取り出し、そのドメインの SPF レコードを DNS から引きます。そこに書かれた IP と、実際に接続してきたサーバーの IP を突き合わせ、一致すれば pass です。ここで見ているのは、画面に表示される From ヘッダーではない点が肝心です。

ここで最初に押さえたいのが、メールには差出人が 2 つあるという事実です。この区別が SPF の挙動をすべて決めます。

受信側の処理は次の順で進みます。まず封筒の差出人（エンベロープ From）のドメインを取り出し、そのドメインの SPF レコードを DNS から引きます。次に、そこに列挙された IP と実際に接続してきたサーバーの IPを突き合わせ、 一致すれば pass、末尾の all の指定に従って softfail や fail を返します。

SPF の書式とメカニズムはどうなっていますか？

SPF は v=spf1 で始まる 1 本の TXT レコードで、include・a・mx・ip4・ip6 といったメカニズムで許可する送信元を並べ、末尾の all でそれ以外の扱いを決めます。1 ドメインに SPF は 1 本だけで、v=spf1 の TXT が 2 本あると permerror になり、判定そのものが無効化されます。

; 送信するドメインの SPF レコード（TXT）
example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; v=spf1        SPF レコードであることの宣言（必須・先頭に置く）
; include:...   他ドメインの SPF をこの位置に取り込む（送信サービスごとに 1 つ）
; ~all          上のどれにも当てはまらない IP は softfail 扱い

; ★ SPF レコードは 1 ドメインに 1 本だけ。
;   "v=spf1" で始まる TXT が 2 本あると permerror になり、SPF 判定そのものが無効化される。

SPF は必ず v=spf1 で始まり、そのあとにメカニズムを左から順に並べます。受信側は接続元 IP が 最初に当てはまったメカニズムの修飾子を採用し、そこで評価を打ち切ります。主なメカニズムは次のとおりです。

; 複数の送信元をまとめた例
; include（外部サービス）、mx（自前メールサーバー）、ip4（固定 IP）を併用
example.com.  IN  TXT  "v=spf1 include:_spf.google.com mx ip4:203.0.113.10 ~all"

; include: 展開先の SPF に書かれた IP をすべて許可する
; mx:      example.com の MX が指すホストの IP を許可する
; ip4:     指定した IPv4 アドレス（範囲）を直接許可する

外部サービス（Google Workspace やメール配信サービス）は、送信元 IP が増減しても追従できるよう include で自社の SPF を配布します。利用者は指示された include: を 1 行足すだけで済み、IP の変更に振り回されずに済みます。 自前のメールサーバーがあるなら mx や ip4 で直接指定します。

修飾子と -all / ~all の違いは何ですか？

各メカニズムには修飾子が付き、+ が pass（既定）、- が fail（拒否してよい）、~ が softfail（疑わしいが通す）、? が neutral です。末尾は一覧外の IP をどう扱うかの宣言で、-all（拒否）か ~all（ソフトフェイル）が実務の選択肢です。DMARC と併用するなら ~all、メールを送らないドメインは -all を選びます。

各メカニズムの前には修飾子を付けられます。省略時は +（pass）です。実務でほぼすべての意味を持つのが、末尾の all に付ける修飾子です。

; 末尾の all 修飾子 — 一覧に載っていない IP から来たときどうするか
"v=spf1 include:_spf.google.com -all"   ; hardfail: 一覧外は拒否してよい（最も厳格）
"v=spf1 include:_spf.google.com ~all"   ; softfail: 疑わしいが受け取る（実務で最も多い）
"v=spf1 include:_spf.google.com ?all"   ; neutral: 判定しない = 対策になっていない
"v=spf1 include:_spf.google.com +all"   ; どこからでも許可。SPF が無いより悪い。書かない

-all（hardfail）は「一覧に無い IP は拒否してよい」という最も厳格な宣言、~all（softfail）は「疑わしいが通す」という 穏当な宣言です。DMARC と併用する場合は ~all で十分で、最終的な処遇は DMARC のポリシーが決めます。逆に?all は判定を放棄しており、+all はどこからでも許可してしまうため、書けばSPF が無いより危険です。

10 回ルックアップ制限とは何ですか？

SPF の評価で発生する DNS 問い合わせは 10 回までと決められており、include や a・mx を辿った合計がこれを超えると permerror となって SPF 全体が無効になります。include の先がさらに include していれば、それも合算されます。送信サービスを足していくうちに、ある日突然この上限を超えるのが典型的な事故です。

SPF の評価では、include・a・mx・redirect などが DNS 問い合わせを発生させます。RFC は、この問い合わせの合計を 10 回までに制限しています。11 回目に達した時点で permerror となり、SPF の判定そのものが無効になります。

厄介なのは、回数が入れ子で合算される点です。自分のレコードには include が 4 つしか無くても、 その先がさらに include していれば、展開された合計が上限を超えていることがあります。 つまり「送信サービスを足していったら、ある日突然 SPF が全部効かなくなる」という形で表面化します。

対策は、使っていない include を削る、複数サービスを 1 つの include に集約する、あるいは固定 IP を ip4 で 直接書いてルックアップを減らす、といった整理です。本ツールの診断でも、このルックアップ回数の超過を検出します。

なぜ転送されると SPF は失敗するのですか？

メールが転送されると、受信側から見た接続元 IP が転送サーバーのものに変わる一方、封筒の差出人は元のままだからです。その IP は元ドメインの SPF に載っていないため、正当なメールでも fail します。これは避けられない構造的弱点で、これを補うのが転送されても署名が残る DKIM と、両者を束ねる DMARC のアライメントです。

メーリングリストや .forward による転送では、メールがいったん転送サーバーを経由して届きます。このとき受信側から見た接続元 IP は転送サーバーのものに変わりますが、封筒の差出人は元のままです。 転送サーバーの IP は元ドメインの SPF に載っていないため、正当なメールなのに SPF が fail します。

これは設定ミスではなく、SPF が「接続元 IP」を見る以上避けられない構造的な弱点です。ここを埋めるのが、他の 2 つの仕組みです。

• DKIM — メール本文とヘッダーへの電子署名。転送されても署名は生き残るため、経路が変わっても検証できる（DKIM の解説）
• DMARC — SPF と DKIM のどちらか一方が通ればよい設計。転送で SPF が落ちても DKIM が救う（DMARC の解説）

だからこそ SPF・DKIM・DMARC は3 つ揃えて意味を持ちます。SPF 側を無理に -all にすると、この転送の失敗が そのまま拒否につながって届かなくなることがあるため、送信するドメインでは ~all にしておき、最終判断を DMARC に委ねるのが実用的です。

メールを送らないドメインはどう設定しますか？

メールを 1 通も送らないドメインには、v=spf1 -all だけを publish してください。これは「このドメインからのメールは 1 通も存在しない」という宣言で、受信側はそのドメインを騙るメールを安心して拒否できます。送信が無いので誤爆の心配が原理的に無く、段階導入も不要で、初日から最も厳格な設定を入れられます。

実務で最も多い誤解が「うちはこのドメインでメールを送っていないから SPF は関係ない」というものです。逆です。狙われるのは、まさにそういうドメインです。SPF も何も宣言していないドメインは、受信側にとって偽物と判定する根拠が一切無いため、第三者が名乗り放題になります。

; このドメインからメールは 1 通も送らない、という明示的な宣言
; コーポレートサイト専用ドメイン、リダイレクト用ドメイン、旧ブランドのドメインなど
example.com.  IN  TXT  "v=spf1 -all"

v=spf1 -all は「このドメインからのメールは 1 通も存在しない。だからどの IP から来ても拒否してよい」という宣言です。 送信が無いので誤爆の心配が原理的に存在せず、送信ドメインで必要な段階導入も不要で、初日から最も厳格な設定を入れられます。 リダイレクト用に取っただけの旧ドメインやキャンペーン用ドメインこそ、今すぐこれを入れる価値があります。

なお、なりすまし対策を完全にするには、SPF だけでなく DMARC も p=reject で入れ、受信を拒む場合は null MX（MX 0 .）も添えます。ドメイン全体の防御セットとしての進め方は SPF・DMARC でなりすましメールを防ぐ にまとめています。

SPF が正しく設定できているか確認するには？

dig コマンドで実際の TXT レコードを引くのが最も確実です。v=spf1 の TXT が 1 本だけあるか、末尾の all が意図どおりか、ルックアップ回数が 10 回以内かを確認します。管理画面上は正しく見えても実際には反映されていないことがあり、本ツールの診断でも SPF の実レコードと、その内容の妥当性まで判定します。

# v=spf1 の TXT が 1 本だけあるか
dig +short TXT example.com | grep spf1

# include の展開先も確認したいとき（例: Google の SPF）
# SPF はエンベロープ From のドメインに対して引かれる点に注意
dig +short TXT _spf.google.com

# メールを送らないドメインなら "v=spf1 -all" の 1 本だけが返るのが正しい
dig +short TXT example.com

確認のポイントは 3 つです。① v=spf1 の TXT が1 本だけあるか（2 本あると permerror）、② 末尾の all が意図どおりか（+all や ?all になっていないか）、③ 展開後の DNS ルックアップが10 回以内に収まっているか。

DNS の変更は即座には広まりません。TTL のぶんだけ古い値がキャッシュされ続けるので、変更直後に確認して 「反映されていない」と慌てないでください。作業前に TTL を短くしておくと楽になります。

本ツールの診断でも、SPF の実レコードと妥当性（1 本かどうか、+all のような効いていない設定、ルックアップ回数の超過）を判定します。 あわせて DMARC・DKIM・MX も確認できます。仕様の一次情報は RFC 7208（SPF） が正典です。