SPF for cold email

SPF is the oldest of the three email authentication records, and it is still the one teams get wrong most often. A broken SPF record does not fail loudly. Mail keeps sending. It just stops landing. Here is how SPF works, how to set it up correctly for cold email, and the two rules that break most setups: the exactly-one-record rule and the 10 DNS lookup limit.

What SPF is

SPF (Sender Policy Framework) is a TXT record on your sending domain. It lists the servers that are allowed to send mail claiming to be from that domain. When a receiving server gets a message from you@yourdomain.com, it looks up the SPF record on yourdomain.com and checks whether the connecting server is on the list.

A minimal SPF record for a Google Workspace domain looks like this:

yourdomain.com  TXT  "v=spf1 include:_spf.google.com ~all"

Three parts: the version tag v=spf1, one or more mechanisms that authorize senders (include:_spf.google.com pulls in Google’s server list), and a policy for everything else (~all).

Why it matters for a cold email launch

• Without SPF, anyone can spoof your domain. Receivers know this, so unauthenticated mail starts at a trust deficit.
• Google and Yahoo require it. Since February 2024, bulk senders must pass SPF or DKIM at minimum, and DMARC requires at least one of them to pass with alignment. See the bulk sender requirements guide.
• A broken record is worse than a missing one. Two SPF records, or a record that exceeds the lookup limit, returns a permanent error. Some receivers treat that as a failure on every message you send.

For a cold email campaign, that means lower reply rates on day one and no obvious error message telling you why.

How to set it up

Step 1: Find every service that sends mail for the domain. For a cold email sending domain this is usually just the inbox provider (Google Workspace or Microsoft 365). Marketing tools, help desks, and billing systems send from your root domain, not your outbound domains, which is one more reason to keep cold email on separate domains.

Step 2: Publish one TXT record at the domain root.

Google Workspace:

v=spf1 include:_spf.google.com ~all

Microsoft 365:

v=spf1 include:spf.protection.outlook.com ~all

Step 3: Verify. Look up the record and confirm there is exactly one, it starts with v=spf1, and the lookup count is under 10. The SPF checker does this in one pass.

The exactly-one-record rule

A domain must publish exactly one SPF record. Two records, even if both are valid on their own, produce a permerror and receivers ignore both. This happens constantly in practice: a domain registrar adds a default SPF record, then someone adds a second one for Google Workspace instead of editing the first.

Wrong:

"v=spf1 include:_spf.google.com ~all"
"v=spf1 include:spf.protection.outlook.com ~all"

Right:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Merge everything into one record. One v=spf1, one all at the end.

The 10 DNS lookup limit

SPF evaluation is capped at 10 DNS lookups. Every include:, a, mx, exists, and redirect mechanism costs one lookup, and includes are recursive: include:_spf.google.com costs one lookup plus every lookup inside Google’s record. Cross 10 and the result is a permerror.

Fresh cold email domains with one provider rarely hit the limit. Root domains that accumulated years of tools do. If you are over:

• Remove includes for services you no longer use. This fixes most cases.
• Move bulk tools to their own subdomains with their own SPF records.
• As a last resort, flatten the record: replace includes with the underlying ip4:/ip6: ranges. Flattening works but goes stale when the provider changes IPs, so only do it with a tool or process that keeps it updated.

~all vs -all

The final mechanism sets the policy for servers not on the list:

• ~all (softfail): unauthorized mail is suspect but not hard-rejected. The safe, standard choice.
• -all (hardfail): unauthorized mail should be rejected. Stricter, and correct once you are certain the record lists every sender.
• ?all or +all: effectively no policy. +all authorizes the entire internet to send as you. Never ship either.

For cold email domains with a single provider, ~all or -all are both fine. What matters is that mail passes, not which failure mode you chose.

Common mistakes

1. Two SPF records. The single most common permerror. Merge them.
2. More than 10 lookups. Usually caused by stale includes on an old root domain.
3. +all or a missing all. An open or absent policy tells receivers you do not control your own domain.
4. SPF on the wrong host. The record goes on the domain in the return-path. If you send from mail.yourdomain.com, that subdomain needs its own record.
5. Typos in the include. _spf.google.com, not spf.google.com. One character and the whole record fails.
6. Assuming SPF alone is enough. SPF breaks on forwarding and does not sign content. You need DKIM and DMARC with it.

FAQ

Does SPF need to be on every sending domain? Yes. Each cold email sending domain needs its own SPF record. There is no inheritance from the root brand domain.

How long do SPF changes take to apply? DNS propagation, so anywhere from minutes to the TTL on the record. Most changes are live within an hour.

Can I have an SPF record with no includes? Yes, if you send from fixed IPs: v=spf1 ip4:203.0.113.10 -all. Uncommon for cold email, where the inbox provider’s include is the norm.

Does SPF pass mean my mail is authenticated? Only partly. DMARC also checks that the SPF domain aligns with the From domain. Passing SPF on an unaligned domain does not help your DMARC result.

SPF is one of 16 checks OutboundQA runs before a launch. Run the SPF checker for one domain, or check the full cold email infrastructure checklist for everything else that has to be true before you send.