なりすまし対策の土台となる「SPF」を、仕組み・レコードの書き方・つまずきやすい落とし穴まで、はじめての方向けに整理します。
最終更新: 2026年6月
SPF（Sender Policy Framework）は、「このドメインのメールは、これらのサーバーから送られるはずだ」という送信元の許可リストを、あらかじめDNSに公開しておく仕組みです。受信側のメールサーバーは、届いたメールの実際の送信元が、その許可リストに含まれているかを照合します。含まれていれば「正規の送信元から来た」と判断でき、含まれていなければ、なりすましの疑いがあると分かります。
SPFは、SPF・DKIM・DMARC というなりすまし対策の3点セットのうち、最も基本的な土台にあたります。
仕組みはシンプルです。あるドメインを名乗るメールが届くと、受信側は、そのドメインのDNSに公開されたSPFレコード（後述）を参照します。そして、実際にメールを送ってきたサーバーのIPアドレスが、レコードに記載された許可リストに含まれるかを確認します。含まれていれば「pass（合格）」、含まれていなければ「fail（不合格）」です。
ここで一点、後で重要になる注意があります。SPFが照合するのは、技術的な送信元（エンベロープFrom、Return-Path）のドメインであって、メールソフトの差出人欄に表示されるアドレス（ヘッダーFrom）とは別物です。この違いが、後述する「SPFだけでは足りない理由」につながります。
SPFは、ドメインのDNSに1本のTXTレコードとして公開します。必ず v=spf1 で始まり、許可する送信元を並べ、最後に「リストにないものをどう扱うか」を指定します。
たとえば、Google Workspace でメールを送るドメインなら、次のような形になります。
v=spf1 include:_spf.google.com -all
主な構成要素は次のとおりです。include: は他のサービスの許可リストを取り込むもので、メール配信サービスやグループウェアを使う場合に多用します。a や mx はそのドメインのAレコード・MXレコードのサーバーを許可、ip4: / ip6: は特定のIPを直接許可します。そして末尾の all が、リストに該当しない送信元の扱いを決めます。
-all と ~all の違い末尾の記号で挙動が変わります。-all（ハードフェイル）は「リストにない送信元は不正」と明確に宣言します。~all（ソフトフェイル）は「おそらく不正だが拒否までは求めない」という弱い宣言です。なりすまし対策を効かせたいなら -all が基本です。逆に +all は「どこからでも許可」を意味し、SPFを無意味にするので使ってはいけません。
SPFは一見シンプルですが、運用で事故が起きやすいポイントがいくつかあります。
最も多い事故がこれです。SPFは1回の検証で参照できるDNSの回数が合計10回までと決められており（RFC 7208）、これを超えるとSPF全体が無効（permerror）になります。送信サービスを表す include は、内部でさらに複数回のDNS参照を伴うことが多く、メール配信ツールやCRMなどを数個追加しただけで、気づかないうちに上限に達します。「設定したはずなのに、あるツールを1つ足したらメールが届かなくなった」という形で表面化するのが典型です。
1つのドメインに公開できるSPFレコードは1本だけです。複数のサービスを設定するうちに、SPFのTXTレコードを2本作ってしまうと、SPF全体が無効になります。複数のサービスを許可したいときは、1本のレコードの中に include を並べます。
メールが転送されると、送信元サーバーが転送サーバーに変わるため、元のドメインのSPFには含まれず、SPFはfailします。これはSPFの仕組み上避けられない弱点で、SPF単独ではなりすまし対策として不十分である、という大きな理由のひとつです。
前述のとおり、SPFが照合するのは技術的な送信元（エンベロープFrom）で、利用者の目に見える差出人欄（ヘッダーFrom）ではありません。なりすましメールは、まさにこのヘッダーFromを偽装して「正規の会社からのメール」に見せかけます。SPFはヘッダーFromを直接は守らないため、SPFがpassしていても、見た目の差出人がなりすましということが起こりえます。
この穴を塞ぐのがDMARCです。DMARCは、SPFやDKIMの結果と、利用者に見えるヘッダーFromのドメインが一致しているか（整合性、アライメント）まで確認します。だからこそ、SPF・DKIM・DMARC は3点セットで初めてなりすまし対策として機能します。SPFはその不可欠な土台、という位置づけです。
まずやるべきは、自社ドメインのSPFが正しく設定されているかを知ることです。そもそもSPFレコードがあるか、-all で終わっているか、そして10ルックアップの上限を超えていないか。これらを把握すれば、次に直すべき点が見えてきます。
SPF is the foundation of email anti-spoofing. Here's how it works, how to write an SPF record, and the pitfalls that trip up even experienced administrators.
Last updated: June 2026
SPF (Sender Policy Framework) lets you publish a list of mail servers authorized to send email on behalf of your domain — in DNS, as a TXT record. When a receiving mail server gets a message claiming to be from your domain, it checks whether the actual sending server appears on that list. If it does, SPF passes. If it doesn't, the message is flagged as a potential spoof.
SPF is the most fundamental layer of the SPF + DKIM + DMARC trio that together protect your domain from spoofing.
The process is straightforward. When a message arrives claiming to be from your domain, the receiving server looks up your SPF record in DNS and checks whether the sending server's IP address is on the authorized list. Match → pass. No match → fail.
One important nuance: SPF checks the technical envelope sender (the Return-Path / MAIL FROM address), not the From header that users see in their email client. This distinction matters — it's the reason SPF alone isn't enough to stop spoofing, as explained below.
An SPF record is a single DNS TXT record. It always starts with v=spf1, followed by the authorized senders, and ends with an all qualifier that says what to do with everything else.
For a domain that sends mail through Google Workspace, it looks like this:
v=spf1 include:_spf.google.com -all
The main building blocks: include: pulls in another service's authorized server list (common when using email delivery services or productivity suites). a and mx authorize the servers in your domain's A and MX records. ip4: / ip6: authorize specific IP addresses directly. The trailing all qualifier controls what happens to everything not on the list.
-all vs ~all-all (hard fail) declares that any server not on the list is unauthorized — the strongest stance. ~all (soft fail) says "probably not authorized, but don't reject it." For real protection, use -all. Never use +all — it means "anyone can send from my domain" and defeats the purpose entirely.
This is the most common SPF failure. RFC 7208 limits SPF validation to 10 DNS lookups total. Each include: can chain into multiple additional lookups internally, so adding just a few email services can silently push you over the limit. When the limit is exceeded, SPF returns permerror — the entire record is treated as invalid. The symptom: legitimate mail stops being delivered after you add one more sending service.
A domain can have exactly one SPF TXT record. If you accidentally create two, SPF becomes invalid entirely. To authorize multiple services, combine them into a single record using multiple include: terms.
When a message is forwarded, the sending server changes to the forwarding server — which won't be in the original domain's SPF record, causing SPF to fail. This is an inherent limitation of SPF, and one of the main reasons SPF alone is insufficient for spoofing protection.
As noted above, SPF checks the envelope sender, not the From header visible to the recipient. Spoofed emails forge the From header to impersonate a legitimate organization. Since SPF doesn't directly validate the From header, an email can pass SPF while still displaying a spoofed sender name.
DMARC closes this gap by checking that the domain authenticated by SPF or DKIM actually aligns with the From header domain. That's why SPF + DKIM + DMARC must work together — SPF is the essential foundation, but it needs the other two to deliver real protection.
The first step is knowing your current state: does your domain have an SPF record? Does it end with -all? Is it over the 10-lookup limit? Once you know what's there, it's clear what needs fixing.
Enter your domain for a free instant report on your SPF, DMARC, DKIM, and MX configuration — including SPF lookup count. No sign-up required.
Check for free