SPFとは？ 10分でわかりやすく解説

取引先にファイルを送ろうとしたら「添付容量オーバー」で弾かれてしまった——そんな経験がある方も多いはずです。容量問題の陰に隠れがちですが、メール運用でもう一つ厄介なのが「なりすまし」です。この記事では、送信ドメインの正当性を受信側で判定する仕組みであるSPF（Sender Policy Framework）を、導入判断と運用の観点まで含めてわかりやすく整理します。

SPFの基礎知識

SPFとは何か

SPF（Sender Policy Framework）とは、メールを送ってきたサーバーの送信元IPアドレスが、送信ドメインの管理者により「送信を許可された範囲かどうか」を検証する仕組みです。送信側ドメインの管理者がDNSにSPFレコード（TXTレコード）を公開し、受信側メールサーバーがその内容を参照して判定します。

重要なのは、SPFが認証するのは主にエンベロープFrom（Return-Path）やHELO/EHLOに関するドメインであり、メールソフトに表示されるヘッダーFrom（差出人表示）そのものを直接保証する仕組みではない点です。差出人表示の“なりすまし”対策としての確度を上げるには、DKIMやDMARCと組み合わせてドメインの整合（アライメント）まで確認できる形にするのが一般的です。

SPFでできること・できないこと

• できること：「このドメインを名乗って送信してよい送信元（IP・送信サービス）を限定する」
• できないこと：メール本文の安全性（マルウェア有無）の保証、表示名の詐称防止、転送経路でIPが変わるケースの完全な救済

SPFは“なりすまし対策の土台”として効果がありますが、SPFだけでメールの安全性が完成するわけではありません。受信側の運用（隔離・拒否・スコアリング）にも左右されるため、全体設計の中で位置づけることが大切です。

SPFレコードの設定方法

SPFレコードはDNSのTXTレコードに設定します。基本形は「v=spf1」で始まり、許可条件（メカニズム）と判定（qualifier）を並べ、最後にallで締めます。

この例は、以下の意味になります。

• ip4:192.0.2.0/24：IPv4アドレス192.0.2.0〜192.0.2.255からの送信を許可
• ip6:2001:db8::/32：指定範囲のIPv6アドレスからの送信を許可
• include:example.com：example.comのSPF評価結果を取り込み（そのドメインが許可する送信元を自ドメインでも許可）
• ~all：上記以外はSoftFail（許可しないが、受信側で即拒否とは限らず隔離・スコアリング等の判断材料になる）

SPFレコードの設定にはドメイン管理者の権限が必要です。加えて、設定内容によっては正当なメールがSPF Fail扱いになるため、いきなり強いポリシーにせず段階的に整備するのが安全です。

SPFの判定（Pass/Failなど）の読み方

受信側がSPFを評価すると、代表的に以下のような結果が返ります。

• Pass：SPFで許可された送信元
• Fail：明確に許可されていない（-all等）
• SoftFail：許可されていないが、Failほど強くない（~all等）
• Neutral：どちらとも言えない（?all等）
• None：SPFレコードが存在しない/評価不能
• PermError / TempError：構文ミスやDNS一時障害などで評価できない

受信側が「Fail＝必ず拒否」とは限りません。実際には迷惑メール判定のスコアに反映されたり、隔離（迷惑メールフォルダ）に振り分けられたりします。最終処理は受信側のポリシー次第です。

SPFの検証方法

SPFレコードが正しく設定されているかどうかは、以下の方法で検証できます。

• オンラインのSPF検証ツールを利用する（構文・DNS参照回数・想定IPの判定を確認）
• DNSのTXTレコードを確認する（例：digやnslookupで取得して内容を目視確認）
• 実際にメールを送信し、受信側のヘッダーやログでSPF結果（pass/fail等）を確認する

検証は「初回だけ」で終わらせず、送信サービスの追加・変更（メール配信サービス、CRM、ヘルプデスク、グループウェア等）のタイミングで必ず見直す運用が現実的です。

SPFの導入メリット

なりすましメール対策の第一歩になる

SPFにより、送信元ドメインが許可していないIPから送られたメールを受信側で検出しやすくなります。結果として、なりすまし・スパムの混入を減らすための材料が増え、社内外のメール運用の安全性を底上げできます。

ドメインの信頼性（レピュテーション）に寄与する

正規の送信経路をSPFで明確にし、不要な送信元を排除していくと、受信側から見た「このドメインは管理されている」という印象につながりやすくなります。単独で劇的に改善するものではありませんが、到達率や迷惑メール判定の観点で、足回りの整備として意味があります。

メール到達率の改善につながる可能性がある

SPFが未設定、または不整合が多いと、受信側で“疑わしい”扱いになり、迷惑メールに寄る要因になります。SPFを整え、送信元を整理することで、重要な通知（請求書、ワンタイムコード、問い合わせ返信など）が埋もれにくい状態を作ることができます。

DKIM・DMARCと組み合わせると効果が増す

SPFは「送信経路（IP）」の確認が中心です。一方、DKIMは「署名による改ざん検知」、DMARCは「SPF/DKIMの結果を踏まえたドメイン保護ポリシー」を扱います。特にDMARCでは、ヘッダーFromとSPF/DKIMで使われるドメインの整合（アライメント）が重要になり、差出人表示のなりすまし対策としての実効性が高まります。

SPFレコードの読み方と設計の考え方

「all」の前に何を並べるかが設計

SPFは「許可する送信元の列挙」です。つまり、運用上は次の棚卸しが先に必要です。

