SPF is a DNS record listing who is allowed to send email as your domain. It is the easiest of the three authentication records to publish and the easiest to break, because the ways it breaks do not look like errors: the record is present, the syntax is valid, and authentication still fails.
What to look at, in order
| Check | What good looks like |
|---|---|
| Record exists | Exactly one TXT record starting v=spf1 |
| Number of records | One. Two SPF records is a permanent failure, not a merge |
| DNS lookups | Ten or fewer. Eleven means every message fails SPF |
| Every sender included | Your mailbox provider, your sequencer, your ESP, your invoicing and support tools |
| Ending mechanism | ~all (softfail) or -all (hardfail). Never +all |
The three failures that actually happen
Two SPF records. Almost always because a new tool’s setup guide said “add this TXT record” and someone did, alongside the existing one. The specification allows exactly one; two produces a permanent error and SPF fails for every message. The fix is to merge the include: mechanisms into a single record, not to pick one.
Too many DNS lookups. Each include, a, mx and redirect costs a lookup, and includes nest: one provider’s include can consume four on its own. Past ten, evaluation stops and returns a failure. This is the most common silent SPF break in a stack that has grown, because nothing changes at your end: you add a tenth tool and yesterday’s working record stops working. Fix by removing includes for services you no longer use, dropping a and mx mechanisms you do not need, and using flattening only as a last resort. A flattened record goes stale when a provider changes IPs.
A missing sender. Your cold email platform authenticates, but your CRM’s notification emails or your invoicing tool do not, so some of your mail fails and the domain’s aggregate reputation suffers. List everything that sends as your domain, not just the outbound stack.
What SPF does not do
Two things worth being clear about. SPF checks the envelope sender, not the From address a recipient sees, which is why it cannot stop display-name spoofing on its own, that is DMARC’s job with DKIM. And a passing SPF record does not make cold email land: authentication is a floor, not a lever. How all three records fit together.
Hardfail or softfail
~all tells receivers to treat unauthorised mail with suspicion; -all tells them to reject it. For a cold email sending domain, -all is the stronger signal and the right end state, but only once you are certain every sender is listed, because anything you forgot will be rejected outright. Publish ~all, watch for a fortnight, then tighten.
Per-domain, every time. If you send from 12 lookalike domains, each needs its own correct record. This is where bulk DNS management stops being a convenience and starts being the thing that prevents a silent failure across an estate. Managing records across many domains.
Next: checking DKIM, checking DMARC, or grading all four records at once.
Frequently asked questions
How do I check my SPF record?
Look up the TXT records for your domain and find the one starting v=spf1. Confirm there is exactly one, that it consumes ten or fewer DNS lookups, that every service sending as your domain is included, and that it ends in ~all or -all.
Can I have two SPF records?
No. The specification allows exactly one, and two produces a permanent error that fails SPF for every message. Merge the include mechanisms into a single record rather than choosing between them.
What is the SPF ten-lookup limit?
Each include, a, mx and redirect mechanism costs a DNS lookup, and includes nest. Past ten lookups, evaluation stops and returns a failure, which is why adding a tenth tool can silently break a record that worked yesterday.
Should SPF end in ~all or -all?
-all is the stronger end state for a cold email domain, but only once every sender is listed, because anything you forgot gets rejected. Publish ~all, monitor for two weeks, then tighten.
Does a passing SPF record improve deliverability?
It removes a reason to be filtered rather than adding a reason to be delivered. Authentication is a floor, not a lever.