Cold Email Infrastructure: Domains, Warmup, and Sending Setup

Why does cold email infrastructure decide the campaign before the copy does?

Almost every infrastructure guide on the internet opens with a shopping list. Buy 5 domains, buy 15 mailboxes, install a warmup tool, go. Across 50+ active B2B campaigns we run, the domain count has never been the first decision in a build. It is the last one, because it falls out of arithmetic that starts at the number of conversations the business actually needs. Below is that arithmetic, the build order that keeps week 1 alive, the DNS records that have to be right before a single send goes out, and the 6 numbers to watch once the campaign is live.

We have audited outbound programs for over 50 B2B companies. The most common failure is not a weak subject line. It is a mailbox that skipped warmup, a DKIM key that was generated but never switched on, or a domain count picked out of a blog post instead of out of a volume target. Those mistakes burn 6 to 10 weeks and leave behind a sender reputation that takes months to rebuild.

Writing is a 5 to 10 percent lever on reply rate. Infrastructure is a 30 to 50 percent lever on whether the reply rate exists at all. Most people work the smaller lever first because it is the more interesting one.

Cold Email Infrastructure

The technical foundation required to send cold email at scale without tripping spam filters or damaging the primary company domain. It has 6 parts: secondary sending domains kept separate from the main domain, mailboxes hosted on a real provider, DNS authentication records (SPF, DKIM, DMARC), a warmup protocol run before any cold send, a sending platform that rotates volume across the mailbox pool, and a monitoring layer that catches reputation loss while it is still reversible.

How do you size cold email infrastructure backwards from conversations?

Start at the only number the business cares about, which is conversations on the calendar, then work backwards through the funnel until you land on mailboxes. Every step in that chain is a rate you can measure, so the sizing is arithmetic rather than opinion.

The chain runs like this. Sends produce replies. Replies split into positive and negative. Positive replies produce booked meetings. Booked meetings produce completed conversations after scheduling gaps and no shows take their cut. Our reply rate sits at 4.6 percent across the book against an industry median closer to 3.4 percent, and roughly 40 percent of those replies are positive. What happens after the positive reply is where most models quietly cheat, so we use a range instead of a single number: 200 to 300 sends per completed conversation once scheduling loss and no shows are netted out. Tighter lists land near the low end, broad lists land near the high end, and anyone quoting a precise constant here is guessing.

That gives you a sizing table you can actually build against. It assumes 22 business days of sending per month and a conservative 35 cold emails per warmed mailbox per day.

Two things fall out of that table immediately. The first is that most companies dramatically overbuild. A business that needs 10 real conversations a month needs 1 or 2 secondary domains, not the 8 domain pool the tooling vendors describe. The second is that the jump from 30 to 100 conversations is not a copy problem or a targeting problem, it is a 3x infrastructure build with a 4 week warmup lead time attached to it, and that lead time is the part nobody schedules.

Build in a buffer. Size the pool for 20 to 30 percent more volume than the target, then run the mailboxes below their ceiling. A pool of 12 mailboxes running at 35 a day is a far safer asset than a pool of 8 running at 50, and it costs one extra domain. If the funnel math itself is the part you are unsure about, our cold email reply rate benchmarks and the breakdown of what a positive reply rate actually measures give you the two rates that drive everything above.

What is the right order of operations for a cold email infrastructure build?

Order matters more than any single setting. Roughly half the broken builds we audit have every component present and correct, installed in the wrong sequence, which produced a record of failed authentication and cold sends from an unwarmed mailbox that the receiving providers had already filed away.

This is the sequence we run on every deployment:

