SPF Explained: Why a Pass Does Not Always Mean Safe
SPF is the oldest email authentication standard and the most misunderstood. It checks a different address to the one your recipient sees, and it breaks in ways nobody notices until mail stops arriving.
Sender Policy Framework was the first serious attempt to answer a simple question: is this server allowed to send email for this domain? Two decades later, it is on almost every business domain, and it is broken on a surprising number of them. Worse, even a perfectly configured SPF record does not prove what most people assume it proves. Here is what SPF really checks, how it fails, and why it only becomes useful when DMARC ties it to the address your recipient sees.
What SPF actually does
An SPF record is a DNS TXT record on your domain that lists the servers and services permitted to send email for it. When a receiving server gets a message, it looks up the SPF record for the domain in question and checks whether the connecting server’s IP address is on the list.
yourcompany.co.za TXT "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all"That record says: Microsoft 365’s servers may send for us, Mailchimp’s servers may send for us, and anything else should fail. The include: mechanism pulls in each provider’s own published list, so you do not have to track their IP addresses yourself.
It checks a different address to the one you see
This is the fact that changes how you think about SPF. Every email has two sender addresses.
- The envelope sender, also called the Return-Path or MAIL FROM. This is used by servers during delivery and is where bounces go. Recipients almost never see it.
- The header From. This is the address shown in the recipient’s inbox.
SPF authenticates the envelope sender. It says nothing about the header From. A criminal can send from their own server, use their own domain as the envelope sender, authorise that server in their own SPF record, and write your address in the visible From line. SPF passes. The recipient sees your name.
This is the gap DMARC closes with alignment. Under DMARC, an SPF pass only counts if the envelope sender domain matches the header From domain. In relaxed alignment, the default, a subdomain such as bounce.yourcompany.co.za matches yourcompany.co.za. In strict alignment the domains must be identical.
Why third-party senders so often fail alignment
Many platforms send email on your behalf using their own domain as the envelope sender. Your newsletter may pass SPF perfectly, but for the platform’s bounce domain, not yours. Under DMARC that is an unaligned pass, and it counts for nothing.
The fix varies by platform. Some let you set a custom return-path on your own subdomain. Others cannot align SPF at all, and rely on DKIM signing with your domain instead. This is why a DMARC rollout has to look at each sending service individually, and why DKIM usually carries more of the load than SPF.
The ten lookup limit that breaks records silently
SPF evaluation is capped at ten DNS lookups. Every include, a, mx, ptr, exists and redirect counts, and so does every lookup inside the records those includes point to. The limit exists to stop SPF being used to overload DNS, and exceeding it produces a permanent error. Receivers treat that as an SPF failure for every message.
It is easy to hit. Microsoft 365, a CRM, a helpdesk, a newsletter platform, an accounting package and a website form service can each add one or more lookups, and some providers’ records contain nested includes of their own. The record looks tidy in DNS and quietly fails everywhere.
| Common SPF fault | Effect | Fix |
|---|---|---|
| Two records starting with v=spf1 | Permanent error, SPF fails for all mail | Merge into one record |
| More than ten lookups | Permanent error, SPF fails for all mail | Remove unused includes, move senders to subdomains, or use a maintained flattening service |
| Includes for services no longer used | Wasted lookups, wider attack surface | Audit against real sending data and remove |
+all at the end | Any server in the world passes | Replace with ~all or -all |
ptr mechanism | Slow, unreliable and deprecated | Replace with explicit includes or IP ranges |
Hard fail or soft fail?
The mechanism at the end of the record tells receivers what to do with servers that are not listed. -all is a hard fail, ~all a soft fail, ?all neutral. Long arguments are had over which is correct. Under an enforced DMARC policy, the distinction matters much less, because DMARC makes the delivery decision. Some receivers act on an SPF hard fail before DMARC is evaluated, which can cause problems with forwarded mail, so a soft fail combined with an enforced DMARC policy is a common and defensible choice. What is never defensible is +all, which authorises the entire internet.
Where SPF breaks: forwarding
When a message is forwarded, the forwarding server passes it on from its own IP address. That address is not in your SPF record, so SPF fails at the final destination even though the original message was genuine. There is no fix for this within SPF. It is one of the main reasons DKIM, which survives forwarding when the message is not modified, matters so much for DMARC.
A practical SPF checklist
- Publish exactly one SPF record per sending domain.
- List only services that genuinely send for that domain, confirmed against DMARC report data rather than memory.
- Count lookups including nested ones, and keep a margin below ten.
- Give parked domains that never send email a record that authorises nothing:
v=spf1 -all. - Rely on DMARC for enforcement, and on DKIM for mail that is forwarded.
You can see your current record and its top-level lookup count with our DMARC checker.
The short version
- SPF lists the servers allowed to send for a domain, but it checks the envelope sender, not the address recipients see.
- An SPF pass is only meaningful under DMARC, when the passing domain aligns with the From address.
- More than ten DNS lookups or more than one record breaks SPF for every message.
- SPF fails on forwarding, which is why DKIM carries most of the weight for DMARC.
Frequently asked questions
Should our SPF record end in -all or ~all?
Once DMARC is enforced, the choice matters less than people think, because DMARC applies the policy. Many practitioners keep ~all to avoid some receivers rejecting mail on SPF alone before DMARC is evaluated. What matters far more is that the record is accurate and within the lookup limit. Never use +all.
Can a domain have two SPF records?
No. More than one record starting with v=spf1 causes a permanent error, and SPF fails for every message. If two services each tell you to add an SPF record, merge their includes into a single record.
What is SPF flattening?
Flattening replaces include mechanisms with the IP addresses they resolve to, which reduces lookups. The risk is that providers change their IP ranges and a flattened record goes out of date silently. If you flatten, it must be refreshed automatically, not done once by hand.
Does SPF protect against someone using our domain in the From line?
Not on its own. SPF checks the envelope sender, not the visible From address. Only DMARC alignment connects the two.
Sources and standards
- RFC 7208: Sender Policy Framework (SPF). The IETF specification for publishing and evaluating SPF records.
- RFC 7489, section 3.1: Identifier Alignment. How DMARC decides whether the SPF and DKIM domains match the From domain.
MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.
Keep reading
What Is DMARC, and Why It Is No Longer Optional
DMARC is the record that decides whether criminals can send email as your business. Here is how it works, what the three policies really do, and why monitoring alone protects nothing.
DKIM Explained: The Signature Behind Trusted Email
DKIM is the part of email authentication that survives forwarding and does most of the work for DMARC. It is also the part most often left signing with someone else's domain.
Rolling Out DMARC Safely: From p=none to p=reject
Enforcement is where DMARC protects you and where it can hurt you. This is the sequence that gets a domain to p=reject without blocking the invoices, statements and bookings your business depends on.
Find out where your domain stands
Send us your domain. We will review your DMARC, SPF and DKIM set-up, map the services sending as you, and tell you plainly what it would take to reach enforcement. No charge and no obligation.