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 against the connecting IP, and reject or flag the message when it doesn't match. The standard is RFC 7208.

Nearly every domain that sends mail has an SPF record by now. A lot of those records do nothing useful; they've been over the DNS lookup limit for two years, or they end in a qualifier nobody chose deliberately. The gap between "has SPF" and "SPF actually evaluates" is where most deliverability pain lives.

What is SPF?

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

Think of it as a guest list at the door. IP on the list, the message passes SPF; IP not on the list, the message fails, and the receiver decides what to do next based on your policy and its own filtering rules. SPF on its own doesn't block spoofing; it hands receivers a signal. DMARC is the piece that tells them what to do with that signal.

Here's the subtlety that trips people up constantly. SPF checks the envelope sender, meaning the MAIL FROM or Return-Path address, and never touches the visible From: header that recipients actually read. An attacker can pass SPF cleanly on a domain they control while displaying your brand in the From line. That is why SPF alone can't stop display-name phishing, and why you want DKIM and DMARC stacked on top; the SPF vs DKIM vs DMARC breakdown covers how the three divide the work.

How SPF works

The mechanics are simpler than the acronyms suggest. Five things happen, in order.

1. You publish a TXT record at your sending domain 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 that 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, where it serves as one of the two alignment checks deciding inbox, spam, or nothing at all (Google Postmaster).

The record lives as a TXT record on the sending domain. Some older guides mention a dedicated SPF record type (DNS type 99); RFC 7208 §3.1 deprecated that in 2014. Use TXT and ignore anything that says otherwise. If DNS record types are unfamiliar ground, the DNS record glossary entry is a shorter detour than the RFC.

Reading an SPF record

Here's a realistic record 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 record, authorizing Google Workspace IPs.
• include:sendgrid.net: same idea, for SendGrid's sending IPs.
• include:spf.mailneo.co: Mailneo's sending IPs (swap in whatever ESP you use).
• ip4:203.0.113.25: a single literal IPv4 address, maybe an on-prem mail server or a VPS.
• -all: the qualifier plus the all mechanism, meaning everything not matched above fails hard.

The mechanisms you'll actually reach for are a (the A record of the current or a named domain), mx (the domain's MX hosts), ip4: and ip6: (literal addresses or CIDR ranges), include: (recursively pull in another domain's record), and all, which matches everything and always sits last with a qualifier in front of it.

Qualifiers change what a mechanism means when it matches:

So -all means fail everything not explicitly permitted, and ~all means treat it with suspicion but don't reject it. That one character carries more consequence than most guides admit.

Why SPF matters

Email fraud is not a theoretical problem. The FBI's IC3 2023 Internet Crime Report put losses from Business Email Compromise at $2.9 billion in that year alone (FBI IC3, 2023). A large share of BEC begins with a spoofed domain, and SPF is the cheapest available defense against that specific move.

The deliverability case is more immediate for most senders. Gmail and Yahoo's February 2024 bulk sender rules require SPF on any domain sending more than 5,000 messages a day to Gmail users (Google Postmaster); Yahoo matched the policy and Microsoft has signaled the same direction. If your inbox placement rate dropped sharply and nothing about your content changed, authentication is the first thing to look at, ahead of subject lines and send times. The broader picture is in the email deliverability guide.

There's also DMARC, which cannot function unless SPF or DKIM passes with alignment. Skip SPF and your DMARC policy either fails closed, blocking legitimate mail, or gets ignored entirely. Neither outcome is the one you wanted.

Setting up SPF

A clean setup takes about twenty 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, CRM, the HR tool that sends offer letters, monitoring services, your own servers.
2. Find the include or IP range each vendor publishes. It's in their docs; if it isn't, ask support.
3. Combine them into a single TXT record starting with v=spf1 and ending with a qualifier plus all.
4. Publish the record at your root sending domain. If you also send from subdomains such as news.yourdomain.com, each one needs its own record; SPF does not inherit.
5. Check that the record parses with Mailneo's SPF generator or dig TXT yourdomain.com.
6. Wait 24 to 48 hours for DNS to propagate, then send a test to a Gmail address and confirm the Authentication-Results header reads spf=pass.

Start with ~all while you verify nothing broke. Watch bounce logs and DMARC aggregate reports for a week or two, then tighten to -all once you're confident every legitimate sender is covered. 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 the full three-protocol walkthrough, see the SPF, DKIM, and DMARC setup guide.

Where SPF records go wrong

Roughly ranked by how often they bite.

Publishing two records. RFC 7208 §3.2 says a domain must have exactly one. Two produce a permerror, which DMARC treats as a fail; if you have one you added last year and one your ESP generated, merge them.

Blowing the 10 DNS lookup limit. This is the big one. RFC 7208 §4.6.4 caps the DNS lookups a single evaluation can trigger at ten. Every include:, a, mx, exists, and redirect counts against it, while ip4 and ip6 cost nothing. Chain four or five ESPs together, each with its own nested includes, and you sail past the cap into a permerror that fails SPF outright. The fixes are consolidating vendors, replacing includes with literal IPs (flattening), or splitting senders across subdomains with shorter records each.

Reaching for -all too early. A hard fail on a record missing a legitimate sender bounces real mail: password resets, calendar invites sent from a laptop on hotel Wi-Fi, the CRM that quietly started forwarding last Tuesday. Roll out on ~all, move to -all after a clean DMARC report.

Forgetting subdomains. SPF is per-domain. If yourdomain.com has a record and notifications.yourdomain.com doesn't, mail from the subdomain evaluates to none and DMARC may fail it for lack of any SPF result. Publish a record on each sending subdomain, or set a DMARC sp= policy that matches what you actually intend.

Expecting SPF to survive forwarding. It usually doesn't. A forwarding server changes the connecting IP while keeping the original envelope sender, so the check fails at the forwarding hop through no fault of yours. DKIM survives forwarding because it signs the message itself, which is exactly why DMARC accepts either one passing with alignment. If a chunk of your mail travels through mailing lists or corporate forwarders, SPF alone will look broken and DKIM is what saves you.

One last habit worth keeping: distrust old documentation. SPF changed in 2014 when RFC 7208 obsoleted RFC 4408, and the operational expectations changed again in 2024 with the bulk sender rules. A 2015 blog post confidently explaining the SPF record type is not a small error to inherit; check anything older than a couple of years against the RFC before you act on it, then go look at what your own domain actually publishes today. Most people are surprised.