SPF (Sender Policy Framework) は、「このドメインを名乗るメールは、どの IP アドレスのサーバから送ってよいか」 をドメイン所有者が DNS の TXT レコードで宣言し、受信サーバが実際の送信元 IP と突き合わせてなりすましを検出する仕組み。SMTP には本来「差出人が本物か」を確かめる仕組みが無く、誰でも MAIL FROM: ceo@example.com を名乗れてしまう。SPF はその穴を DNS で塞ぐ、メール認証の最も基本的な一枚目。DKIM・DMARC と組み合わせて初めて実効的な防御になる。
SPF が解く問題 — SMTP はなりすまし放題 #
SMTP (RFC 5321) は 1980 年代の「性善説」設計で、送信者が名乗るアドレスを検証しない。攻撃者は自分のサーバから、差出人を銀行や取引先に偽装したメールをそのまま送れる。これがフィッシング・BEC (ビジネスメール詐欺) の土台になる。
メールには From が 2 つある。Envelope From (MAIL FROM / Return-Path) は配送制御に使う「封筒の差出人」で、SPF が検証するのはこちら。一方 Header From (差出人:) は受信者の画面に表示される「便箋の差出人」。この 2 つは食い違わせられるため、SPF だけでは表示名のなりすましを完全には防げない (→ §04 の DMARC で整合性を縛る)。
- SPF が守るもの — Envelope From ドメインの「送信元 IP」の正当性
- SPF が守らないもの — メール本文の改ざん (→ DKIM)、Header From の偽装 (→ DMARC)
SPF レコードの構文 #
SPF は専用のレコード型を持たず、ドメイン直下の TXT レコードとして 1 つだけ公開する。v=spf1 で始まり、左から右へ メカニズムを評価していき、最初に一致したものの結果を採用する。
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all"| メカニズム | 意味 |
|---|---|
ip4:192.0.2.0/24 | この IPv4 範囲からの送信を許可 |
ip6:2001:db8::/32 | IPv6 範囲を許可 |
a / mx | ドメインの A / MX レコードの IP を許可 |
include:_spf.google.com | 別ドメインの SPF を取り込む (SaaS 利用時の定番) |
all | 「その他すべて」。必ず末尾に置く最終ルール |
各メカニズムの頭には クォリファイアを付けられる (省略時は +)。一致したときにどう判定するかを決める。
+Pass (許可) — 既定-Fail (拒否) —-allで「リストにない IP は拒否」~SoftFail (やや拒否) —~allは「怪しいが受け取る」。導入初期に使う?Neutral (中立) — 判定しない
SPF 評価中に発生する DNS 問い合わせ (include / a / mx など) は 合計 10 回を超えると PermError になり、SPF が機能しなくなる。SaaS を多数 include していると簡単に超過するため、不要な include を削るのが運用の要点。
判定の流れ — 自分で試す #
受信サーバは、(1) Envelope From のドメインの SPF レコードを DNS で引き、(2) 接続してきた IP を左から順にメカニズムへ照合し、(3) 最初に一致したクォリファイアを結果とする。下のシミュレータで SPF レコードと送信元 IP を自由に設定し、ip4 範囲や include、-all / ~all で判定がどう変わるかを確かめてみよう。
例えば ~all を -all に変え、範囲外の IP を入れると SoftFail → Fail に変わる。include:_spf.example.net は別レコード (v=spf1 ip4:198.51.100.0/24 -all) を取り込むので、198.51.100.x も Pass になる。
SPF の限界と DKIM・DMARC #
SPF だけでは守りきれない穴がある。転送 (forwarding) されると送信元 IP が転送サーバに変わり SPF は壊れる。また SPF は Header From を見ないため、Envelope From を自分の正規ドメインにしつつ Header From を偽装する手口を素通ししてしまう。
SPF + DKIM + DMARC をすべて設定し、DMARC を p=reject まで上げて初めて「自ドメインを騙るメールを受信側に拒否させる」状態になる。メールを送らないドメインなら Null MX + v=spf1 -all + p=reject でなりすましの土台を完全に塞げる。
運用のベストプラクティス #
- TXT は 1 ドメイン 1 つだけ — SPF レコードを複数公開すると
PermError。統合する - 導入は
~allから — まず SoftFail で様子を見て、DMARC レポートで正規送信元を洗い出してから-allへ - include は最小限に — 10 ルックアップ制限を超えないよう、使っていない SaaS の include を削る
- DKIM・DMARC と必ず併用 — SPF 単体は転送と Header From 偽装に弱い
dig TXT example.comで公開済みのレコードを確認できる
