メールセキュリティ

SPF（Sender Policy Framework）えすぴーえふ（せんだーぽりしーふれーむわーく）

メール認証なりすまし対策DNSレコードDMARCDKIM迷惑メール

SPFについて教えて

簡単に言うとこんな感じ！

SPFは「このドメインからメールを送っていいサーバーはここだよ」ってあらかじめ登録しておく仕組みだよ。受け取った側がその登録リストを見て「本物かどうか」を確認できるから、なりすましメールを弾けるってこと！

SPFとは

SPF（Sender Policy Framework） は、メールの送信元ドメインが「正規のサーバーから送られたものかどうか」を受信側が検証するためのメール認証技術です。具体的には、ドメインの管理者が「このドメインのメールを送信してよいサーバーのIPアドレス一覧」を DNSレコード に登録しておき、メールを受け取ったサーバーがそのリストと照合することでなりすましを検知します。

たとえば、攻撃者が example.com を騙って偽メールを送ろうとしても、example.com のDNSに登録されていないサーバーから送信されていれば「SPF認証失敗」となり、受信側で迷惑メールと判定したり、拒否したりできます。これにより、フィッシング詐欺や標的型攻撃メールのリスクを大幅に低減できます。

SPF単体でもなりすまし対策に有効ですが、DKIM（電子署名による改ざん検知）や DMARC（SPF・DKIMの結果をポリシーとして運用する仕組み）と組み合わせることで、より強固なメールセキュリティを実現できます。現代のビジネスメール環境では、SPFの設定は事実上の必須要件になっています。

SPFの仕組みと構造

SPFは DNS（ドメインネームシステム） を使って動作します。送信ドメイン管理者が「TXTレコード」という形式でSPF情報を公開し、受信サーバーがそれを参照します。

メール送受信の流れ

ステップ	実施者	内容
① SPFレコード登録	送信ドメイン管理者	DNSのTXTレコードに許可サーバーを記載
② メール送信	送信サーバー	`example.com` 宛にメールを送る
③ SPFレコード取得	受信サーバー	送信元ドメインのDNSにSPFレコードを問い合わせ
④ IPアドレス照合	受信サーバー	実際の送信元IPがレコードに含まれるか確認
⑤ 結果判定	受信サーバー	Pass / Fail / SoftFail などを判定して処理

SPFレコードの書き方（例）

v=spf1 ip4:203.0.113.10 include:spf.example-mailer.com -all

要素	意味
`v=spf1`	SPFバージョン1を使用（必須）
`ip4:203.0.113.10`	このIPアドレスからの送信を許可
`include:spf.example-mailer.com`	外部サービスのSPFレコードも引用して許可
`-all`	上記以外はすべて拒否（ハードフェイル）

SPF認証結果の種類

結果	記号	意味
Pass	`+`	認証成功。正規の送信元
Fail	`-`	認証失敗。なりすましの可能性が高い
SoftFail	`~`	認証失敗だが、完全拒否はしない（移行期などに使う）
Neutral	`?`	ポリシーなし。判定しない
None	—	SPFレコードが存在しない
TempError	—	DNS一時エラーで判定不能
PermError	—	SPFレコードに構文エラーがある

覚え方・語呂合わせ

「SPF＝日焼け止め」 と覚えよう！
肌を守る日焼け止め（SPF30、SPF50…）と同じ略語。メールを「なりすましの紫外線」から守るのがSPFだよ！

歴史と背景

2000年代初頭 — 迷惑メール（スパム）やフィッシング詐欺が急増。送信元を偽るメールが社会問題化
2003年 — Meng Weng Wong氏らがSPFの原型となる「Sender Permitted From」を提案
2004年 — IETFで実験的RFCとして議論が開始（RFC 4408）
2006年 — RFC 4408 が発行され、SPFが標準化の道へ
2014年 — RFC 7208 が発行され、SPFの正式な標準仕様として確立。現在もこれが有効
2015年以降 — GmailやMicrosoft 365などの主要メールサービスがSPF確認を標準で実施
2022年 — GoogleとYahoo!がメール送信者向けガイドラインでSPF設定を事実上の必須要件に指定
2024年 — 日本国内でも大手キャリアや企業のメールシステムでSPF+DMARC対応が加速

SPF・DKIM・DMARCの関係

メールセキュリティの3つの柱として、SPF・DKIM・DMARCはセットで語られます。それぞれが異なる角度からなりすましを防ぎます。

SPFだけでは防げないケース

ケース	SPFの限界	対策
メール転送	転送サーバーのIPになりSPF失敗しやすい	DKIMを併用する
ヘッダーFromの偽装	SPFはEnvelope-Fromを見るのでヘッダーFromは別	DMARCでアライメント確認
本文の改ざん	内容の検証はSPFの範囲外	DKIMで署名する

規格・RFC番号	内容
RFC 7208	SPFの現行標準仕様（2014年策定）
RFC 4408	SPFの初期実験的仕様（RFC 7208に置き換え）
RFC 6376	DKIM（DomainKeys Identified Mail）の標準仕様
RFC 7489	DMARC（Domain-based Message Authentication）の仕様
RFC 5321	SMTP（メール転送プロトコル）の標準仕様