Cold email playbook
Why SPF records matter for cold senders
Secondary domains, multi-tool stacks, the 10-lookup ceiling, and the silent ways SPF tanks a sending operation.
1. Why SPF moves the needle on cold
Cold email is the hardest deliverability environment. You're sending to people who didn't opt in, and providers grade you harder than anyone else.
SPF is a baseline filter, not a tiebreaker. Fail it and none of your other work matters. Subject line, copy, warm-up history, none of it gets a fair look.
It's also the cheapest fix in the stack. Two minutes in DNS, zero ongoing cost.
2. How Gmail and Outlook treat SPF
Since February 2024, Gmail and Yahoo require SPF for senders hitting more than 5,000 messages per day. Below that, they technically allow it, but they downweight you.
- SPF pass + DKIM pass + aligned DMARC: fair shot at the inbox. Content and reputation decide the rest.
- SPF pass but unaligned: usable, but DMARC won't help. Spoof protection drops.
- SPF softfail (~all): delivered but treated with suspicion. Most cold tools' default.
- SPF hardfail (-all): Outlook rejects it. Gmail spam-folders it.
- No SPF record: spam at Gmail, hard reject at Outlook. Done.
Outlook is stricter than Gmail on SPF. B2B audiences in finance, legal, or enterprise IT are Outlook-heavy. That's where bad SPF costs you the most.
3. SPF setup for secondary domains
Each secondary domain needs its own SPF record. Google Workspace:
v=spf1 include:_spf.google.com ~all
Microsoft 365:
v=spf1 include:spf.protection.outlook.com ~all
8 secondaries with 3 inboxes each means 8 separate records to keep healthy. Drift on one doesn't look like a domain problem. It looks like a slow leak across your whole pipeline.
4. The 10-lookup ceiling
Every include: triggers a DNS lookup at evaluation time. The RFC caps you at 10 total. Hit 11 and the record returns PermError, same as having no SPF.
Includes are recursive. _spf.google.com alone resolves to multiple nested lookups. Two or three providers and you're close.
- Remove includes for tools you no longer use. Most operators have at least one zombie.
- Don't add includes for services not in your actual mail path.
- If you're over the limit, use an SPF flattening service (EasyDMARC, DMARCLY) to resolve nested includes into a static IP list.
- Use a checker that counts lookups, not just one that confirms "record found."
5. ~all vs -all for cold senders
- ~all (softfail): treat unauthorized senders as suspicious but accept. Most setups default to this.
- -all (hardfail): reject unauthorized senders. Stricter, safer.
- ?all (neutral): useless. Skip it.
- +all: allows anyone to spoof you. Never.
Start new secondaries at ~all while testing connections. Once the domain is stable and you know exactly which servers are in the path, tighten to -all.
6. SPF alignment
SPF passing isn't enough. For DMARC to work, SPF must be aligned: the domain in the Return-Path header must match your From address domain.
SMTP relays break this. A tool might pass SPF using its own Return-Path domain (bounce.tool.com) while sending from you@yourco.com. SPF passes. Alignment fails. DMARC fails.
Check the headers of a real test send. In Authentication-Results you want both spf=pass and dmarc=pass. If DMARC fails despite SPF passing, alignment is the issue.
7. Silent failures that kill reply rate
SPF breaks without announcing itself. Reply rates drift down for days before you can pinpoint it. The usual causes:
- Provider switch. Moved a secondary from Workspace to Office 365, old include still in the record.
- Domain handoff. New secondary set up with inboxes, SPF never added. Mail sends, lands in spam.
- Lookup overflow. Added one more tool, pushed from 10 to 11 lookups. Everything fails.
- Duplicate record. Someone added a second SPF "to be safe." Two records means both fail.
- Typo on batch setup. One of 10 new secondaries has include:_spf.google.cm instead of .com. Silent failure, single domain.
None of these break at the moment they happen. The damage compounds for days before metrics show it.
8. Agency setup: SPF across client domains
20 clients with 5 secondaries each is 100 SPF records. What works at scale:
- One template per provider. Google Workspace clients get the same record. Office 365 clients get theirs. No per-client customization.
- Document DNS ownership. When something breaks at 11pm, you need to know who controls the DNS for that domain.
- Monitor continuously. Quarterly audits catch problems that have been live for 11 weeks. Continuous monitoring catches them in hours.
- Alert per inbox, not per domain. A domain-level failure affects every inbox on it. The alert should be tied to the sender.
9. Operator FAQ
Tool SMTP relay or send through Google/Microsoft?
Google/Microsoft when possible. Alignment is clean by default. With tool relays you have to verify alignment manually.
Does SPF stop spoofing on its own?
No. SPF validates the envelope sender. The visible From header can still be spoofed. You need DKIM and DMARC too.
How fast do SPF changes propagate?
5 to 30 minutes on Cloudflare and modern registrars. Older registrars with high TTLs can take up to 24 hours.
One SPF record for multiple secondaries?
No. Each domain needs its own record in its own DNS. Same value, separate records.
SPF on a domain that only receives, not sends?
Yes. Publish v=spf1 -all. Blocks attackers from spoofing you. Same for parked domains.
Subdomains used for cold?
SPF doesn't inherit. mail.yourco.com needs its own record. Forgetting this means silent failures on every inbox in that subdomain.
Does SPF still matter after the domain is warm?
Yes. Reputation gives you grace on content, not on authentication. A warmed inbox with broken SPF still gets filtered.
What's the right monitoring cadence?
Continuous. SPF breaks at random points: registrar updates, DNS migrations, a teammate cleaning up. You want to know within an hour, not a week.