SPFとは？メール認証の仕組み・SPFレコードの書き方と設定の判断基準を解説

メールの差出人アドレスは、技術的には簡単に詐称できてしまいます。取引先や自社を装ったなりすましメールを受信側で見抜く土台になるのが、SPF（Sender Policy Framework）を中心とした送信ドメイン認証です。この記事では、SPFがDNSのTXTレコードで送信元IPアドレスを検証する仕組み、v=spf1から始まるSPFレコードの書き方と主要メカニズム、10回のDNSルックアップ上限といった実務でつまずく箇所、そしてDKIM・DMARCと組み合わせる理由までを、設定を社内で内製するか外部に委託するかの判断とあわせて解説します。

まとめ：SPF設定で押さえる送信ドメイン認証の要点

SPFは、送信側ドメインの管理者がDNSに「このIPアドレスからのメールは正規のもの」と宣言し、受信側のメールサーバーがエンベロープFromのドメインと実際の送信元IPを突き合わせて正当性を確かめる仕組みです。RFC 7208で標準化された、なりすましメール対策の第一層にあたります。ただしSPF単体では、メール転送で認証が壊れる、受信者が実際に目にするヘッダFromの詐称は防げない、といった穴が残ります。

実務での結論はシンプルにまとまります。SPF・DKIM・DMARCの三点をセットで導入し、SPFレコードのDNSルックアップは10回以内に収め、最終的な運用ポリシーはDMARCで宣言する——この形が現在の到達点です。自社の送信経路が複数のSaaSに分散し、SPFレコードの管理が破綻しかけているなら、DNSとメールインフラの設計を外部の開発会社に委ねる判断も現実的な選択肢になります。以下で仕組み・設定・判断基準を順に見ていきます。

SPFの仕組みとメール送信元を検証する送信ドメイン認証の役割

まずSPFが何を検証し、何を検証しないのかをはっきりさせます。ここを取り違えると、後述の「SPFを設定したのになりすましが届く」という誤解につながります。

DNSのTXTレコードに登録した送信元IPで正当性を検証する流れ

SPFの動作は3ステップです。送信側ドメインの管理者が、自ドメインのDNSに「正規の送信元IPアドレスの一覧」をTXTレコードとして公開する。メールを受け取った受信側のメールサーバー（MTA）が、そのドメインのSPFレコードをDNSに問い合わせる。実際にメールを届けてきたサーバーのIPアドレスが一覧に含まれていればpass、含まれていなければfailと判定する。この判定結果は受信側のスパム判定やDMARCの評価材料になります。SPFはメール本文を一切見ず、あくまで「どのサーバーから来たか」だけを照合する点が特徴です。

エンベロープFromとヘッダFromの違いとSPFが照合する宛先

メールには2種類の差出人があります。SMTPの通信中にやり取りされるエンベロープFrom（Return-Path）と、メールソフトの画面に表示されるヘッダFromです。SPFが照合するのは前者、エンベロープFromのドメインだけです。ここが実務上の落とし穴になります。攻撃者はエンベロープFromに自分が管理する正規ドメインを使ってSPFをpassさせつつ、ヘッダFromには有名企業のアドレスを詐称できます。受信者が目にするのはヘッダFromのほうです。SPFだけでは「表示上のなりすまし」を止めきれない構造的な理由がここにあります。

SPF・DKIM・DMARCの三層で構成する送信ドメイン認証の全体像

この弱点を補うため、送信ドメイン認証は3つの技術を層にして使います。SPFがIPアドレスの正当性を、DKIMが電子署名でメールの改ざん有無と発信元を、DMARCがそのSPF・DKIMの結果とヘッダFromの整合（アライメント）を検査し、認証に失敗したメールの扱い方を宣言します。3つの役割分担を整理すると次の通りです。

SPFは三層の入口であり、これ単独で完結する対策ではありません。DKIMの署名検証は別途詳しく整理します。DMARCの設定手順まで踏み込みたい場合は、DMARCとは？その仕組みと設定方法、SPFやDKIMとの関係で全体像を確認してください。

SPFレコードの基本構文と主要メカニズムの意味と設定確認手順

仕組みが分かったら、実際のSPFレコードの読み書きに移ります。構文は短く、覚えるべき要素も限られています。

v=spf1で始まるSPFレコードの基本構文とall修飾子の使い分け

