How Agencies Set Up Hundreds of Cold Email Inboxes Without Getting Domains Burned

Agencies avoid burned domains by making the domain disposable and the volume invisible: they send from cheap secondary domains that carry no business value, put only 2–3 mailboxes on each domain, cap each mailbox at roughly 20–30 sends per day, and authenticate every domain with aligned SPF, DKIM, and DMARC. When a domain does degrade, they retire it and replace it from a spare pool. The client's primary domain was never in the sending path, so nothing of value is lost.

Everything below is the operational detail behind that sentence: the math for sizing a fleet, what actually causes reputation damage (it is almost never raw volume), and how to run 100+ domains without manually touching each one.

What is the actual architecture agencies use to run hundreds of inboxes?

Every high-volume cold email setup is the same four-layer stack. Get the layering right and scale becomes arithmetic instead of guesswork.

The sizing formula

Work backwards from daily send volume:

A worked example for an agency that needs 5,000 sends per day:

Notice what this architecture does: 5,000 daily sends are spread so thin that no single domain sends more than about 75 messages a day. That is indistinguishable from a small sales team doing normal work. The provider-side daily caps (Google Workspace allows 2,000 messages per user per day) are irrelevant here. You will never come close, and you should not want to.

Why do cold email domains actually get burned?

Volume is the thing people blame and almost never the cause. Mailbox providers are reacting to recipient behavior and technical signals. In rough order of how often they kill a domain:

How many mailboxes should go on one domain?

Two to three. The reason is blast radius, not cost.

Reputation is evaluated substantially at the domain level. If a domain degrades, every mailbox on it degrades with it. Ten mailboxes on one domain means one bad list takes out ten sending slots. Three mailboxes means you lose three, and you swap in a bench domain the same afternoon.

Three mailboxes per domain also happens to look like a real small company: a founder, an SDR, and an ops person. Fifteen mailboxes on a two-month-old domain does not.

Do email aliases count as separate mailboxes?

No, and this is worth being precise about because aliases are marketed as a cost hack. An alias routes through the same underlying mailbox: it shares that mailbox's sending reputation, its throttle limits, and its fate. If the parent mailbox is restricted, every alias on it stops working simultaneously. Aliases are useful for catching reply variants and inbound routing. They are not a way to multiply sending capacity, and treating them as one concentrates risk in exactly the way this whole architecture exists to avoid.

Which domains should you buy, and which will burn on day one?

Rules that hold up in practice:

Should you use Google Workspace, Microsoft 365, or your own SMTP?

Use Google Workspace and Microsoft 365, mixed. Their outbound reputation is strong, they land well at their own destinations, and mixing both lets you route Gmail-heavy prospect lists through Workspace mailboxes and Outlook-heavy lists through 365 mailboxes.

Self-hosted SMTP on a VPS is cheaper per mailbox and worse at almost everything that matters: you start with zero IP reputation, you are responsible for PTR records and blacklist remediation, and consumer inboxes treat a fresh VPS IP with justified suspicion. It can work, but it is an infrastructure project, not a cost saving.

Why the provisioning channel matters more than the price

This is the part that determines whether a 300-mailbox fleet survives. Mailboxes sold cheaply are sometimes created through channels the providers do not sanction, or held inside a tenant you don't control. Two failure modes follow: mass suspension when the provider acts on the pattern, and no recourse when it happens, because the accounts were never yours.

What to require from any mailbox vendor, regardless of who you buy from:

This is the specific gap Inboxlogy fills: authorized Google Workspace and Microsoft 365 mailboxes on dedicated US or EU IPs, with 100% ownership and admin access handed to you, SPF/DKIM/DMARC configured automatically at provisioning, and a full API for programmatic setup, from $2.80 per mailbox per month, $0 setup, billed monthly. That combination matters to an agency because "cheap mailboxes" and "mailboxes you actually own" are usually not the same product, and you only find out which one you bought when something goes wrong.

How do you set up SPF, DKIM, and DMARC correctly across dozens of domains?

