A cold email domain setup that holds up has five parts: you never send from your main domain, every sending domain has exactly one SPF record, a DKIM key and a DMARC record, each domain carries a capped number of cold emails a day, the domain has its own nameservers and a real website, and you check all of it before the first send instead of after the replies stop. That’s the whole recipe. The rest of this page is how to set each part up, the numbers I run with, and what actually went wrong on my own domains in 2026, because none of it was the copy.
Last checked against the provider docs and RFCs on 20 October 2026.
Check your domain first
Before you change anything, run the domain you send from (or plan to send from) through the free cold email domain checker. It reads public DNS and checks six things: whether the domain can receive replies (MX), whether it has exactly one SPF record and how many DNS lookups that record costs, whether a DKIM key sits at the common selectors or one you enter, what the DMARC record asks receivers to do, whether the domain ending is one filters trust less, and whether you’re about to send cold email from your company’s own domain. Every failing check comes with the fix. It runs in your browser and stores nothing.
Then come back here for the parts a DNS lookup can’t see.
Never send cold from your main domain
Your main domain carries your invoices, your proposals, your password resets and every reply to a paying customer. Cold email is the one activity most likely to get a domain marked down: people hit “report spam”, a list bounces, a filter decides you look like everyone else. If that happens on your main domain, the damage lands on the mail you actually can’t afford to lose.
So cold email goes out from separate domains. Microsoft gives the same advice for any mail you don’t fully control: its SPF setup guide recommends a subdomain for bulk email services so “issues with mail sent from those email services” don’t hit the reputation of your employees’ mail. For cold email I go one step further and use separate registered domains, not subdomains, because a subdomain still shares a name with the domain you’re protecting.
How I pick them:
- Same brand, recognisable. getyourbrand.com, yourbrandhq.com, tryyourbrand.com. A prospect who sees the reply should still know who you are.
- .com or your country domain. Cheap endings like .online, .xyz, .top or .click are where throwaway senders live, so filters weigh them. It’s not a block, it’s a handicap you start with. One of my own domains was a .online, and it was also the one with the worst placement (more on why below; the TLD wasn’t the only problem).
- A real one-page website on it. Not just a redirect. When I checked eight of my sending domains in August 2026, every domain that served its own page was clean and every domain that was dead or redirect-only was listed or degraded. Eight domains is a small sample and the listed ones had other problems too, so read it as a pattern, not proof. A page costs nothing, so I don’t take the risk.
- Its own nameservers. This one surprised me, see the mistakes section.
SPF, DKIM and DMARC in plain words
Three DNS records, three jobs:
- SPF lists which servers may send mail for your domain. It’s one TXT record starting with
v=spf1. The spec is RFC 7208. - DKIM puts a signature on every message so the receiver can check it came from you and wasn’t changed on the way. Your provider holds the private key; you publish the public key in DNS under a “selector”. The spec is RFC 6376.
- DMARC tells receivers what to do when a message fails SPF and DKIM alignment, and where to send reports about it. It lives at
_dmarc.yourdomain.com. DMARC became an IETF standard in May 2026 as RFC 9989, which replaces the older RFC 7489.p=noneis still a valid policy, and the RFC itself suggests starting there.
Here’s what the records look like on the two providers almost every B2B sender uses. Replace yourdomain.com with your sending domain.
| Record | Google Workspace | Microsoft 365 |
|---|---|---|
| SPF (TXT on the domain) | v=spf1 include:_spf.google.com ~all | v=spf1 include:spf.protection.outlook.com -all |
| DKIM | TXT at google._domainkey, generated in the Admin console under Apps, Google Workspace, Gmail, Authenticate email. Use a 2048-bit key if your DNS host allows it. | Two CNAMEs, selector1._domainkey and selector2._domainkey. Copy the exact values from the Defender portal; they’re specific to your tenant. |
| DMARC (TXT at _dmarc) | v=DMARC1; p=none; rua=mailto:[email protected] | |
Sources: Google’s SPF and DKIM setup pages, Microsoft’s SPF and DKIM guides. The two providers disagree on the end of the SPF record: Google recommends ~all (soft fail), Microsoft recommends -all (hard fail) when DKIM and DMARC are in place. Either works for cold email; follow the provider you send from.
The policy I start with is p=none plus a rua address, so reports come in from day one. After a couple of weeks of reports with nothing legitimate failing, I move it to p=quarantine. Microsoft’s own FAQ advises the same order: none, then quarantine, then reject.
The two SPF mistakes that look fine in a DNS panel
Two SPF records. Someone connects a new tool and its setup wizard adds a second v=spf1 record next to the first. Two isn’t twice as safe. Under RFC 7208 a domain must not have more than one, and if it does, the check returns a permanent error, which receivers treat as if you had no SPF at all. Merge them into one record.
More than 10 lookups. RFC 7208, section 4.6.4: SPF checks must stop at 10 DNS lookups and return a permanent error past that. Every include: costs at least one lookup, and the includes inside it count too. Five tools in one record can blow the limit without the record looking long. The checker counts them for you.
What Google and Microsoft actually require
Google’s sender guidelines, in force since February 2024, ask every sender for SPF or DKIM, valid forward and reverse DNS, TLS, and a spam rate in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to Gmail need SPF and DKIM, a DMARC record (policy none is enough), alignment between the From domain and the SPF or DKIM domain, and one-click unsubscribe on marketing mail. Google recommends keeping the spam rate under 0.1%.
Microsoft announced the same three records in April 2025 for domains sending more than 5,000 emails a day to Outlook.com, Hotmail and Live addresses, with DMARC at least p=none and aligned. The post says non-compliant mail goes to Junk first and also, in an update, that it gets rejected, so treat both as possible.
A cold email domain at 25 a day is nowhere near 5,000. I set everything up as if it were anyway: the records cost ten minutes, and being under the threshold doesn’t mean the filters stop looking.
How many emails per domain per day
My working cap, across all mailboxes on that domain
Five mailboxes on a domain at 5 each
The hard SPF limit in RFC 7208
My cap is 25 cold emails per domain per day, and a fresh domain starts well below that and climbs by a few a day each week. Per mailbox that’s about 5 a day, with five mailboxes on a domain.
Why per domain and not per inbox: filters track reputation per domain and per sending IP. Google says it plainly in its guidelines, it “tracks volume, feedback, and limits per domain and IP address”. Ten mailboxes on one domain at 10 a day each isn’t ten small senders, it’s one domain sending 100 a day. Adding mailboxes raises your capacity only if you add domains with them.
Where the 25 comes from: in my October 2026 deliverability audit, I compared domains that carried the same list, the same copy and the same infrastructure. The ones carrying about 220 cold emails a week burned. The ones carrying about 75 to 140 a week stayed healthy. 25 a day is 125 a week at most, which sits inside the range that held. Neither Google nor Microsoft publishes a cold email limit, so this is my operating rule, not an industry standard. If someone quotes you a hard number as fact, ask where it’s from.
To turn a meeting target into domains and mailboxes at these limits, with a cost range, use the cold email infrastructure planner.
For what all this buys you: in my cold outreach benchmarks, 4.2% of the people we cold emailed replied, 2.07% per delivered email, and that’s from domains that passed everything on this page. The setup is what gets you a fair hearing in the inbox. What you say once you get there is a different page.
The mistakes that got my domains listed
In 2026 I had sending domains go bad and assumed, like everyone does, that it was the copy. I rewrote it. Nothing changed. So I did a proper audit, with the copy tested first: the live email scored 10/10 on mail-tester, and the exact same email landed fine from some domains and badly from others. The copy wasn’t it. This is what was:
Warm-up: what it does and does not fix
Warm-up tools send your new mailbox’s messages to a network of other mailboxes that open them, reply and pull them out of spam. That gives a new domain a history of mail people engage with, so I warm every new mailbox for a few weeks before it sends a single cold email.
What it doesn’t do: it doesn’t measure your cold email. A warm-up score tells you whether your warm-up mail lands. Three of my domains showed 100% warm-up reputation while they were listed on SURBL. And warm-up can’t repair a missing DMARC record, a shared nameserver, a bad list or 200 emails a day from one domain. If warm-up is the only thing you watch, you’ll find out about the real problem from your reply rate.
A 0% bounce rate proves nothing either. Being blocklisted mostly changes where mail lands, not whether it bounces.
How to check it yourself
- DNS: the domain checker, for SPF, DKIM, DMARC, MX and the lookup count.
- The real result on a real message: send a test to a Gmail address, open it, click “Show original” and look for
spf=pass,dkim=passanddmarc=pass. That’s what the receiver actually concluded, which beats any DNS check. - Blocklists: look the domain up on Spamhaus and SURBL through their own sites. Check every sending domain, not just the one that’s acting up.
- Reputation over time: add each sending domain to Google Postmaster Tools. It shows the spam rate Google holds you to, once you send enough volume for it to show data.
- DMARC reports: the
ruaaddress gets daily reports of who sent mail as your domain and whether it passed. Read them before you tighten the policy.
Checklist
Screenshot this one.
- Cold email never goes out from the domain your company runs on.
- Sending domains are .com or a country domain, recognisably your brand, not a typo of it.
- Each sending domain has its own one-page website, not just a redirect.
- Each sending domain sits on its own nameservers, not a pair shared with other cold domains.
- Exactly one SPF record, under 10 DNS lookups.
- DKIM on, at the selector your provider gives you, 2048-bit where possible.
- One DMARC record with
p=noneand aruaaddress to start; quarantine once reports are clean. - New mailboxes warm up for a few weeks before the first cold email.
- At most 25 cold emails per domain per day, about 5 per mailbox, ramped up slowly.
- Test message shows spf, dkim and dmarc pass, and every domain is checked against Spamhaus and SURBL each week.
If you’re sending into Europe, the setup is half of it. Whether you may send the email at all depends on the country, and the rules in Germany and the Netherlands are stricter than most founders think. I put them side by side with the actual articles in B2B cold email law in Europe, country by country. And if you’d rather not run any of this yourself, it’s part of the outbound engine I run for founders. The usual reasons the tooling around it breaks are in why sales automation fails in B2B.
Not sure your setup is safe? I’ll record a free 10-minute video audit of your domains, sending setup and outbound, with the fixes to make first. Get your free video audit.