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

SPF（Sender Policy Framework）は、受信側が「このドメインから送ってよいサーバーか」をDNSのTXTレコードで確かめる仕組みです。メールのなりすましを減らすうえでの基本策ですが、From欄の見た目までSPFだけで守れるわけではありません。導入するときは、どのサービスからメールを送っているかを洗い出し、DKIMやDMARCとどう組み合わせるかまで見ておく必要があります。

SPFとは何を確かめる仕組みか

SPFの役割

SPFは、メールを送ってきたサーバーの送信元IPアドレスが、そのドメインで送信を許された範囲に入っているかを受信側が確かめる仕組みです。ドメインの管理者はDNSのTXTレコードにSPFを公開し、受信側のメールサーバーはその内容を見て判定します。

ここで見るのは、主にエンベロープFrom（Return-Path）やHELO/EHLOで使われるドメインです。メールソフトのヘッダーFromをそのまま裏づける仕組みではないため、見た目の差し出し元まで含めて確かめたい場合は、DKIMやDMARCと組み合わせて、使うドメインがそろっているかまで確認します。

SPFでできること・SPFだけではできないこと

• できること：このドメインを名乗ってよい送信元（IPアドレスや送信サービス）を絞り込むこと
• SPFだけではできないこと：メール本文が安全かどうかの保証、表示名のなりすまし対策をSPFだけで完結させること、転送で送信元IPが変わる場面をSPFだけで救うこと

SPFはなりすまし対策の出発点として有効ですが、これだけで安全なメール運用ができるわけではありません。受信側でどう扱うかにも差があるため、DKIMやDMARC、受信時の扱いとあわせて考える必要があります。

DNSにSPFをどう書くか

SPFはDNSのTXTレコードに設定します。基本は「v=spf1」で始め、許可する送信元を順に並べ、最後にallを置きます。

この例は、次の意味です。

• ip4:192.0.2.0/24：IPv4アドレス192.0.2.0〜192.0.2.255からの送信を許可
• ip6:2001:db8::/32：この範囲のIPv6アドレスからの送信を許可
• include:example.com：送信元IPについてexample.comのSPF評価を行い、その結果がPassなら条件に一致したものとして扱う
• ~all：ここまでで一致しなかった送信元はSoftFailとして扱う（受信側の設定しだいで隔離や加点の対象になる）

SPFを更新できる権限が必要です。正規の送信元が漏れていると、正しいメールまでSPF Failになるため、最初は弱めの設定で様子を見ながら整えるほうが安全です。

SPFの結果をどう読むか

受信側がSPFを評価すると、主に次の結果が返ります。

• Pass：SPFで許可された送信元
• Fail：明確に許可されていない（-allなど）
• SoftFail：許可されていないが、Failほど強く扱わない（~allなど）
• Neutral：送信元IPが許可されているかどうかを明示しない（?allなど）
• None：使えるドメイン名を取り出せない、またはSPFレコードが見つからない
• PermError：公開したSPFを正しく解釈できない
• TempError：DNSの一時的な不調などで、その場では評価できない

受信側がFailをどう扱うかは一律ではありません。拒否する運用もあれば、迷惑メールとして隔離したり、判定点に加えたりする運用もあります。

SPFをどう確かめるか

SPFが正しく設定されているかどうかは、次のように確かめられます。

• オンラインのSPF確認ツールを使う（書き方、DNS問い合わせの回数、想定したIPの判定を確かめる）
• DNSのTXTレコードを見る（例：digやnslookupで取得し、内容を手で確かめる）
• 実際にメールを送信し、受信側のヘッダーやログでSPF結果（passやfailなど）を確かめる

確認は初回だけで終わらせず、送信サービスを追加したときや設定を変えたときに、そのたびに見直す運用が現実的です。

SPFを入れると何がよいか

なりすましメールを見分けやすくなる

SPFを入れると、ドメインの管理者が許していないIPから届いたメールを受信側が見つけやすくなります。なりすましや迷惑メールを減らすための手がかりが増える点が利点です。

送信元を管理していることを受信側へ示しやすい

正規の送信元をSPFで明らかにし、不要な送信元を外していくと、そのドメインがきちんと管理されていることを受信側へ示しやすくなります。これだけで到達率が大きく変わるとは言えませんが、土台を整える意味はあります。

大事な通知が埋もれにくくなる

SPFが未設定だったり、送信元の登録に漏れが多かったりすると、受信側から不審なメールと見られやすくなります。設定を整えることで、請求書やワンタイムコード、問い合わせへの返信などが迷惑メールに寄りにくくなることがあります。

DKIMとDMARCを組み合わせると補い合える

SPFは主に送信元IPとドメインの関係を見ます。DKIMは署名で改ざんの有無を確かめ、DMARCはSPFやDKIMの結果とFrom欄のドメインが合っているかを見たうえで、失敗時の扱いを示します。三つを組み合わせると、見た目の差し出し元まで含めた対策に進めます。

SPFレコードを考えるときの見方

allの前に何を並べるかが要点

