The setup nobody publishes
Most agencies guard this build like it's trade secret. It isn't. The runbook is straightforward enough for any founder to copy in an afternoon. The reason it gets dressed up in mystique: "we provisioned 80 mailboxes across 27 dedicated domains" sells better as a sales line than "here's how to spend a Tuesday at Cloudflare and Google Admin".
I'll walk it through end to end.
Bad infrastructure is the silent killer of every cold-email programme. People reach for copy and AI when a campaign tanks. The actual cause sits underneath both. A brand-new mailbox on a brand-new domain hitting 25 cold sends on day one lands in spam before the founder finishes their morning coffee, and from there the deliverability never recovers. Every A/B variant you test is contaminated. Every reply rate is artificially low. You sit there wondering why the campaign isn't working, and the answer was settled in week one before a single send went out.
This is the foundation layer underneath every cold-outbound programme worth its budget. The runbook below is what we run for the cold outbound work we operate end to end, and what any in-house team can copy if they'd rather build it themselves.
The four domain rules
Every outreach domain we provision passes four tests. We've broken each rule on test runs and watched the deliverability collapse so you don't have to.
Rule 1. .com only. No .co.uk, no .io, no .ai, no .co, no .net. The trust hierarchy spam filters apply to TLDs is heavily weighted toward .com for cold-channel email. I've watched .ai domains drop sharply on Microsoft and Gmail's bulk-sender heuristics since the back end of 2024, because the spam-from-AI-tooling correlation is now strong enough to score against. .co.uk reads fine for a known-correspondent business email. On a cold send to a US prospect it tilts the scoring against you for no upside.
Rule 2. No hyphens. marchwood-search.com gets filtered. marchwoodsearch.com lands. Hyphenated domains pattern-match too cleanly against the spam-domain corpus filters were trained on. Hyphens in a brand domain are fine; in cold email they're the difference between landing and not landing.
Rule 3. Short and brandable. The recipient sees the sender domain in the From line. It has to read like a real company. Twenty-character domains stitching three nouns together don't.
Rule 4. 301-redirect to your brand domain on day one. A recipient who pastes the sender domain into their browser must land on your real website. If they hit a parked GoDaddy page or a Cloudflare 404, the entire setup is exposed and trust evaporates in two seconds. I've watched campaigns die on this single oversight. Cloudflare Page Rules handle the redirect in 30 seconds per domain, set up at the same time as the domain itself.
Naming convention
Every name pulls from vocabulary the recipient's industry would actually use. For a recruitment firm: Search, Partners, Associates, Advisory, Executive, Talent, Recruitment, Leadership, Headhunters, Capital, Group. For a sales-as-a-service firm those words don't fit; you'd reach for Strategy, Revenue, Growth, Operations, Advisory. The principle is the same. The recipient should read the sender domain and parse it as a real boutique firm in their space.
What never to use:
- SaaS-style prefixes (try-, use-, hello-, my-). They signal a B2B product launch, not a professional services firm.
- Modern-agency informalism (hq, works, collective, brand, studio, lab). None of these read as a serious firm to a buyer about to spend £20k+ with you.
- Legal-entity suffixes baked into the domain (LLP, Ltd, Inc). Real firms don't put their company structure in their URL.
Worked example for a London recruitment firm called Marchwood. The 27-domain priority list opens with marchwoodpartners.com, marchwoodadvisory.com, marchwoodsearch.com, marchwoodexecutive.com, marchwoodtalent.com. Each one reads as a plausible boutique. The backup list pulls geographic and seniority modifiers: marchwoodlondon.com, marchwoodexec.com, marchwoodleaders.com, marchwoodadvisorypartners.com. None of them say "outbound shell".
Cloudflare Registrar and the 301 redirect
Buy every domain on Cloudflare Registrar. Registry pricing, no markup, around £8.30/yr per .com depending on the day's exchange rate. Auto-renew on, WHOIS privacy on. The dashboard ships with DNS, the firewall, and Page Rules included.
The 301 redirect is non-negotiable. Click into the domain. Rules > Redirect Rules > Create. Hostname equals [your-outreach-domain].com. Target: https://yourbrand.com$1. Status: 301. Preserve query string. Save.
Test it. Paste the outreach domain into a fresh browser tab. You should land on your brand site within a second. If you don't, the rule isn't deployed and the next eight steps don't matter.
I've seen agencies skip this step on the assumption nobody checks the sender domain. Plenty of buyers do. The kind of buyer who's going to spend £50k a year with you is exactly the kind of buyer who pastes a sender domain into a browser at 9.30am to work out who's writing to them. A parked Cloudflare default page kills the relationship before they've read the email body.
The Google Workspace per-domain build, all 10 steps
This is the core of the runbook. Repeat the entire flow for each domain. After the first two it takes around 10 minutes per domain.
Step 1. Buy the domain on Cloudflare. Cloudflare dashboard > Registrar > Register Domains. Search, register, auto-renew on, WHOIS privacy on. Wait until the domain shows Active under Websites, usually under five minutes for a fresh .com.
Step 2. Set the 301 redirect. Covered above. 30 seconds. Test it before moving on.
Step 3. Sign up for Google Workspace. Open an incognito window. Clean browser state matters here, because Google's anti-fraud heuristics start scoring the moment you load workspace.google.com. Pick Business Starter at £7/user/mo. Business name: your firm. Country: United Kingdom. Enter the domain you bought in Step 1. The admin contact for the very first signup uses a personal email; for subsequent signups, use a mailbox you've already created on a previous domain. Complete to payment.
Step 4. Phone verification with JuicySMS. Google asks for phone verification during signup, and may ask again later for "suspicious activity". Open JuicySMS in a separate tab, buy a fresh UK number (around £0.10 per number). Different number every signup. Reuse is the single biggest fraud-flag trigger on the Google side. I've had a tenant get sandboxed on Step 4 because we reused a JuicySMS number two domains earlier; the recovery flow took 48 hours and we lost the slot. Paste the JuicySMS number into Google's verification field, wait for the SMS to land in JuicySMS, copy the code, paste it into Google.
Step 5. Verify the domain. Google gives you a TXT record string. In Cloudflare: DNS > Records > Add record. Type: TXT. Name: @. Content: the verification string Google produced. Click Verify back in Google. Propagation is usually 30 seconds.
Step 6. Let Google auto-add MX, SPF, and the DKIM placeholder. When Google detects Cloudflare, it offers to add the standard records automatically. Accept it. This adds five Google MX records, the SPF record (v=spf1 include:_spf.google.com ~all), and a DKIM verification placeholder. This is the only Google-specific shortcut in the entire flow worth using.
Step 7. Create three real-name users on the domain. Inside the setup wizard, or admin.google.com > Directory > Users, create three users using real team names: benedict@, hugo@, plus a third real teammate. Don't invent fake personas. Recipients sometimes Google the sender's name, and a fabricated person destroys credibility instantly. Set a strong password for each, save in your password manager. Rotate which three names sit on each domain so the same combination doesn't repeat across all 27 domains.
Step 8. Activate DKIM. admin.google.com > Apps > Google Workspace > Gmail > Authenticate Email. Select the domain. Generate new record. Keep defaults: 2048-bit, prefix google. Copy the TXT value Google produces. In Cloudflare: TXT record. Name: google._domainkey. Content: the value Google produced. Wait two to three minutes for DNS propagation. Back in Google, click Start authentication.
Step 9. Add DMARC manually. DMARC is the only DNS record Google does not auto-add. In Cloudflare:
- Type: TXT
- Name:
_dmarc - Content:
v=DMARC1;p=none;sp=none;pct=100;rua=mailto:admin@<this-domain>;ruf=mailto:admin@<this-domain>;ri=86400;aspf=s;adkim=s;fo=1
Replace <this-domain> with the outreach domain you're configuring right now. For marchwoodgroup.com it's admin@marchwoodgroup.com, never admin@marchwood.com. DMARC reports must come back to the same domain that's sending the mail or the record fails alignment. p=none means "monitor only, don't reject failures yet". Keep p=none across all domains for the first 4 weeks.
Step 10. Set the signature on each of the three mailboxes. In each user's Gmail settings: Name. Role. Marchwood. That's the entire signature. No website URL. No social links. No images. No tracking pixels. All four are heavily-weighted spam signals on the Gmail and Outlook scoring engines.
Done with this domain. Move to the next.
The Microsoft 365 parallel build
The runbook above covers Google Workspace. The half nobody documents is the Microsoft 365 mirror. Half your prospect base sits on Outlook, and the deliverability scoring at Microsoft works differently to Gmail's. Here's the equivalent build, sourced directly from the Microsoft 365 Defender and Admin Centre docs.
Tenant and domain setup. In the Microsoft 365 admin centre: Settings > Domains > Add domain. Verify ownership via TXT record at the registrar (Cloudflare in our case). Microsoft also offers an MX-record verification fallback and a text-file upload option, but the TXT method is cleanest because it doesn't interfere with mail flow during cutover. Create users in Admin Centre > Users > Active users before switching the MX record. The reason: if you switch MX first, mail starts flowing into a tenant with no mailboxes provisioned, and inbound mail bounces.
SPF. The Microsoft 365 SPF include is v=spf1 include:spf.protection.outlook.com -all. Note -all (hard fail) versus Google's ~all (soft fail). Microsoft's stance is that production senders should run hard-fail.
DKIM. Configuration happens in the Defender portal: Email & collaboration > Policies & rules > Threat policies > Email authentication settings (security.microsoft.com/authentication) > DKIM tab. Slide the Toggle from Disabled to Enabled. A client-error dialog opens because no CNAMEs exist yet. Click OK. Status becomes CnameMissing. Click the row to copy the two Publish CNAMEs (selector1._domainkey and selector2._domainkey). Add both as CNAME records at the registrar. Return to the open flyout, toggle "Sign messages for this domain with DKIM signatures" to Enabled. Status moves to "Signing DKIM signatures for this domain". Default key size is 1024-bit; 2048-bit is recommended and selectable via the Rotate-DkimSigningConfig PowerShell cmdlet. Microsoft's guidance on rotation cadence is "periodically" without a fixed interval. Each rotation takes 96 hours for the new private key to start signing, so factor that in if you rotate quarterly.
DMARC. TXT record at _dmarc, content v=DMARC1; p=none; pct=100; rua=mailto:rua@yourdomain.com; ruf=mailto:ruf@yourdomain.com. Microsoft recommends a gradual progression: start at p=none, monitor, move to p=quarantine (optionally ramping with pct=10, pct=25, pct=50, pct=75, pct=100), then p=reject (also pct-ramped). No fixed timing per stage. Microsoft's published guidance says "after enough time monitoring the effects". For parked or non-sending domains they say go straight to p=reject.
A 2025 wrinkle worth knowing. As of May 2025, new custom domains in Microsoft 365 use an updated DKIM record format that includes a dynamically generated character (r or n) in the selector CNAME target, assigned by Microsoft and not configurable. Existing custom domains carry on with the old format. If you're standing up new domains today, expect the new format and use the values Microsoft surfaces in the flyout verbatim.
For programmatic sending from your cold-email tool, the choice is IMAP/SMTP versus Microsoft Graph API. IMAP/SMTP is what most tools support out of the box; Graph is cleaner if your tool offers it. Smartlead supports both.
Sources for the Microsoft side: Microsoft Defender DKIM, SPF, and DMARC configuration docs, plus the Admin Centre add-domain guide.
Why we split 80 mailboxes 50/50 across providers
Single-provider setups are the standard. Most agencies stand up 80 Google mailboxes and call it done. The 50/50 split across Google and Microsoft is the agency-grade play they miss. Three reasons it matters.
First, Gmail and Outlook score differently. Gmail leans heavier on engagement signals (open rate, reply rate, time-in-inbox) and lighter on header authentication once you're past the initial reputation phase. Outlook leans heavier on header authentication (SPF, DKIM, DMARC, sending-IP reputation, content-based scoring) and is far less forgiving of new senders. A campaign that's deliverable into Gmail can be at 0% deliverability into Outlook at the same time, and you only see it if you're sending from both providers and tracking the splits separately. I track Outlook deliverability separately on every campaign I run, off a Glockapps seed list every fortnight, because Smartlead's headline number averages the two and hides the divergence.
Second, your prospect base is split across both. Mid-market UK and US B2B sits roughly 60/40 Outlook/Gmail. Enterprise tilts further toward Outlook. Sending exclusively from Gmail means half your prospects see a Gmail-from-an-unfamiliar-domain pattern that Outlook scores down. Sending from a matched-provider sender (Outlook to Outlook) lifts deliverability noticeably on the Microsoft side.
Third, redundancy. If Google or Microsoft suspends a tranche of accounts, half your fleet keeps running. Google Workspace has cracked down on bulk-account creation patterns several times in the past two years. Microsoft's anti-abuse team is less reactive but more arbitrary when they do act. Single-provider exposure is operational risk you don't need to carry.
Smartlead OAuth and the 4-week warmup
Once all the domains and mailboxes are stood up, connect every account to Smartlead. Email Accounts > Add new. For Google, OAuth handles the connection without IMAP enabled, which is cleaner. For Microsoft, OAuth where the tool supports it; IMAP/SMTP otherwise. 80 accounts, around 30 seconds per OAuth flow.
Then turn warmup on for every account.
The 4-week warmup is non-negotiable. A brand-new account hitting 25 cold sends on day one is a dead account by day three. Warmup ramps internal traffic between the accounts. Smartlead handles the volumes automatically: a few sends a day in week one, scaled up across week two and three, full warmup volume by week four. The accounts build positive engagement signals (opens, replies, replies-to-replies, no spam complaints) that the receiving providers score against the sending domain's reputation.
After campaigns go live, leave warmup running permanently in the background. Switching it off in week 5 because "the account is ready now" is one of the most common ways to crater deliverability six weeks in. The warmup volume is engineered to keep reputation from drifting downward as cold-send volume goes up. I've watched a fleet of 40 mailboxes lose 30 points of inbox placement in a fortnight because the operator turned warmup off "to save the credits". The credits weren't the issue. The reputation drift was.
What this layer earns you
This is the foundation. With it, cold outbound runs at production volume without burning the brand. Without it, the copy doesn't matter and the AI doesn't matter, because nothing the recipient is meant to read ever reaches their inbox.
If you're a head of sales auditing what your current vendor or in-house team has built, the questions to ask are the ones this runbook answers. Are the outreach domains separate from the brand domain? Do they 301-redirect? Is the fleet split across Google and Microsoft? Is warmup permanently on? Is DMARC aligned per sending domain? A vendor running a serious infrastructure stack answers each of those in concrete language. A vendor running a shallow setup hand-waves.
If you'd rather we run the cold outbound work we operate for clients end to end, the Pipeline page is the cleanest way in. We provision the domains, the mailboxes, the warmup, the lot.