• 自社の送信メールサーバー（オンプレ、クラウド、グループウェア）
• 外部委託の送信（メール配信、フォーム、チケット/問い合わせ管理、請求書サービス等）
• サブドメインで送信している用途の有無（example.comとmail.example.comなど）

「何から送っているか」が整理できていないままSPFを強くすると、正当なメールが落ちる事故が起きやすくなります。SPFは“技術”であると同時に“運用台帳”の整備でもあります。

qualifier（+ / - / ~ / ?）の使い分け

• +（Pass）：明示しない場合の既定。通常は書きません
• -（Fail）：明確に拒否したい（受信側で強い扱いになりやすい）
• ~（SoftFail）：原則許可しないが、移行期や様子見で使うことが多い
• ?（Neutral）：判断を委ねる。運用方針が定まらない場合の暫定に使われることがある

実務では、初期は~allで観測し、送信経路の漏れがないことをログで確認したうえで、段階的に-allへ移行する、という進め方が安全です（ただし、最終判断は組織の要件次第です）。

DNS参照回数（10回制限）に注意する

SPF評価では、include/redirect/a/mxなどによりDNS参照が増えます。一般に、参照が多すぎると「PermError（評価不能）」となり、意図した効果が出ません。外部サービスを重ねて利用しているほど増えやすいので、includeの乱立には注意が必要です。

SPFレコードは「1ドメインにつき1つ」が原則

同じドメインに複数のSPFレコード（v=spf1）が存在すると、受信側が正しく評価できずエラー扱いになる可能性があります。追加のたびにTXTレコードを増やすのではなく、既存のSPFレコードに要素を統合していく管理が必要です。

SPFの設定における注意点

SPFレコードの記述ミス（構文・要素の位置）

SPFは構文が比較的シンプルに見えますが、スペース区切り・メカニズムの書き方・allの位置など、細部のミスで評価不能になります。設定後は必ず、想定する送信元（自社サーバー、委託サービス等）で「Passになるか」を検証しましょう。

SPFレコードの複雑化と管理不能

IPやドメインを足し算で増やしていくと、SPFレコードが長くなり、参照回数制限にも引っかかりやすくなります。運用としては「送信元の統廃合」「不要になった送信サービスの削除」「サブドメイン分離（用途別）」など、設計で解決する視点が重要です。

第三者への委託メール配信の“漏れ”

メールマガジン、問い合わせ返信、請求書送付、認証メールなどを外部サービスに委託している場合、そのサービスの送信元がSPFに含まれていないとFail/SoftFailになります。委託先の案内に従い、includeの追加や送信ドメインの分離（専用サブドメイン化）を検討しましょう。

転送（forward）とSPFの相性

メール転送では、受信→転送の過程で送信元IPが変わるため、SPFがFailになりやすいという特性があります。この問題はSPFだけで完全には解消しづらく、DKIMの併用や、転送側がSRS（Sender Rewriting Scheme）に対応しているかどうか、といった別観点も関係します。

SPFとDMARCの連携

DMARCは、SPF/DKIMの結果に基づいて「失敗時にどう扱うか（none/quarantine/reject）」を受信側へ宣言する仕組みです。SPF単体だと「Return-PathでPassしているだけ」で、差出人表示のなりすまし対策としては弱いことがあります。DMARCではアライメントが重要になるため、SPFの設定はDMARC設計の一部として進めるのが確実です。

SPFのトラブルシューティング

SPFレコードの確認方法

まずはDNSに公開されているSPFレコード（TXT）を確認します。確認ポイントは以下です。

• v=spf1が含まれているか
• SPFレコードが複数存在していないか
• include/redirectの参照先が正しいか
• 不要な要素が残っていないか（退役した送信サービス等）

送信元IPアドレスの確認

「SPF Failになる」という相談で多いのは、実際の送信元IPが想定と違うケースです。たとえば、社内サーバーから送っているつもりでも、実際は中継サービス（アウトバウンドゲートウェイ）から出ている、といったことがあります。メールサーバーのログや受信ヘッダーから、実際の送信元IP（受信側が見ているIP）を特定し、SPFに含まれているかを確認します。

メール配信ログ（受信側ヘッダー）の確認

受信側ヘッダーやログには、SPF結果（pass/fail/softfail等）と、評価対象となったドメイン（Return-Path等）が残ることが多いです。どのドメインで評価され、どのIPが原因になっているかを切り分けると、修正点が明確になります。

よくある原因と対処の方向性

• 原因：委託サービスを追加したがSPFに反映していない
  対処：委託先の案内どおりinclude追加、または専用サブドメイン化
• 原因：includeが増えすぎてDNS参照制限に到達
  対処：送信元の整理・統合、不要includeの削除、設計の見直し
• 原因：SPFレコードが複数ある/構文が誤っている
  対処：TXTを統合し、ツールで構文検証してから反映
• 原因：転送でFailになっている
  対処：DKIM/DMARCの併用、転送環境の仕様（SRS等）確認

SPFは「入れたら終わり」ではなく、送信経路が増減するたびにズレが生じます。運用として、送信元の棚卸しとログ観測を定期的に行うことが、トラブル削減の近道です。

まとめ

SPFは、送信ドメインが許可した送信元IP（または送信サービス）から送られてきたメールかどうかを受信側が検証する仕組みで、なりすまし対策の基本となります。一方で、SPFが見ているのは主にReturn-Path等であり、差出人表示のなりすまし対策を強めるにはDKIM/DMARCとの併用が重要です。記述ミス、複雑化、委託配信の漏れ、転送との相性といった落とし穴を押さえ、段階的に導入・検証・改善していくことで、メール配信の信頼性と安全性を高められます。

FAQ：SPFに関するよくある質問