What Is SPF? How Sender Policy Framework Protects Your Email

SPF (Sender Policy Framework) is a DNS-based email authentication standard that lets a domain owner publish which IP addresses and hostnames are permitted to send mail using that domain. Receiving servers look up the record, compare it to the connecting IP, and reject or flag the message if it doesn't match. It's defined in RFC 7208.

Adoption has climbed fast over the last few years; Valimail's 2024 Email Fraud Landscape report found SPF records exist on roughly 80% of the domains it scans globally, though only a fraction are configured correctly (Valimail, 2024). That gap, between "has SPF" and "SPF actually works," is where most deliverability problems live.

What is SPF?

SPF stands for Sender Policy Framework. It's a TXT record you publish in DNS that lists the mail servers (by IP address, hostname, or included third-party records) allowed to send email from your domain. When a receiver like Gmail gets a message claiming to come from you@yourdomain.com, it checks your SPF record and compares the sending IP against the allowed list.

Think of it as a guest list at the door. If the IP's on the list, the message passes SPF. If it isn't, the message fails, and the receiver decides (based on your policy and its own rules) whether to reject it, mark it as spam, or deliver it anyway. SPF alone doesn't block spoofing; it gives receivers a signal. DMARC is what tells them what to do with that signal.

One subtlety that trips people up all the time. SPF only checks the envelope sender (the MAIL FROM / Return-Path address), not the visible From: header most users actually see. That's a big part of why SPF on its own can't stop display-name phishing; you need DKIM and DMARC stacked on top. More on that in our SPF vs DKIM vs DMARC breakdown.

How does SPF work?

The mechanics are simpler than the acronyms make them sound. Five things happen, in order.

1. You publish a TXT record at your root domain (like yourdomain.com) listing allowed senders.
2. Someone sends an email claiming to be from @yourdomain.com.
3. The receiving server extracts the envelope-from domain and queries DNS for your TXT record.
4. It compares the connecting IP to the mechanisms in the record (ip4, ip6, a, mx, include).
5. It returns one of seven results: pass, fail, softfail, neutral, none, temperror, or permerror (RFC 7208 §2.6).

That result gets stamped into the Authentication-Results header and fed into DMARC evaluation. Google's Postmaster docs confirm Gmail uses SPF (alongside DKIM) as one of the two alignment checks that decide whether mail lands in inbox, spam, or nowhere at all (Google Postmaster, 2024).

Where SPF lives

The record lives as a TXT record on your sending domain. Some older guides mention an SPF record type (DNS type 99); RFC 7208 §3.1 officially deprecated that in 2014. Use TXT; ignore anything that says otherwise.

What does an SPF record look like?

Here's a real-world example for a domain that sends marketing mail through Mailneo, transactional mail through SendGrid, and workspace mail through Google Workspace:

yourdomain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:spf.mailneo.co ip4:203.0.113.25 -all"

Reading it left to right:

• v=spf1: the version tag. Every SPF record starts with this; without it, the record isn't SPF.
• include:_spf.google.com: pulls in Google's published SPF record, authorizing Google Workspace IPs.
• include:sendgrid.net: same idea, for SendGrid's sending IPs.
• include:spf.mailneo.co: Mailneo's sending IPs (swap this for whatever ESP you use).
• ip4:203.0.113.25: a single literal IPv4 address (maybe your on-prem mail server or a VPS).
• -all: the qualifier + all mechanism, meaning "everything not matched above fails hard."

The mechanisms you'll actually reach for:

• a: authorize the A record of the current domain (or a named domain with a:mail.example.com).
• mx: authorize the domain's MX hosts.
• ip4: / ip6:: literal IP addresses or CIDR ranges.
• include:: recursively include another domain's SPF record.
• all: matches everything, always placed last with a qualifier.

Qualifiers change what each mechanism means when it matches:

