Cold email infrastructure in 2026, and why we diversify it

Why not just use Google?

Because every risk in cold email is correlated inside a single provider. A reputation problem, a policy change, an authentication failure or a domain-level listing does not politely affect one mailbox. It affects the environment those mailboxes share.

If the whole programme sends through one provider on one domain pattern, then a single deterioration event takes the whole programme offline at once. Split across independent pools, the same event costs a slice of capacity while the rest keeps running, and it gives you something far more valuable than redundancy: a comparison. When one pool's placement drops and the others hold steady, the problem is that pool. When all three drop together, the problem is the list, the offer or the copy. A single-pool programme cannot tell those apart.

Diversification is an operational resilience strategy. It is not a way to evade a provider's enforcement, and anyone selling it that way is selling you a future outage. Every pool authenticates properly, sends conservatively and gets retired when it deteriorates.

The Google Workspace pool

We run roughly 10 to 12 cold sends per Google Workspace mailbox per day. That is ReplyLead's operating choice, not a limit Google publishes and not a recommendation Google makes about cold email. Google's documented limits are far higher, and the gap between them is the entire point of this section.

The Google pool is shaped wide rather than deep: a small number of mailboxes on each of a large number of domains. Losing one domain costs a small, bounded slice of capacity. Per-mailbox volume never rises to absorb the loss; the mailbox count does.

The detailed volume arithmetic, including how to work backwards from a target number of conversations to a mailbox count, lives on how many cold emails you can send per day.

The Microsoft 365 pool, and why it is a different architecture

The second pool runs on Microsoft 365 mailboxes served by Exchange Online. It is worth being precise about the terminology, because these names are not interchangeable: this is Microsoft 365 with Exchange Online as the mail service, connected over OAuth. It is not Azure Communication Services, which is Microsoft's separate bulk-email product, and it is not a generic SMTP relay.

We run roughly 1 to 2 cold sends per Microsoft mailbox per day - an order of magnitude below the Google pool, not a rounding difference. In exchange, a single domain in this pool may carry around 49 to 50 mailboxes. Many mailboxes each sending almost nothing produces a materially different risk profile from a few mailboxes each sending steadily, even at the same total volume.

SMTP as a third pool

A dedicated SMTP sending service can act as a third independent pool. Its value in this design is provider diversity: different infrastructure, a different IP environment, a different reputation that deteriorates on its own schedule rather than in step with your mailbox providers. Where an architecture needs a pool that fails independently of both Google and Microsoft, that is the role it fills.

Two honest caveats. SMTP does not inherently deliver better than a provider mailbox, and anyone claiming otherwise is describing a sales page rather than a measurement. And a third pool is only worth adding when it is genuinely independent - a pool that shares its reputation environment with one you already run adds cost and no resilience.

We currently run the Google and Microsoft pools. SMTP is described here as a component of a diversified design, not as something in our own live configuration.

Domains: never the main one, and never one pattern

Your primary domain never sends cold email. That rule has no exceptions. Cold email carries bounce risk, complaint risk and listing risk, and if the domain your business runs on absorbs that, you lose the mail the business depends on: invoices, support threads, password resets, replies from customers.

Everyone knows to buy several sending domains. Far fewer people think about what those domains are called, and that is where our expensive mistake happened. We bought a set built on obvious variations of one brand word. Tidy, easy to manage, and instantly recognisable as a pattern - which is precisely the problem, because a pattern legible to you is legible to a filter.

The rule: if you can describe your domain set in one sentence, so can a filter. Vary the stem, not just the suffix - and vary it across pools too, so a Google-pool pattern and a Microsoft-pool pattern do not share a signature.

Where aged domains fit

Buying established domains - registrations that are already many years old, sometimes fifteen or twenty - is one further axis of diversification available to a programme, and worth naming because most infrastructure content ignores it. A pool built entirely on domains registered last month is uniform in a way that a mixed-age pool is not.

Two things we will not claim, because we cannot evidence them: that aged domains inbox better, and that any provider grants them additional trust. Neither is something we have measured, and both are asserted constantly by people selling aged domains. The defensible statement is narrower and still useful: an outbound programme does not have to depend exclusively on newly registered sending domains, and diversity of registration age is one more way a pool avoids looking like a single batch.

Warmup, briefly

A new mailbox on a new domain has no sending history, and receivers treat unknown senders with suspicion by default. Plan on two to three weeks of warmup before real campaign volume, and keep a lighter warmup running underneath live sending rather than switching it off the day you start. Domain age matters separately from mailbox age, so buy sending domains before you need them and let them sit.

The full ramp, what warmup does and does not fix, and how to run it under live campaigns is on email warmup.

Authenticate every domain in every pool

Every sending domain needs SPF, DKIM and DMARC before its first send, in every pool. This is no longer a best practice; it is an entry requirement at both major receivers, and the thresholds are published.

The trap is assuming that what you configured is what is live. SPF in particular fails silently: the specification allows a maximum of 10 DNS lookups per evaluation, every include costs at least one and usually more, and crossing the limit turns the whole record into a permanent error. Your DNS panel will show the record sitting there looking perfectly correct.

Build the records with the SPF and DMARC generator, which counts lookups as you add providers, then confirm what is actually resolving with the deliverability checker. When a message goes wrong, the header analyzer shows what the receiver actually saw.

Monitor each pool separately, and retire on bounce rate

Diversification only pays if you can tell which pool is deteriorating. Health has to be tracked per pool, per domain and per mailbox, because each of those levels fails differently and only one of them is worth acting on at the mailbox level.