1. Define the list before buying anything. The ICP definition sets the addressable count, and the addressable count caps monthly volume whether the mailboxes exist or not. A 4,000 person market does not need a 12 domain pool, it needs 2 domains and a follow up sequence.
2. Buy the secondary domains. Close variations of the primary, registered in one place, with a redirect pointed at the main site so a curious recipient who types the domain into a browser finds a real company. A parked registrar page is a trust problem.
3. Publish DNS records before the mailboxes exist. SPF, DKIM, and DMARC go live first. DNS propagation is not instant, and a mailbox that sends its first message during propagation registers an authentication failure against a domain with no history to absorb it.
4. Create the mailboxes and switch DKIM signing on by hand. Google Workspace and Microsoft 365 both generate the DKIM key and both leave signing off until an admin enables it. This is the single most common miss in the entire build.
5. Turn on reputation monitoring before the first send. Google Postmaster Tools and Microsoft SNDS both need domain verification and both only report forward from the day you connect them. Connect on day 1 and you have a baseline. Connect in week 6 and you are diagnosing a drop with no idea what normal looked like.
6. Warm for 21 to 28 days. No cold sends in weeks 1 and 2. Light cold volume in weeks 3 and 4. Full volume from week 5.
7. Verify the list twice while warmup runs. Two independent verifiers, not one. This is dead time in the build anyway, so it costs nothing on the calendar.
8. Seed test, then launch at 20 percent of the ceiling. Run an inbox placement test against Gmail, Outlook, and at least one corporate domain, then open at a fifth of target volume and step up weekly.

Steps 3 and 4 are the ones that get swapped, and swapping them is what produces the campaign that looks correctly configured on paper and lands in spam anyway. The records were right. They just went live after the provider had already formed an opinion.

How many domains and mailboxes do you actually need?

Never send cold email from the primary company domain. That domain carries the website, the invoicing, the client threads, and the marketing sends. Containing outbound risk to a secondary domain means a bad list or a spike in complaints costs you a $12 asset instead of the address every client already has.

The ratios that hold up across campaigns:

• 2 to 3 mailboxes per domain. Past 3, a single domain level reputation event takes out more capacity than it should, and the gain in sending headroom is not worth the concentration.
• 30 to 50 cold emails per warmed mailbox per day. Google Workspace technically permits 2,000 a day and Microsoft 365 permits more. Those are platform ceilings for warm mail, not safe volumes for cold mail, and treating them as targets is how domains get burned.
• Real human sender names. A mailbox at jordan@getacme.com outperforms sales@getacme.com on reply rate and reads less like bulk mail to a filtering system. Role addresses attract filters.
• One person per mailbox. Do not stack aliases on a single account and send from all of them. Each sending address needs its own warmup history and its own daily cap configured in the sending platform.
• Retire, do not repair, at the margin. A domain that has taken a genuine reputation hit is often cheaper to replace than to rehabilitate. The recovery path for a burned domain runs 6 to 12 weeks, and a fresh domain plus warmup runs 4.

Domain naming is worth 10 minutes of thought. Variations that read as the same company (getacme.com, acmehq.com, tryacme.com) inherit some brand recognition and survive a recipient who looks the sender up. Random word salad domains do not, and they are also the pattern that domain age and registration heuristics flag. The full setup walkthrough lives in our guide to setting up email domains for outbound, and the rotation and retirement rules sit in multi domain sending strategy.

Which DNS records have to be correct before the first send?

Three records, and in 2026 all 3 are mandatory rather than advisable. Google's sender guidelines, enforced from February 2024, require SPF, DKIM, and DMARC on any domain sending 5,000 or more messages a day to Gmail, and require a spam complaint rate under 0.3 percent. Yahoo adopted the same threshold in the same window. Microsoft followed on 5 May 2025 with its own high volume sender requirements for consumer Outlook, which dmarcian documented in detail. Failing authentication is now a 550 rejection, not a trip to the spam folder.

SPF publishes the list of servers permitted to send for your domain as a single TXT record. For Google Workspace that is v=spf1 include:_spf.google.com ~all. The trap is the lookup limit: RFC 7208 caps an SPF evaluation at 10 DNS lookups, and every include: you stack counts against it. Cross the limit and the record returns permerror, which receiving servers treat as no SPF at all. One mailbox provider plus one sending tool is usually fine. Four stacked includes is usually broken.

DKIM signs each outgoing message cryptographically, and the receiving server checks the signature against a public key in your DNS. Use a 2,048 bit key where the provider offers it. Both major providers generate the key automatically and both leave signing disabled until an admin turns it on in the console, which is why a domain can pass an SPF check and still fail DMARC alignment on every message.

DMARC tells receiving servers what to do when SPF or DKIM fails, and returns aggregate reports on attempts to send as your domain. The DMARC specification defines 3 policies, and they are a ladder rather than a menu.

Start at p=none and read the aggregate reports for 2 weeks. Move to p=quarantine once every legitimate source aligns. Move to p=reject only after that holds for a month. Jumping straight to reject on a new domain is how people delete their own mail with no bounce to warn them. The record syntax, the ordering mistakes, and the migration trap are covered further in what SPF, DKIM, and DMARC actually do and email deliverability DNS records explained.

