A secure SPF (Sender Policy Framework) record lists every server allowed to send mail for your domain, stays under the 10 DNS-lookup limit, and ends with -all so unauthorised senders are rejected rather than just flagged. Get any one of those wrong and receiving mail servers either reject legitimate mail or silently let spoofed mail through.
SPF is defined by RFC 7208 (which obsoletes the older RFC 4408), and it's published as a plain DNS TXT record — there's no dedicated SPF record type in active use anymore. This guide walks through building one that's both correct and hard to break.
What is an SPF record, exactly?
An SPF record is a TXT record on your domain that tells receiving mail servers which IP addresses and hosts are authorised to send mail using your domain in the envelope-from (Return-Path) address. When someone emails you claiming to be [email protected], the receiving server checks your domain's SPF record to see if the sending IP is on the approved list.
A basic record looks like this:
v=spf1 ip4:203.0.113.10 include:_spf.google.com -all
Each piece is a mechanism, evaluated left to right:
| Part | Meaning |
|---|---|
v=spf1 |
Required version tag, must be first |
ip4:203.0.113.10 |
Authorises a specific IPv4 address (no DNS lookup needed) |
include:_spf.google.com |
Pulls in Google's sending ranges (uses a DNS lookup) |
-all |
Hard-fail everything else — reject unlisted senders |
You can check what a domain currently publishes with our free DNS lookup tool, and build a syntactically valid record from scratch with the SPF generator.
Which mechanisms and qualifiers should you use?
SPF mechanisms describe what to check; qualifiers describe what to do when a check matches.
Mechanisms:
ip4/ip6— match a specific address or CIDR block, no lookup costa— match the domain's own A/AAAA recordmx— match hosts listed in the domain's MX recordsinclude— pull in another domain's SPF policy (common for Google Workspace, Microsoft 365, ESPs)exists— match based on a DNS lookup returning any A recordptr— matches based on reverse DNS lookups
Qualifiers, placed before a mechanism:
+Pass (default, rarely written explicitly)-Fail (hard fail — reject)~SoftFail (accept but mark, often into spam)?Neutral (no real opinion — best avoided)
WarningAvoid
ptrentirely. RFC 7208 explicitly marks it as not recommended because reverse-DNS lookups are slow, unreliable, and expensive against the lookup limit.
For the trailing catch-all, use -all once you're confident every legitimate source is listed. ~all is a reasonable staging step while you're still discovering senders, but leaving it as your permanent policy weakens the whole point of SPF — and a stray +all authorises literally anyone to spoof your domain. Treat +all as a critical misconfiguration, not a lenient setting.
The 10-lookup limit — the pitfall that breaks most SPF records
This is the part most teams get wrong. RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups per check. Every include, a, mx, ptr, exists, and redirect counts toward that limit — ip4 and ip6 don't, since they need no lookup.
Go over 10 and the result is a PermError, which receiving servers treat as a broken/failed check — not a pass. This is a genuinely common outage: a domain adds Google Workspace, then Microsoft 365 for a shared inbox, then a marketing platform, a CRM, and a helpdesk tool, each contributing its own nested include: chain, and nobody notices the total lookup count creeping past 10 until deliverability quietly drops.
Two things make this worse:
mxis a hidden multiplier. Usingmxin your SPF record costs one lookup for the MX query itself, plus one more for each MX host it returns.- Void lookups are capped at 2. A
Frequently asked questions
- What's the difference between SPF hard fail and soft fail?
- A hard fail (`-all`) tells receiving servers to reject mail from unlisted senders outright, while a soft fail (`~all`) asks them to accept it but treat it with suspicion, often routing it to spam. Use `~all` only while you're still confirming all legitimate senders, then switch to `-all`.
- Does SPF alone stop email spoofing?
- No — SPF only validates the envelope-from (Return-Path) address, not the visible 'From:' header a recipient sees, so it doesn't fully prevent display-name spoofing. Pair SPF with DKIM and a DMARC policy that enforces alignment for real anti-spoofing protection.
- Can I have two SPF TXT records for redundancy?
- No. RFC 7208 requires exactly one SPF TXT record per domain — publishing more than one causes a PermError and the entire SPF check fails. If you need multiple sources, combine them into a single record using `include` mechanisms.
- What is SPF flattening and is it safe?
- SPF flattening replaces `include:` mechanisms with their resolved IP addresses to reduce lookup count, which helps stay under the 10-lookup limit but creates an ongoing maintenance burden — you must keep the flattened IPs in sync whenever the provider changes its sending infrastructure, or mail will start failing silently.