SPF is the oldest of the three email authentication standards, and it's usually the first thing to break when a cold email operation adds a second or third sending tool. This guide covers what SPF actually checks, how to write a record for a dedicated cold-outreach domain, and the specific failure modes that quietly kill deliverability without ever throwing an obvious error.
Sender Policy Framework is a DNS TXT record that lists which mail servers are allowed to send email on behalf of your domain. When a receiving server gets a message claiming to be from yourdomain.com, it looks up that domain's SPF record and checks whether the sending server's IP address is on the authorized list. If it's not, SPF returns a "fail" — one input among several (alongside DKIM and DMARC) that receiving servers weigh when deciding whether a message reaches the inbox, goes to spam, or gets rejected outright.
SPF alone doesn't determine deliverability. It's a building block that DMARC depends on, and a domain with no SPF record at all sends a strong signal to modern spam filters that the domain hasn't been properly configured for sending — a red flag independent of anything about the message content itself.
A basic SPF record for a domain sending through one platform looks like this:
Breaking that down: v=spf1 declares the record version. include: pulls in another domain's authorized sender list — in this case, Smartlead's own SPF record, which lists the IP ranges Smartlead sends from on your behalf. ~all is the qualifier at the end, telling receiving servers what to do with mail from IPs not on the list — ~all (soft fail) is the standard choice for cold email; -all (hard fail) is stricter and better reserved for domains where you're fully confident every sending source is accounted for.
| Qualifier | Meaning | When to use it |
|---|---|---|
-all | Hard fail — reject mail from unlisted sources | Mature domains with a fully mapped sending infrastructure |
~all | Soft fail — mark as suspicious, don't reject outright | Standard choice while a domain's sending sources may still change |
?all | Neutral — no policy stated | Rarely appropriate; provides no real protection |
+all | Pass everything, including unlisted sources | Never use this — it defeats the purpose of SPF entirely |
For a domain dedicated purely to cold email sending through one platform:
@ (or your root domain, depending on the provider's convention)Verify before you warm up. Don't start the warmup process until you've confirmed the SPF record resolves correctly with an external lookup tool. Warming up a mailbox on top of broken authentication wastes the entire warmup period — you'll need to restart the clock once the DNS is actually fixed.
This is the single most common way SPF fails for growing operations. The SPF specification caps every check at 10 DNS lookups, and several mechanisms count against that limit — not just include, but also a, mx, ptr, and exists mechanisms, and each nested include can itself trigger further lookups if the included domain's own SPF record has includes of its own.
A domain that starts with one sending platform and later adds a CRM, a helpdesk, a marketing tool, and a transactional email service can hit this limit surprisingly fast, especially since some vendors' own SPF records are nested two or three includes deep before you even add your own. Once the limit is exceeded, the entire SPF check returns a permerror — which most receiving mail servers treat as an outright failure, not a partial pass. The specific tool that was actually sending the message doesn't matter at that point; the whole record is broken for every sender on it.
For a dedicated cold email domain, the fix is straightforward: keep the domain narrow. Don't add every tool your business uses to the sending domain's SPF record — a domain used purely for cold outreach only needs the cold email platform's include and, if applicable, a warmup tool's include. Route other business email (support, billing, marketing newsletters) through separate domains or subdomains with their own SPF records.
A domain can only have one SPF record. If you (or a previous developer, or a plugin, or a second tool's setup instructions) add a second TXT record starting with v=spf1, the domain now has two SPF records, which is explicitly invalid per the specification and causes a permerror on every check — again treated as a fail by most receiving servers, regardless of what either individual record actually said.
This happens most often when adding a second sending tool without checking whether an SPF record already exists — the setup instructions for the new tool say "add this TXT record," and if you follow them literally without merging into the existing record, you end up with two. The fix is always to combine every sending source into a single record with multiple include mechanisms, never to have separate records for separate tools.
SPF checks the sending server's IP against an authorized list. DKIM checks a cryptographic signature attached to the message, proving it wasn't altered in transit and genuinely came from a server holding the matching private key. DMARC sits above both, requiring that at least one of them (SPF or DKIM) not only pass but also "align" — the domain in the SPF/DKIM check must match the domain shown in the message's visible From address.
Because DMARC alignment can be satisfied by either mechanism, a domain with correctly configured DKIM but a broken SPF record can sometimes still pass DMARC. Relying on that as a fallback isn't a good practice, though — both mechanisms should be correctly configured independently, since a single point of failure in either one still increases risk. See our DKIM setup guide and DMARC configuration guide for the other two pieces of the authentication stack.
Related guides