SPFは、送信を許す相手を並べる仕組みです。先に次を洗い出しておかないと、正しいメールまで止まりやすくなります。

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

何から送っているかが曖昧なままSPFを強くすると、正しいメールが落ちる事故につながります。SPFはDNSの設定であると同時に、送信元の一覧を保つ作業でもあります。

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

• +（Pass）：明示しない場合の既定値で、ふつうは書きません
• -（Fail）：明確に許可しないことを示す
• ~（SoftFail）：基本的には許可しないが、移行中などで少し弱めに扱う
• ?（Neutral）：許可か不許可かを明言しない

最初は~allで様子を見て、漏れている送信元がないことを確認したうえで、必要なら-allへ進めるやり方が安全です。どこまで厳しくするかは組織の条件で決まります。

DNSの問い合わせ回数に注意する

SPFでは、include、redirect、a、mx などの評価でDNSへの問い合わせが増えます。これらのうちDNS参照を伴う仕組みや指定子は、合計10回までという上限があるため、多すぎるとPermErrorになるおそれがあります。外部サービスを重ねて使うほど増えやすいので、includeを増やしすぎないように注意が必要です。

SPFレコードはTXTを一つにまとめる

同じドメインで、SPFの判定に使われるレコードが複数見つかる状態は避ける必要があります。送信元を追加するたびにTXTレコードを増やすのではなく、既存のSPFへ統合して管理します。

SPFで起きやすい問題

書き方のミス

SPFは見た目が単純でも、スペースの入れ方やメカニズムの書き方、allを置く位置などを誤ると正しく評価されません。設定後は、自社サーバーや委託サービスから送ったメールがPassになるかを必ず確かめます。

レコードが長くなりすぎる

IPアドレスやドメインを足していくと、SPFレコードは長くなりやすく、DNSへの問い合わせ上限にも達しやすくなります。不要になった送信サービスを外す、用途ごとにサブドメインを分ける、といった整理が欠かせません。

外部サービスの送信元が漏れる

メールマガジン、問い合わせ返信、請求書メール、認証メールなどを外部サービスから送る場合、その送信元がSPFに入っていないとFailやSoftFailになりやすくなります。委託先の案内どおりにincludeを足すか、用途ごとに専用のサブドメインを分けるかを検討します。

転送とSPFの相性

メールを転送すると、受信側から見える送信元IPが変わるため、SPFはFailになりやすくなります。この点はSPFだけでは対処しにくく、DKIMの併用や、転送側がSRS（Sender Rewriting Scheme）に対応しているかどうかも確認が必要です。

DMARCとあわせて考える

DMARCは、SPFやDKIMの結果をもとに、失敗したメールをどう扱うかを受信側へ示す仕組みです。SPFだけではReturn-Path側しかPassしていないことがあり、From欄の見た目に近いドメインまで守れていない場合があります。DMARCまで含めて設計すると、差し出し元の見え方とSPFやDKIMの結果をそろえやすくなります。

SPFが通らないときの見方

公開したSPFをどう確かめるか

まずはDNSに公開されているSPFレコード（TXT）を確認します。見るポイントは次のとおりです。

• v=spf1が入っているか
• 同じドメインに、SPFの判定に使われるレコードが二つ以上ないか
• includeやredirectの参照先が正しいか
• 不要な要素が残っていないか（使わなくなった送信サービスなど）

実際に使われた送信元IPを確かめる

SPF Failの原因として多いのは、想定していたものと実際の送信元IPが違うケースです。社内サーバーから送っているつもりでも、実際には中継サービスを経由している場合があります。メールサーバーのログや受信ヘッダーを見て、受信側が見ている送信元IPを特定し、SPFに入っているかを確かめます。

受信ヘッダーで見るポイント

受信側のヘッダーやログには、SPFの結果（pass、fail、softfail など）と、どのドメインを使って評価したかが残ることが多いです。どのドメインで評価され、どのIPが原因だったかを分けて見ると、直す場所が見えやすくなります。

よくある原因と対処

• 原因：委託サービスを追加したがSPFに反映していない
  対処：委託先の案内どおりにincludeを足す、または専用サブドメインを使う
• 原因：includeが増えすぎてDNSへの問い合わせ上限に達した
  対処：送信元を整理し、不要なincludeを外す
• 原因：SPFレコードが重複している、または書き方が誤っている
  対処：TXTを統合し、確認ツールで検証してから反映する
• 原因：転送でFailになっている
  対処：DKIMやDMARCもあわせて見直し、転送側の仕様（SRSなど）を確認する

SPFは一度入れて終わりではありません。送信元が増えたり変わったりするたびにズレが出るため、送信元の洗い出しとログ確認を定期的に続けることが、トラブルを減らす近道です。

まとめ

SPFは、ドメインが許した送信元IPや送信サービスから届いたメールかどうかを受信側が確かめる仕組みです。なりすまし対策の基本になりますが、From欄の見た目までSPFだけで守れるわけではありません。DKIMやDMARCと組み合わせ、送信元の洗い出し、段階的な設定、継続的な確認を進めることで、メール運用の信頼性を高めやすくなります。

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