SPF Explained: What It Proves and Why It Fails

SPF is a DNS record that lists which servers are allowed to send email for a domain. A receiving server checks the connecting IP address against that list and records a result: pass, fail, softfail or neutral. It is useful and almost every domain should have one, but it checks the delivery path, not the sender the reader sees, and that gap explains most of the confusion around it.

If you arrived here because of a bounce, a “spf=fail” header or a warning about “~all” against “-all”, this guide covers what SPF proves, what it ignores, how to write a record that works and why legitimate email so often fails it. Standards and provider instructions were checked against RFC 7208 and the providers’ own pages on 8 October 2026.

At a Glance: Who Needs to Care About SPF

What SPF Actually Checks, and What It Ignores

SPF is evaluated during delivery. The receiving server takes the IP address of the server connecting to it, looks up the SPF record in DNS for the domain in the envelope sender (the Return-Path, also called MAIL FROM or the bounce address) and compares the two. RFC 7208 also checks the HELO name the sending server announces, and recommends checking it first.

It does not read the message. It ignores the subject, the body and the visible From address. That is the central point: a message can carry a From address of billing@yourbank.com while the envelope sender is a completely different domain that passes SPF without trouble. SPF has answered a question about the server, not about the person.

This is why DMARC exists. DMARC adds the missing check, that the domain which passed SPF (or DKIM) matches the From domain. Without that alignment step, an SPF pass proves very little about who the message appears to come from.

Anatomy of an SPF Record

An SPF record is a single DNS TXT record on your domain, beginning with v=spf1. This is an annotated example using reserved documentation addresses:

Put together, the published record reads: v=spf1 ip4:203.0.113.10 include:_spf.example.net ~all

Mechanisms

Qualifiers

Each mechanism can carry a prefix that decides what happens on a match. With no prefix, + (pass) is assumed.

A receiver can also return none (no SPF record found), temperror (a temporary DNS problem) or permerror (the record cannot be interpreted, for example because there are two records or too many lookups).

~all or -all: Which Should You Use?

This is the question behind many searches, and the providers do not agree with each other. As of 8 October 2026:

The practical difference is smaller than the debate suggests. Most receivers do not bin mail on an SPF result alone; they weigh it with DKIM, DMARC and their own reputation data. Where it does matter is DMARC. Microsoft explains that with ~all a DMARC policy can effectively treat SPF softfails as unenforced for unsigned mail, so -all gives DMARC something firmer to act on.

A sensible rule: use ~all while you are still discovering senders, because a missed service then lands in spam rather than bouncing. Once DMARC reports show everything legitimate is covered, move to -all if your provider recommends it. Do not use +all, which authorises the entire internet, and note that ?all offers no protection.

The 10 DNS Lookup Limit

RFC 7208 limits an SPF evaluation to 10 DNS lookups. The terms that count are include, a, mx, ptr, exists and redirect, including those inside included records. ip4, ip6 and all do not count. Go over and the result is permerror, which receivers usually treat as an SPF failure.

The limit is easy to hit because each service you add brings its own includes, and those can include others. Microsoft’s own guidance repeats the warning that more than 10 lookups causes a permanent error. The RFC also says to limit “void” lookups, ones that return nothing or a non-existent domain, to two.

Staying under the limit

• Remove services you no longer use. Old newsletter tools and abandoned CRMs are the usual culprits.
• Prefer ip4 and ip6 where a service gives you fixed addresses.
• Use subdomains. Send marketing mail from news.example.com with its own SPF record, so the lookups are not shared with your main domain.
• Be careful with flattening. Replacing includes with raw IP lists saves lookups, but providers change their addresses. A flattened record that is not refreshed automatically will quietly go stale and start failing real mail.
• Avoid ptr. It is slow, unreliable and discouraged by the standard.

RFC 7208 also advises keeping a published record within 512 octets, so that the DNS answer fits comfortably in a single response. Long lists of IP addresses can run into that before the lookup limit.

One Record Only