DMARC Alignment

The requirement that the domain in the visible From address matches the domain validated by SPF or signed by DKIM. A message can pass SPF against the sending server's own domain and still fail DMARC, because the validated domain is not the one the recipient sees. Alignment is the reason DKIM signing has to be enabled by hand rather than assumed, and the reason a campaign with a clean SPF record can still be rejected at the gateway.

How long does warmup take, and what does warmup not fix?

Warmup builds a new mailbox's sending reputation by starting at very low volume and stepping up over several weeks. Receiving providers score behavior, not intent. A mailbox created on Monday that sends 100 messages on Tuesday looks identical to a spam operation, and there is no field in the protocol where you explain that it is not one.

Warmup tools run those sends for you by connecting the mailbox to a pool of other mailboxes and generating the engagement signals that build reputation: opens, replies, and removal from the spam folder when a message is filed there. The mechanics are covered in email warmup explained, and the new domain specific ramp in how to warm up a new email domain.

What warmup does not do is the more useful half of the answer. It does not clean a list. It does not make spam trigger words invisible. It does not survive a 20 percent bounce rate. A perfectly warmed domain aimed at a scraped list with a third of the addresses dead will land in spam by week 2, because bounce rate is a reputation input and providers weight it heavily. Research published by Validity puts list quality and authentication ahead of every other variable in inbox placement, which is why two pass email verification belongs in the build and not in a later backlog. Our own rule is 2 independent verifiers on every list before a single send, and we hold bounce rate under 2 percent. The bounce rate causes and fixes breakdown covers the thresholds providers enforce.

Keep warmup running at a reduced level after the mailboxes reach full volume. Switching it off entirely at launch is a slow problem that surfaces 2 to 3 months later as open rate erosion nobody can trace, because the thing that changed was the absence of positive engagement rather than the presence of anything bad.

Google Workspace or Microsoft 365 for outbound mailboxes?

Both work. Generic SMTP relays and cheap shared hosting do not, and the money saved there is the most expensive money in the build. The real question is which provider matches the recipients on your list.

The platform ceilings in that table are the least important row on it. Nobody gets blocked for exceeding a documented limit, they get blocked for a complaint rate, a bounce rate, or a sending pattern. Both providers will happily let you send your way into a reputation hole well below their published caps.

If your list skews toward enterprise contacts on Exchange, put a meaningful share of the mailbox pool on Microsoft and accept the longer warmup. If the list is mostly Gmail, which most agency and consultant lists are, Google Workspace is the simpler build and the faster ramp. Splitting the pool across both providers also gives you real isolation: a provider level issue takes out part of your capacity instead of all of it.

For the sending layer itself, the platform matters less than whether it handles mailbox rotation, per mailbox daily caps, and send time randomization. Instantly, Smartlead, and Lemlist all do. We compare the current field in best cold email tools for 2026.

What kills a cold email launch in week 1?

Week 1 failures are boringly consistent. These are the 5 we see most, in the order they cost the most time:

1. DKIM was never enabled. The key exists in DNS, signing is off in the admin console, and every message fails alignment. Fix takes 4 minutes. Finding it takes 3 weeks if nobody checks a message header.
2. Cold sends started during warmup. Someone loads a campaign in week 1 to test the platform, 40 messages go out from a mailbox with no history, and the domain starts life with a spam signal attached. There is no undo. The mailbox needs a fresh ramp.
3. The list was never verified, or verified once. Bounce rate opens above 5 percent, the provider reads it as a purchased list, and placement degrades across the whole domain rather than the one campaign.
4. Volume opened at the ceiling. A warmed mailbox that jumps from 15 to 50 in one day triggers a throttle even with clean authentication. Step up weekly instead.
5. Postmaster Tools was never connected. Not a failure on its own, but it turns every later failure into guesswork, because there is no baseline to compare the drop against.

Notice that none of the 5 are copy problems, and 4 of the 5 are ordering problems rather than knowledge problems. The operator knew what a DKIM record was. They just did the steps in the wrong sequence and the providers scored the sequence.

How do you monitor infrastructure once the campaign is live?

Sender reputation built over 8 weeks can erode in 72 hours, which makes monitoring an operating cadence rather than a reaction. Six numbers, checked weekly, catch almost everything.