Qualifier	Result	What it means	Typical use
+	Pass	Accept the message. Implicit default if no qualifier is written.	Rarely written explicitly.
-	Fail (hard fail)	Reject the message outright.	Mature deployments, once every legitimate sender is in the record.
~	Softfail	Accept but mark suspicious; usually routed to spam.	Initial rollout, so unauthorized senders get flagged without bouncing.
?	Neutral	Treat as if no policy exists.	Avoid; neutral defeats the purpose of publishing SPF.

So -all means "fail everything not explicitly permitted." ~all means "softfail everything not permitted; treat with suspicion but don't reject outright." The distinction matters more than most guides admit; we'll get to it below.

[SCREENSHOT: example SPF TXT record in Cloudflare or a real DNS provider]

Why do you need SPF?

Email fraud isn't a theoretical problem. The FBI's IC3 2023 Internet Crime Report put losses from Business Email Compromise at $2.9 billion that year alone (FBI IC3, 2023). A significant share of BEC starts with a spoofed domain; SPF is the first, cheapest line of defense against that specific attack.

There's a deliverability angle too. Gmail and Yahoo's February 2024 bulk sender rules (the ones that kicked a lot of senders into spam folders overnight) require SPF on every domain sending more than 5,000 messages a day to Gmail users (Google Postmaster, 2024). Yahoo matched the policy; Microsoft signaled the same direction. If you're running a newsletter, a transactional platform, or any volume of marketing mail, publishing a valid SPF record isn't optional anymore.

And then there's DMARC, which can't function without at least one of SPF or DKIM passing with alignment. DMARC.org's own documentation describes SPF as one of two "underlying authentication mechanisms" DMARC relies on (DMARC.org); skip SPF and your DMARC policy either fails closed (blocking legitimate mail) or gets ignored. Neither is what you want.

[MY EXPERIENCE: describe the first SPF record you fixed and what was wrong]

How do you set up SPF correctly?

A clean setup takes about 20 minutes for most senders. The broad strokes:

1. List every system that sends mail from your domain. All of them. Marketing ESP, transactional provider, help desk (Zendesk, Intercom, Freshdesk), CRM (HubSpot, Salesforce Marketing Cloud), HR tools that send offer letters, monitoring services, your own servers.
2. Find the SPF include or IP range each vendor publishes. (It's in their docs; if it's not, ask their support.)
3. Combine them into a single TXT record starting with v=spf1, ending with a qualifier + all.
4. Publish the record at your root sending domain. If you send from subdomains (mail.yourdomain.com, news.yourdomain.com), each subdomain needs its own record; SPF doesn't inherit.
5. Test with a tool like Mailneo's SPF generator, MXToolbox, or dig TXT yourdomain.com. Confirm the record parses cleanly.
6. Wait 24–48 hours for DNS to propagate; then send a test message to a Gmail address and check the Authentication-Results header says spf=pass.

Start with ~all (softfail) while you verify nothing's broken. Watch your bounce logs and DMARC aggregate reports for a week or two. Once you're confident every legitimate sender is covered, tighten to -all (hard fail). It's the same logic you'd apply to a firewall; don't move to deny-by-default until you know what the default is denying.

For a full walk-through covering all three protocols together, see our step-by-step SPF, DKIM, and DMARC setup guide.

Common SPF mistakes to avoid

The failures I see most often, roughly ranked by how often they bite.

Publishing multiple SPF records. RFC 7208 §3.2 says a domain must have only one. Two records cause a permerror, which DMARC treats as a fail. If you've got two (maybe one you added last year and one your ESP auto-generated), merge them into a single TXT record.

Then there's the 10 DNS lookup limit, which is the big one. RFC 7208 §4.6.4 caps the number of DNS lookups an SPF evaluation can trigger at ten. Every include:, a, mx, exists, and redirect counts; ip4 and ip6 do not. Chain four or five ESPs together (each with its own nested includes) and you blow through the limit, which produces a permerror and fails SPF outright. Valimail's research found roughly 1 in 5 SPF records exceed the lookup limit (Valimail, 2024). Fixes include SPF flattening services (which replace includes with literal IPs), consolidating vendors, or splitting senders across subdomains.