SPFレコードはDNSのTXTレコードとして1行で書き、必ずv=spf1から始めます。末尾にはallメカニズムを置き、一覧に該当しない送信元をどう扱うかを修飾子で指定します。-allは「一覧外は拒否（hardfail）」、~allは「一覧外は疑わしいが受信は許容（softfail）」、?allは「判定しない（neutral）」の意味です。1つの文字列は255文字までという制約もあり、送信元が多いと分割や参照でまとめる必要が出てきます。運用開始直後は~allで様子を見て、正規メールの取りこぼしがないと確認できてから-allへ絞り込むのが定石です。

includeやa・mxなどDNSルックアップを伴うメカニズムの役割

SPFレコードの中身は「メカニズム」の組み合わせで表現します。よく使うのは、IPアドレスを直接指定するip4・ip6、別ドメインのSPFレコードを取り込むinclude、自ドメインのAレコードやMXレコードを参照するa・mxです。Google WorkspaceやMicrosoft 365、メール配信サービスを使う場合は、各社が案内するincludeを並べる形が基本形になります。ここで注意すべきは、include・a・mxなどは受信側でDNSへの問い合わせを発生させる点で、この回数に後述の上限がかかります。

SPFレコードをDNSに公開する設定手順とnslookupでの確認

設定の流れは次の順序で進めます。

1. 自ドメインからメールを送る全経路（自社サーバー、Google Workspace、配信サービス等）を洗い出す
2. 各経路の指定に沿ってv=spf1から始まるSPFレコードを1本組み立てる
3. DNSの管理画面でTXTレコードとして登録し、反映を待つ
4. コマンドやチェックサイトでレコードが引けるか、意図通りにpassするかを確かめる

公開後の確認にはnslookupコマンドでTXTレコードを引くか、無料のSPFチェックツールを使います。反映にはDNSのキャッシュ有効期間（TTL）ぶんの時間差が出るため、変更直後に旧レコードが返ることも珍しくありません。SPFレコードは1ドメインにつき1本が原則で、複数のTXTレコードにSPFを分けて書くとPermErrorになる点にも気をつけてください。

SPF単体で防げない範囲とDKIM・DMARCを組み合わせる理由

SPFの限界を正しく把握しておくと、なぜ三層セットが標準になっているのかが腑に落ちます。順位を分ける実務知識はここに集まっています。

メール転送でSPF認証が壊れる仕組みとDMARCで補う回避策

SPFが最もつまずくのが「転送」です。利用者がメールを別アドレスへ自動転送すると、転送サーバーが新たな送信元IPになります。エンベロープFromのドメインは元のままなのに送信元IPだけが入れ替わるため、元ドメインのSPFレコードには載っておらずfailになります。正規メールなのに転送を経ると認証に落ちる、これがSPFの構造的な弱点です。回避策はSPFの中では完結せず、転送後も生き残るDKIM署名と、SPFかDKIMのどちらか一方が通れば認証成立とみなすDMARCの評価で補います。この事実こそ、SPFを単独運用しない最大の理由です。

10回のDNSルックアップ上限とPermErrorを避ける設計

RFC 7208は、受信側が1回のSPF評価で行えるDNSルックアップを最大10回までと定めています。includeやa、mxといったメカニズムが1回ずつDNS問い合わせを消費し、include先がさらにincludeを抱えていれば入れ子で加算されていきます。11回目に達するとSPF評価はPermErrorとなり、そのメールはSPF的に無効と扱われてしまう。SaaSを複数includeする構成では、気づかぬうちに上限へ近づく事故が起きがちです。設計段階では、使っていないincludeを削る、送信を主要経路へ集約する、専用のフラット化ツールでルックアップ回数を可視化する、といった手当てで10回以内に収めておきます。

なりすましの完全防止にDMARCのアライメント判定が要る理由

先に触れた通り、SPFはエンベロープFromしか見ないため、受信者が目にするヘッダFromの詐称を単独では止められません。ここを塞ぐのがDMARCのアライメント判定です。DMARCは、SPFがpassしたドメインとヘッダFromのドメインが一致しているか（identifier alignment）まで検査し、一致しなければ認証失敗とみなして拒否や隔離を指示します。フィッシングメールの多くは有名ブランドのヘッダFromを詐称するため、フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策で扱うような組織的対策と、DMARCによる表示ドメインの保護は表裏一体で機能します。

