SPF（Sender Policy Framework）とは何ですか？どのような仕組みでなりすましを防ぎますか？

SPF（RFC 7208）は、DNSを利用してメール送信元サーバーの正当性を検証するインターネット標準プロトコルです。ドメイン管理者は正規の送信元IPアドレスやサーバー群をTXTレコードとして公開します。受信側MTAはSMTP接続時にエンベロープFrom（RFC 5321 Return-Path）のドメインのSPFレコードを取得し、接続元IPが含まれているか照合します。未許可IPからの接続は詐称・なりすましメールとして拒否または隔離されます。

SoftFail (~all) と HardFail (-all) の実際の違いと使い分けは何ですか？

両者は未承認IPからメールが届いた場合の受信側への推奨アクションを指定します。'-all' (HardFail) は不正メールをSMTPハンドシェイク段階で即時拒絶（Reject）するよう要求します。一方 '~all' (SoftFail) はメールを受信した上で不審フラグ付与や迷惑メールフォルダへの隔離を推奨します。転送メールによる誤判定リスクを避けるため、現代のDMARC運用環境では'~all'の採用が主流となっています。

なぜDNSルックアップ10回制限は厳格に適用されるのですか？

DNSサーバーに対するDoS攻撃やリフレクション攻撃（DNSアンプ攻撃）を防ぐためのセキュリティ仕様です。ルックアップ制限がない場合、攻撃者が多数の外部ドメインを再帰的に参照する悪意あるSPFレコードを作成し、受信サーバーに膨大なDNSトラフィックを発生させることが可能になってしまいます。そのため11回目のDNSクエリが発生した瞬間に強制的にPermErrorとなります。

SPFはメールソフトに表示される『差出人（From）』のアドレスを検証しますか？

いいえ。SPFが検証するのはSMTP通信時に使われるエンベロープ送信者（RFC 5321 Return-Path / MAIL FROM）のみであり、ユーザーが目にするヘッダーFrom（RFC 5322 From）は直接検証しません。そのため、エンベロープを自社ドメインにしてヘッダーFromを有名ブランドに偽装する攻撃はSPF単体では防げません。これを解決するために、ヘッダーFromとSPF/DKIMの一致を強制するDMARC（RFC 7489）の導入が必須です。

サブドメインにもSPFレコードは必要ですか？親ドメインのSPFは継承されますか？

サブドメインは親ドメインのSPFレコードを自動継承しません。RFC 7208では、メールのReturn-Pathに記載された完全修飾ドメイン名（FQDN）に対して厳密にSPFルックアップを行います。例えば 'notify@mail.example.com' から送信する場合、'mail.example.com' のTXTレコードが検索されます。親ドメインにSPFがあってもサブドメインに未設定であれば 'None' 判定となるため、送信元として利用するサブドメインには個別のSPFレコードを設定する必要があります。

DNS SPF レコードビルダー＆解説技術者ガイド

ドメイン名 (FQDN)

終端ポリシークオリファイア (all)SoftFail (~all): 未承認を不審としてマーク (DMARC運用推奨)

DNSクエリメカニズム (a, mx, include, exists)

mxドメインのMXメールサーバーを認可 (mx メカニズム)

aドメインのAレコードを認可 (a メカニズム)

ptr (ptrメカニズム (RFC 7208非推奨 - 使用不可))Discouraged by RFC 7208

主要メール送信サービスプロバイダー主要メール＆SaaSプリセット

認可サードパーティ (include:)

include:_spf.google.cominclude:sendgrid.net

認可IPv4アドレス・CIDR範囲 (ip4:)

ip4:198.51.100.24/32

認可IPv6アドレス・CIDR範囲 (ip6:)

Mechanisms: 6DNS参照数: 3 / 10

Length: 80 / 255 文字数:グレード A+

DNS TXTレコード値

80 chars

v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all

DNSレコードパラメータ

レコードタイプ (TXT)TXT

ホスト名 / サブドメイン (ネイキッドは @)@ (または mycompany.io)

TTL (有効期間 / 秒)3600 (1時間を推奨)

BINDゾーン構文

; RFC 7208 SPF TXT Resource Record for mycompany.io
; Host/Name: @ (or mycompany.io.)
; Record Type: TXT
; TTL: 3600 seconds ({t.lbl1HourRecommended || "1 hour recommended"})

mycompany.io.    IN    TXT    "v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all"

; --- Cloudflare DNS API / Web Dashboard ---
; Type: TXT
; Name: @
; Content: v=spf1 mx ip4:198.51.100.24/32 include:_spf.google.com include:sendgrid.net ~all
; TTL: Auto (or 3600)
; Proxy status: DNS only

Policy:~all

Lookups: 3 / 10 Ready

DNS SPFレコード生成＆構文解析ツール

完全ブラウザ内処理＆プライバシー保護

RFC 7208標準準拠＆10回ルックアップ上限検査

主要SaaSプリセット・BIND・CLI検証コマンド

DNS SPF (Sender Policy Framework) レコードビルダー＆解説技術者ガイド — リファレンスガイド

主要パラメータ＆設定項目

プロの活用テクニック＆推奨設定

RFC 7208第4.6.4項により

同一ドメインにSPFレコード（v=spf1）を絶対に複数公開しない

DMARCの最適化

'ptr' メカニズムを廃止し、危険な '+all' を絶対に設定しない

よくあるトラブルと解決策

受信側サーバーから '550 5.7.23 SPF PermError: too many DNS lookups' でメールが拒絶される

DNS検証ツールで 'SPF PermError: duplicate SPF records found' と警告される

転送メールやメーリングリスト経由の正規送信メールが宛先でSPF認証エラー（SoftFail）になる

よくある質問 (FAQ)

関連するおすすめ開発ツール