SPF(Sender Policy Framework)

よみ: エスピーエフ

メールの送信元が「本物」であることを証明し、なりすましを防ぐための認証技術です。ドメインのシステム(DNS)上に、「このサーバーからのメール送信を許可します」という名簿(SPF レコード)を公開し、受信側のサーバーがそれと照らし合わせて検証します。現在は「DKIM」「DMARC」という技術と合わせ、メール認証の 3 点セットとして扱われます。

なぜ必須なのか？（重要性）

近年、Gmail、Yahoo!、Microsoft などの迷惑メール対策が非常に厳格化しています。SPF が正しく設定されていないと、自社からの重要なメールが「なりすましの迷惑メール」と判定され、顧客に届かなくなるため、法人利用においては事実上の必須設定です。

記述例と設定のポイント

SPF レコードは、DNS に「TXT レコード」として、以下のような形式で記述します。

v=spf1 include:_spf.google.com include:amazonses.com ~all

全経路の網羅：普段使うメールソフト(Google Workspace 等)だけでなく、メルマガ配信システムや、業務 SaaS(Salesforce 等)など、「自社ドメインでメールを送るすべてのシステム」を含める(include する)必要があります。
末尾の設定：~all(条件外は疑わしい)と -all(条件外は完全に拒否)があり、本格運用時には、より安全な -all が推奨されます。

よくある落とし穴（現場での事故）

SaaS 追加時の更新忘れ：新しいメール配信システムを導入した際、SPF への追記を忘れてしまい、そのシステムからのメールがすべてスパム扱いになる。
1 ドメインに 1 レコードの原則：複数のシステムを使うからといって、SPF レコードを「複数行」設定してしまう(正しくは 1 つの行にまとめて記述しなければエラーになります)。
10 回の壁(DNS ルックアップ制限)：include で外部の仕組みを読み込む回数が「10 回」を超えると、検証エラーになってしまう。
設定したつもりで放置：SPF を設定しただけで満足し、より強固な DKIM や DMARC の設定を放置してしまう。

言葉をよく利用する人

インフラエンジニア
バックエンドエンジニア
情シス
Web 担当者(発注側)

会話上での使用例

メール配信サービスを導入してSPF設定を依頼された場面

バックエンドエンジニア
Resendを導入するので、SPFの設定をお願いできますか。
Web担当者
いまのレコードがGoogleのぶんだけなので、そこにamazonsesを追記する形になりますね。新しい送信元を足すときにSPF更新を忘れると、そのサービスのメールが全部届かなくなるので、変更前後の値はちゃんと記録しておきます。
バックエンドエンジニア
助かります。DNSの反映待ちもあるので、切り替え後に届くか一緒に確認しましょう。

一部の顧客にメールが届かないと相談された場面

カスタマーサポート
一部のお客様に、こちらからのメールが届いていないみたいなんです。
Web担当者
まずSPFとDKIMとDMARCの認証がちゃんと通っているか確認しますね。受信側のヘッダを見れば、どこで認証に失敗しているか特定できます。レコードの書き方とinclude漏れ、それとDNSの反映状況を順番に潰していきます。