What is SPF?
SPF — the Sender Policy Framework — is the oldest of the three email authentication standards. The idea is simple: you publish a list, in DNS, of the servers that are allowed to send email for your domain. When a message arrives, the receiving server looks up that list and checks whether the server that just delivered the message is on it.
Simple — yet SPF is also the most widely misunderstood of the three, because the domain it checks is not the one you think. Understanding that single distinction explains almost everything about SPF: what it protects, what it misses, and why DMARC had to be invented on top of it.
The two From addresses — and which one SPF checks
Every email carries two sender identities, not one.
The header From is the address you see in your mail client — From: [email protected]. It is part of the message content, and whoever composed the message can set it to anything at all.
The envelope-from — also called the Return-Path, bounce address or MAIL FROM — is the address the sending server announces during the SMTP conversation, before the message content is even transmitted. Its job is to tell receivers where to send bounces. Your recipients never see it unless they go digging through raw headers.
SPF checks the envelope-from. The receiving server takes the domain from the envelope-from address, fetches that domain's SPF record, and checks whether the connecting IP address is authorised by it. The visible From header plays no part in the check whatsoever.
Hold onto that fact — it is the key to the final section of this article.
Anatomy of an SPF record
An SPF record is a single TXT record published at the root of your domain. A realistic example:
example.com. TXT "v=spf1 include:_spf.google.com include:spf.mailer.example.net ip4:203.0.113.10 ~all"Reading left to right: mail for example.com may come from any server Google authorises, any server the email provider behind the second include: authorises, or the single IP address 203.0.113.10 — and anything else should be treated with suspicion.
The building blocks are called mechanisms:
| Mechanism | What it authorises |
|---|---|
ip4: / ip6: | A specific IP address or CIDR range. Explicit and cheap. |
include: | Everything authorised by another domain's SPF record — how you delegate to Google Workspace, Microsoft 365 or an email service provider. |
a / mx | The IP addresses behind the domain's A/AAAA or MX records. |
all | Everything not matched above. Always last, always with a qualifier. |
The qualifier in front of all sets the tone for the whole record. ~all (softfail) says "anything else is probably not us — be suspicious". -all (fail) says "anything else is definitely not us — refuse it". The hard fail sounds stronger, but most receivers treat the two similarly in practice, and once DMARC is in place it is your DMARC policy — not the SPF qualifier — that decides the fate of failing mail. ~all is the safer everyday choice.
The 10-DNS-lookup limit
The SPF specification caps evaluation at ten DNS lookups per check. Every include:, a, mx, exists: and redirect= costs one — and includes count recursively: include:_spf.google.com pulls in Google's own nested includes, each of which counts against your ten.
Go over the limit and the result is a permerror — a permanent evaluation error. Many receivers treat a permerror as though SPF never passed, so a record that grew one include: too many can quietly break authentication for every message you send.
This is not a rare accident; it is the natural fate of a record that accretes services over the years. The CRM, the helpdesk, the newsletter platform, the billing tool — each asks you to "just add our include". Three or four SaaS includes, each with its own nesting, and you are at the cliff edge.
Not sure where you stand? Run your domain through the free SPF checker — it fetches your live record and shows you exactly what it authorises.
Why SPF alone can't stop spoofing
SPF has two structural gaps, and both follow directly from what it checks.
It checks a domain your readers never see. A phisher does not need to pass SPF for your domain. They send from their own server, use their own domain in the envelope-from — passing their own SPF flawlessly — and put From: [email protected] in the header. SPF is satisfied; the human is deceived.
It breaks on forwarding. When a message is forwarded — a university address relaying to Gmail, an old mailbox redirecting to a new one — the final hop is delivered by the forwarder's server, whose IP address is not in your SPF record. Your perfectly legitimate message now fails SPF through no fault of your own. Why SPF fails on forwarded mail examines the mechanics in detail and covers the mitigations available.
The fix for the first gap is alignment: DMARC requires that the domain that passed SPF matches the visible From domain, finally tying the check to what the reader actually sees. We unpack exactly how that works in DMARC alignment explained. The fix for the second gap is DKIM, whose cryptographic signature travels inside the message and survives forwarding intact.
Where SPF fits
SPF is necessary but not sufficient. Publish it, keep it under the lookup limit, and treat it as one leg of a three-legged stool: SPF says which servers may send as you, DKIM proves the message was not tampered with, and DMARC ties both checks to the From address your recipients see — then reports back on the results from mailboxes around the world.
Checking your SPF record takes seconds — then make sure DKIM and DMARC complete the picture.