Another common one is using -all before you're ready. A hard fail on a record that's missing a legitimate sender will bounce real mail. Customers' password reset emails, your CEO's calendar invites from a laptop on hotel Wi-Fi, the CRM that started forwarding last Tuesday. Use ~all during rollout; move to -all after a clean DMARC report.

Forgetting subdomains is its own class of bug. SPF is per-domain. If yourdomain.com has a record but notifications.yourdomain.com doesn't, mail from the subdomain falls under none (no policy), and DMARC may fail it for lack of SPF. Either publish a record on each sending subdomain or use a DMARC sp= subdomain policy that matches your intent.

Last: trusting old docs. The SPF world changed in 2014 (RFC 7208 obsoleted RFC 4408), in 2018 (widespread DMARC adoption), and again in 2024 (the Gmail/Yahoo bulk sender rules). Anything older than two years is suspect. M3AAWG keeps current best practices documented, including their sender authentication guidance (M3AAWG, 2023); start there, not with a 2015 blog post.

[ORIGINAL DATA: percentage of new Mailneo customers whose first SPF audit fails the 10-lookup limit, and the top three offending includes driving it]

Key takeaways

• SPF is a TXT record published in DNS that lists the IPs and hostnames allowed to send mail from your domain; receivers check it against the connecting IP and return pass, fail, or softfail.
• The 10-DNS-lookup limit from RFC 7208 §4.6.4 is the most common cause of broken SPF records; roughly 1 in 5 domains exceed it (Valimail, 2024).
• SPF alone doesn't stop display-name phishing; it checks the envelope sender, not the visible From: header. Pair it with DKIM and DMARC.
• Gmail and Yahoo's 2024 bulk sender rules require valid SPF on any domain sending 5,000+ messages a day to their users (Google Postmaster, 2024).
• Start with ~all during rollout; move to -all only after verifying every legitimate sender passes.

Frequently asked questions

Does SPF work on its own?

Not really. SPF verifies the envelope sender, which most mail clients never display; attackers can spoof the visible From: header while still passing SPF. DMARC is what closes that gap by requiring SPF (or DKIM) to align with the From: domain. Use all three: SPF, DKIM, and DMARC.

What's the difference between ~all and -all?

~all is softfail; receivers accept the message but flag it as suspicious. -all is hard fail; receivers are instructed to reject. Use ~all while you're rolling out SPF and confirming every legitimate sender is covered; tighten to -all once you're confident nothing's missing from the record.

How do I fix an SPF record that's over the 10-lookup limit?

Three options, roughly in order of preference. Consolidate vendors so you need fewer include: mechanisms. Replace include: with literal ip4: or ip6: entries (known as SPF flattening; several services do this dynamically). Split senders across subdomains, each with its own shorter record.

Can I have two SPF records on one domain?

No. RFC 7208 §3.2 explicitly forbids it; multiple records produce a permerror, which DMARC treats as a fail. If you need to authorize more senders, merge everything into a single TXT record that starts with v=spf1.

Does SPF break when I forward email?

Yes, often. Forwarding changes the connecting IP but keeps the original envelope sender, so SPF fails at the forwarding hop. This is why DMARC relies on either SPF or DKIM passing with alignment; DKIM survives forwarding because it signs the message body and headers. Another reason to set up all three, not just SPF.

Related resources

• SPF generator tool: build and validate a record in the browser
• SPF glossary entry: quick definition and cross-references
• DNS record glossary: what TXT, MX, A, and CNAME records actually do
• Email authentication glossary: SPF, DKIM, DMARC, BIMI in one place
• SPF vs DKIM vs DMARC: how the three protocols fit together
• What is DKIM?: the cryptographic signature layer
• What is DMARC?: the policy layer that ties SPF and DKIM together
• How to set up SPF, DKIM, and DMARC: full walkthrough
• Email deliverability guide: the pillar article for this cluster