The weekly check:

• Open rate, week over week. A drop of more than 15 percentage points inside 48 hours is an infrastructure event, not a copy event. The copy did not change overnight.
• Bounce rate. Above 3 percent, stop and re verify. Above 5 percent, stop sending entirely.
• Complaint rate. Hold under 0.1 percent. The 0.3 percent threshold is where blocking starts, so it is a cliff and not a target.
• Postmaster domain reputation. High, Medium, Low, Bad. A move from High to Medium is the earliest signal you get, and the only one that arrives before performance drops.
• Blacklist status. Check the sending domains and IPs weekly with MXToolbox. A listed domain that keeps sending compounds the damage and can pull the whole Workspace account down with it.
• Placement, not just delivery. Delivered is not the same as inboxed. A seed test through a tool like GlockApps is the only way to see the spam folder, because a message filed there still reports as delivered.

When something breaks, the sequence is: pause the affected mailbox or domain, read Postmaster, check blacklists, confirm the DNS records are still intact, run a seed test, then resume at 20 percent of prior volume after 72 to 96 hours. Do not resume at full volume on a domain that just took a hit. The full monitoring stack and alert thresholds live in cold email deliverability monitoring, the diagnosis tree for a campaign already in spam is in how to avoid the spam folder, and the measurement layer underneath all of it is in what email deliverability actually means and what domain reputation measures.

What does an invite campaign change about the infrastructure?

This is the part that does not appear in any other infrastructure guide, because almost nobody is sending invites. We run a podcast invite motion, where the email asks a buyer onto the client's own show rather than asking for a meeting, and that single change to the ask moves several infrastructure numbers.

Invite sending burns domains more slowly than pitch sending. The mechanism is not mysterious: complaint rate is the input providers weight hardest, and a recipient who receives an invitation is far less likely to hit the spam button than one who receives a sales approach. Lower complaints mean a mailbox can hold volume for longer before reputation drifts. Reply rate runs higher for the same reason, which means the same conversation target needs fewer sends and therefore a smaller pool.

Three practical consequences for the build:

• Sender identity has to match the show, not the agency. The mailbox, the signature, and the domain all belong to the host's brand. An invite signed by a third party reads as brokered and the reply rate reflects that.
• The follow up sequence is shorter. An invite that gets no answer after 3 touches is not a lead that needs 8 touches, it is a scheduling miss. We cover the specific cadence in cold email follow up sequence best practices.
• The pool can run tighter. Because reply rate is higher per send, the domain count from the sizing table lands at the low end of each range. Our own invite specific numbers are in how many sending domains podcast invites need and domains and warmup for podcast invites.

None of that removes a single requirement above. Invites still need SPF, DKIM, and DMARC. They still need 21 to 28 days of warmup and a twice verified list. The ask changes the economics of the pool, not the physics of the gateway, and an invite from an unauthenticated domain gets rejected exactly as fast as a pitch does. The deliverability specifics of the invite motion are in podcast invite email deliverability.

What we ship on a client deployment is the whole layer described in this article, run for them: the domains, the mailboxes, the DNS records, the warmup, the verification, the monitoring, and the invites themselves, email only, with every episode edited and published and the recording owned by the client. It carries a plain commitment, which is 30 recorded conversations with your ideal buyers in 90 days, or your money back. The reason that commitment is possible to make is the infrastructure discipline, not the writing.

Infrastructure is a sizing problem, not a shopping problem

The reason infrastructure is a real edge has nothing to do with difficulty. Nothing in this article is hard. Every step is documented, most of it is free, and the whole build takes a few hours of work spread across a 4 week warmup window.

It is an edge because most senders skip it, rush it, or do it in the wrong order. They buy the domain count someone posted on LinkedIn, enable half the records, start sending in week 1 to see if it works, and then spend the next quarter rewriting subject lines to fix a problem that lives in DNS.

The operators with the strongest outbound programs we have seen are rarely the strongest writers. They are the most disciplined builders. They size the pool backwards from the conversations they need, publish DNS before the first mailbox exists, warm for a full month with no exceptions, hold every mailbox below its safe ceiling, and read 6 numbers every Monday.

Size the infrastructure to the outcome, build it in order, then go argue about copy. The best written email in your market is worth nothing from a domain that Gmail has already decided about.