A domain must have no more than one SPF record. If you publish two TXT records that both start v=spf1, receivers return permerror and SPF fails for every message. Microsoft states that only one SPF record is allowed per domain or subdomain, and lists multiple records as a cause of permerror.

This usually happens when you add a second service and paste its suggested record alongside the first. The correct fix is to merge them into one record:

Each subdomain that sends mail needs its own record too. Google’s guidance makes the same point that each domain must have its own SPF record.

Why Legitimate Email So Often Fails SPF

SPF assumes the server delivering the message is the one the domain owner listed. Several ordinary situations break that assumption.

Envelope rewriting such as SRS helps forwarded mail pass SPF, but it adds complexity and does not solve the identity problem. DKIM, DMARC and ARC are the complementary tools, which is why the next guides in this series exist.

Why an SPF Pass Does Not Make a Message Trustworthy

An SPF pass means the delivering server was allowed to send for the domain in the envelope sender. Anyone can register a domain, publish a valid SPF record and send mail that passes. Spammers and phishers do exactly this. A pass says nothing about intent, honesty or whether the visible From address is genuine.

That is also why checking SPF alone is a weak defence for users. The useful question is whether the passing domain matches the From address, and that is DMARC’s job.

How to Check Your SPF Record

1. Look up the record. From a terminal, run dig +short TXT yourdomain.com and find the line beginning v=spf1. There should be exactly one.
2. Count the lookups. Add up every include, a, mx, exists and redirect, then the lookups inside each include. Free online SPF checkers do this for you.
3. Send a test message to a Gmail account, open Show original and look for spf=pass and the domain it passed for.
4. Read your DMARC reports. They show which sources send as your domain and whether SPF passed and aligned, which is the best way to find forgotten senders.

Where SPF Fits, and Where It Stops

SPF dates from the early 2000s, when the aim was modest: let a domain say which machines may send its mail. It does that job well, and blocks low-effort abuse and misconfigured sending. It was not designed to establish identity, and email infrastructure has grown far more complex around it.

Gmail and Yahoo now expect bulk senders to have SPF and DKIM and a DMARC policy, so SPF is a requirement rather than an option. Treat it as the foundation, not the finish.

Frequently Asked Questions

What does SPF stand for?

Sender Policy Framework. It is defined in RFC 7208, which lets a domain publish the servers allowed to send its email.

What is the difference between ~all and -all?

~all is a softfail: mail from unlisted servers is probably unauthorised but is normally accepted and marked. -all is a hard fail: such mail is unauthorised. Google recommends ~all for Workspace and Microsoft recommends -all for Microsoft 365, so follow your provider and move to -all once DMARC reports show you have covered every sender.

Why does my SPF pass but DMARC still fail?

Because DMARC needs the domain that passed SPF to match the From domain. If a third-party service uses its own bounce domain, SPF passes for that domain and not yours. Fix it with a custom return-path or by signing with DKIM using your domain.

Can I have more than one SPF record?

No. Publish one record per domain and merge all your services into it. Two records cause a permerror.

What happens if I exceed 10 DNS lookups?

The check returns permerror and receivers will usually treat the message as failing SPF. Remove unused services, use subdomains for separate senders or flatten carefully.

Does SPF stop spoofing of the From address?

Not by itself. SPF checks the envelope sender, not the From header. Pair it with DKIM and a DMARC policy to protect the address people see.

Do I need SPF on a domain that sends no email?

Yes, it is worth publishing v=spf1 -all, which says no server may send for the domain. Combine it with a DMARC p=reject policy to make the domain a poor target for spoofing.

The Bottom Line

SPF answers a narrow question, which servers may send for this domain, and answers it reliably when the record is tidy. Keep one record, stay under 10 lookups, list only the services you really use and pick ~all or -all on purpose. Then let DKIM and DMARC do what SPF cannot.

Sources: RFC 7208; Microsoft Learn: set up SPF; Google Workspace: set up SPF; Fastmail: domain set-up. No affiliate links in this article.