Every sending domain needs all three, and they need to be consistent. The specifics:

At 60+ domains, do this through your registrar's API or a provider that configures DNS at provisioning time. Hand-editing zone files across dozens of domains produces exactly the kind of silent single-domain misconfiguration that is hardest to find later.

How do you warm up hundreds of mailboxes?

Warmup happens in your sending tool, not at the infrastructure layer. Instantly, Smartlead, and ReachInbox all include warmup networks that exchange and engage with messages between participating mailboxes. To be clear about the division of labor: Inboxlogy provisions and authenticates the mailboxes; warmup runs in whichever sending tool you connect them to. Any vendor claiming to warm mailboxes for you is either running a tool on your behalf or describing something else.

A ramp that holds up:

Two things that break warmup: pausing it once campaigns start (reputation decays without positive signal), and ramping a whole cohort of 60 mailboxes on the same day. Stagger provisioning in batches of 15–20 per week so your fleet has mixed ages and you always have mailboxes finishing warmup as others are being retired.

How do you isolate clients so one bad campaign doesn't take down the rest?

This is what separates an agency setup from a scaled-up single-sender setup. Isolation boundaries you should enforce:

How do you monitor 100+ domains without checking each one manually?

Instrument these, and review weekly:

When should you retire a domain, and how does rotation work?

Treat domains as consumables with a service life. Retire a domain when any of these hold:

The recovery attempt is worth one try: pause all cold sending for 7–14 days, keep warmup running, then restart at 5 sends per mailbox per day. Light damage from a single bad list often recovers. If two weeks of rest produces no improvement, the domain is done. Stop sending from it and do not reuse it later. Retire the domain, keep the redirect live for a few months so old links don't 404, and promote a bench domain.

The operational pattern that makes this painless: keep 15–20% spare domains permanently in warmup so a retirement is a swap, not an outage. Budget for replacing a portion of your fleet on an ongoing basis rather than treating each retirement as a failure. Domains burn. The architecture exists so that it doesn't matter when they do.

What does this cost at agency scale?

For the 200-mailbox / 79-domain example above:

Roughly $650/month of infrastructure to support 5,000 daily sends, before tooling. The number worth watching isn't cost per mailbox, it's cost per replacement cycle: monthly billing and $0 setup mean retiring 12 mailboxes and provisioning 12 new ones is a routine line item, not a sunk annual commitment you're stuck sending from.

Pre-launch checklist

Before the first cold send from any new domain:

FAQ

Can a burned secondary domain damage the client's primary domain?

Not through sending reputation, provided the two are genuinely separated. Separate domains have separate reputations. Damage travels through shared elements: a shared tracking domain, a shared outbound IP, or an SPF record on one domain that includes the other. Keep those separate and the primary domain is insulated. One nuance worth knowing: if your cold emails link to the client's primary website, that URL accumulates link reputation from the campaign. It's a different signal from sending reputation and generally low-risk, but agencies sending very large volumes often link to a page on the sending domain or a neutral booking link instead.

How long does it take to stand up 200 mailboxes and start sending?

Plan on 4–6 weeks from purchase to full-volume sending. Provisioning and DNS can be done in a day or two through an API. The two weeks of warmup per mailbox is the fixed cost, and staggering cohorts across several weeks instead of launching all 200 at once adds time but produces a fleet with mixed ages that degrades gracefully.

Is it cheaper to buy 50 mailboxes on 5 domains instead of 17?

Marginally, and it's the wrong trade. Domains cost about $12/year; a burned domain costs you every mailbox on it plus a warmup cycle to replace them. Ten mailboxes per domain means one bad list removes 10 sending slots at once. Domain count is the cheapest insurance in this entire stack.

Do I need a warmup service separate from my sending tool?

No. Instantly, Smartlead, and ReachInbox all include warmup, and running two warmup systems against the same mailbox produces conflicting traffic patterns rather than better results. Infrastructure providers, Inboxlogy included, supply authenticated mailboxes. The warmup itself runs in whichever tool you connect them to, so pick one tool and let it manage the ramp.