SPF設定を社内で内製すべきか業者へ委託すべきかの損益分岐点

ここからは判断を言い切ります。SPFの設定自体はTXTレコードを1本書くだけで、単純構成なら情シス担当者が自力で完結できます。問題は「単純構成に収まっているか」です。

-allと~allのどちらを採用すべきかを判断する運用上の条件

採用条件は明確です。送信経路を完全に洗い出せていて、レポートで取りこぼしゼロを確認済みなら-allで締める。少しでも把握しきれない送信元が残るなら、無理に-allにせず~allで運用しながらDMARCのレポートで実態を集めるべきです。最も多い失敗パターンは、送信経路の棚卸しを終えないまま最初から-allを設定し、請求書メールや予約通知など業務上重要なメールが受信側で弾かれる事故です。この場面では-allは見送り、可視化を優先します。判断材料が揃うまでは緩めに運用する、これが安全側の選択です。

SaaS乱立でincludeが膨張する組織が委託を選ぶ分岐点

内製で回るのは、送信ドメインが少数で、送信元が1〜2のサービスに収まり、DNSを管理できる担当者がいる場合に限られます。逆に、部門ごとに配信ツールやマーケティングSaaSを導入してincludeが膨れ、10回のルックアップ上限に触れ始めた組織は、すでに内製の限界を超えています。DNSゾーンの再設計、送信経路の集約、SPFとDKIMとDMARCの一貫した設計は、メールインフラ全体を俯瞰しなければ片手間では破綻するでしょう。こうした段階に来たら、DNSやメールサーバーを含むインフラ構築（AWS・Google Cloud・Azure）の設計から外部の開発会社に委ねる判断が、事故対応の総コストを下回る分岐点になります。境目の目安は、送信SaaSが5つを超え、担当が実質1名という状態です。

よくある質問

SPFの設定・運用で実際に検索されることの多い疑問に、実務の観点から答えます。

SPFレコードは1つのドメインに複数設定できますか？

いいえ、1ドメインにつきSPFのTXTレコードは1本だけにします。複数のSPFレコードを別々に登録すると、受信側の評価がPermErrorになり、かえって認証が無効化されます。複数のサービスから送信する場合は、1本のレコードの中にincludeを並べて記述してください。

SPFを設定すればなりすましメールは完全に防げますか？

防げません。SPFはエンベロープFromの送信元IPを照合するだけで、受信者が見るヘッダFromの詐称や、転送経由のなりすましには単独では対処できません。ヘッダFromを保護するにはDMARC、改ざん検知にはDKIMが必要で、三点をセットで運用してはじめて実用的な精度になります。

SPFレコードの反映にはどのくらい時間がかかりますか？

DNSのTTL（キャッシュ有効期間）に依存し、数分から長い場合は24〜48時間ほどかかります。反映前は受信側に旧レコードが残るため、変更直後の検証で意図と違う結果が出ても、TTLの経過を待ってから再確認するのが確実です。

~allと-allは結局どちらで運用するのが安全ですか？

送信経路を完全に把握できるまでは~all（softfail）で運用し、DMARCのレポートで取りこぼしがないと確認できてから-all（hardfail）へ移行する順序が安全です。いきなり-allにすると正規メールが弾かれる事故が起きやすくなります。

SPFの設定や運用を外部の開発会社に依頼できますか？

依頼できます。送信経路が複数SaaSに分散していたり、DNSルックアップの上限に触れていたりする場合は、DNSとメールインフラの設計ごと委託するほうが確実です。一創ではSPF・DKIM・DMARCを含むメール認証基盤の設計や、クラウド上のインフラ構築の相談を受け付けています。

関連記事

• DMARCとは？その仕組みと設定方法、SPFやDKIMとの関係：SPFの上位に立つDMARCの設定を詳しく知りたい方へ。
• フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策：SPF/DMARCが守ろうとするなりすましメールの手口側を解説。
• スパムとは？迷惑メール・SMS・SNSの手口と企業が取るべき対策：送信ドメイン認証がスパム判定に効く背景を整理。
• VPNとは？仕組み・種類・メリットとデメリット、企業導入の判断基準：ネットワークセキュリティ基礎の親記事。