It is tempting to look at a mailbox with one reply next to a neighbour with six and conclude the first is finished. That conclusion is almost always wrong. Sending platforms distribute volume across the mailboxes on a domain, so any individual mailbox's reply count is a small sample of a shared pool. Per-mailbox reply rate is noise. Reply performance is a property of the domain, the copy and the list. Bounce rate is the opposite: deliverability is genuinely mailbox-specific, so one mailbox with a high bounce rate is a real, isolated problem worth acting on even when its domain is healthy.

We run this as a daily snapshot so deterioration shows up as a trend rather than a surprise. A domain whose reply rate is drifting down over two weeks is a far more useful signal than any single day's number. And when a whole pool moves while the others hold, the diversified architecture has just told you something a single-provider setup never could.

What is cold email infrastructure?

Cold email infrastructure is the collection of sending domains, mailboxes and provider accounts that an outbound programme sends from, kept deliberately separate from the domain a business runs its normal mail on. It covers which providers the mailboxes live with, how many domains carry them, how many mailboxes sit on each domain, how each domain is authenticated with SPF, DKIM and DMARC, and how sending reputation is monitored and retired.

What is cold email infrastructure diversification?

Infrastructure diversification means spreading an outbound programme across more than one sending provider, more than one domain strategy and more than one reputation environment, so that no single failure can stop the whole programme. In practice that means separate pools - for example a Google Workspace pool and a Microsoft 365 pool - each with its own domains, its own mailboxes and its own health monitoring. If one pool deteriorates it can be identified, reduced or paused and diagnosed while the other pools keep operating.

How many cold emails does ReplyLead send per Google mailbox in 2026?

Approximately 10 to 12 cold emails per Google Workspace mailbox per day. That is ReplyLead's operating choice rather than a Google recommendation. Google's own documented limit for a paid Workspace account is 3,000 external recipients per day, so we run at roughly 0.4% of what the platform permits, and we scale total volume by adding mailboxes rather than by raising that number.

Why does ReplyLead use different sending providers?

To remove single points of failure and to make diagnosis possible. Risks inside one provider are correlated: a reputation problem, a policy change or a domain-level listing affects the whole shared environment at once. Running independent pools means a deterioration event costs a slice of capacity instead of the entire programme, and comparing pools tells you whether a drop is an infrastructure problem or a list, offer or copy problem. It is a resilience strategy, not a way to evade any provider's rules.

How does Microsoft's architecture differ from Google's for cold email?

The binding constraint sits at a different level. On Google Workspace, sending headroom is largely a per-mailbox property: a paid account may send to 3,000 external recipients a day. On Microsoft 365 with Exchange Online, a mailbox may address 10,000 recipients a day, but Microsoft also applies a Tenant External Recipient Rate Limit that caps external recipients across the entire tenant in a rolling 24 hours, a limit Microsoft says depends on the number of licences the tenant has. Adding mailboxes or domains inside the same tenant does not by itself lift that tenant-level control, so the design is not a way of manufacturing capacity - it spreads sender reputation across many senders. ReplyLead's operating choice is roughly 1 to 2 cold sends per mailbox per day, with up to about 49 to 50 mailboxes on a single domain. Those are our choices, not Microsoft recommendations.

Should cold email use multiple domains?

Yes, and the reason is containment rather than volume. Reputation, blocklisting and authentication failures are domain-level events, so a programme on one sending domain has one thing that can take it entirely offline. Multiple domains cap the loss from any single event. The domains must also differ in name pattern: a set of domains built on obvious variations of one word is a pattern a filter can match, which is how 11 of our own 16 sending domains ended up listed at the same time.

What role do aged domains play in cold email infrastructure?

Aged domains - registrations already many years old - are one optional axis of diversification, so that a sending pool is not composed entirely of domains registered in the same recent batch. They are not a deliverability shortcut. There is no evidence we are willing to publish that aged domains achieve better inbox placement or that any provider grants them additional trust, and claims to that effect usually come from people selling them. Registration-age diversity is a structural benefit, not a placement one.

What role can SMTP play in cold email infrastructure?

A dedicated SMTP sending service can act as a third independent pool alongside provider mailboxes, contributing a different infrastructure and IP environment whose reputation deteriorates on its own schedule rather than in step with Google or Microsoft. Its contribution is independence, not better deliverability - SMTP does not inherently place better than a provider mailbox. It is only worth adding when the pool is genuinely independent of the ones already running.

Why shouldn't all outbound infrastructure depend on one provider?

Because a single provider makes every risk in the programme correlated and gives you no way to diagnose a problem. One reputation event, policy change or domain-level listing inside that environment can stop all sending at once, and when placement drops you cannot tell whether the cause is the infrastructure or the campaign. Independent pools convert a total outage into a partial one and give you a control group to compare against.

Can I recover a blocklisted domain?

Sometimes, through the blocklist's delisting process, but treat recovery as a bonus rather than a plan. Reputation recovery is slow and uncertain. The cheaper move is usually to retire the domain and replace it, which is why domain naming diversity matters so much: it caps how much you lose at once.

How much should this cost?

Domains are a few dollars a year each. Mailboxes are the real cost and scale roughly linearly with volume, and a diversified architecture costs more than a single-provider one because you are deliberately paying for capacity you are not maximising. We publish our full modelled infrastructure cost by volume tier on the agency cost page and in the ROI calculator.