How Agencies Set Up Hundreds of Cold Email Inboxes Without Burning Domains

Agencies avoid burning domains by spreading sending across many cheap secondary domains instead of one. The usual shape is 2–3 mailboxes per domain, 20–40 emails per mailbox per day, on fully authenticated, provider-authorized Google Workspace or Microsoft 365 accounts they own outright. Domains get treated as consumable assets: a bad one is retired, not rescued. The infrastructure is the easy part. What actually burns domains is list quality, ramp speed, and shared link reputation.

Here is the architecture and the operating discipline, in the order you'd build it.

Why do cold email domains actually get burned?

In rough order of how often they're the real cause:

Only two of those are infrastructure problems. Most "my domains got burned" incidents are list and ramp problems that arrive dressed as infrastructure.

Should you ever send cold email from your main domain?

No. Your primary domain carries your transactional email, your sales team's one-to-one replies, your invoices, your password resets. Cold outbound is a reputation-risk activity, and you never put it on the same domain as mail you cannot afford to have filtered.

The standard pattern is a fleet of secondary sending domains that are plausible variants of the brand: getacme.com, acme-hq.com, tryacme.io, acme.team. Each one 301-redirects to the main site, or better, serves a thin one-page site with the company name, a short description, and contact details. A domain with no website at all is a weak signal. A domain that resolves to something real is a strong one.

Avoid: expired domains with unknown history (check them against Spamhaus DBL and the Wayback Machine before buying), free or unusual TLDs with poor reputation, and anything that could read as impersonating a company you don't own.

How many mailboxes should you put on one domain?

Two to three. Some agencies run up to five on aged domains with months of clean history. More than that and you've recreated the single-domain risk you were trying to avoid.

The logic: domain reputation is the unit that gets burned. If one mailbox picks up complaints, the domain degrades, and every mailbox on it degrades with it. Three mailboxes per domain means a bad cohort costs you three inboxes, not thirty. It also matches what a real small company looks like: a handful of named humans rather than a wall of aliases.

Use real-sounding first-and-last-name addresses with a matching display name, a filled-in profile photo, and a signature containing a physical mailing address and an opt-out line. Role addresses like sales@ or info@ are weak performers for cold outbound and often filtered harder.

How many inboxes do you need for your volume target?

Work backwards from a sustained ceiling of 20–40 cold emails per mailbox per day after warmup. The provider quota is far higher; Google Workspace allows thousands of recipients per user per day. But quotas aren't your limit, reputation is. Push a mailbox to its quota on cold traffic and you'll learn what the quota is really there to catch.

At 30/day per mailbox and 3 mailboxes per domain:

Then add 20–30% reserve capacity that is always in warmup, so that when you retire a cohort you have warm inboxes ready instead of a two-week hole in your pipeline. Without that reserve, every retirement turns into a scramble.

One caveat. If your answer to a 1% reply rate is 10,000 emails a day, infrastructure isn't your constraint. Volume is a lever of last resort, and it's the most expensive one to operate.

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

Every sending domain needs all three, correct on day one, before a single email goes out. Google and Yahoo's bulk sender requirements (February 2024) and Microsoft's high-volume sender requirements (effective May 2025) made SPF, DKIM, and a published DMARC policy table stakes for anyone sending at scale to Gmail and Outlook.

At 50+ domains, doing this by hand in a registrar UI guarantees drift. Either script it against your DNS provider's API (Cloudflare's is the usual choice) or use infrastructure that writes the records for you. Inboxlogy provisions SPF, DKIM, and DMARC automatically per domain, which removes the most common category of self-inflicted deliverability bug: the kind you don't notice for three weeks.

Google Workspace, Microsoft 365, or a private SMTP relay?

For cold outbound, hosted Google Workspace and Microsoft 365 mailboxes are the default. They're real mailboxes at providers whose reputation is already excellent, they handle replies natively, and recipients' filters treat them as ordinary business mail.

Private SMTP relays give you IP-level control and much cheaper volume, but you are starting a brand-new IP reputation from zero and you own every mistake. They make sense for high-volume marketing sends, rarely for cold B2B prospecting where you need replies to land in a human's inbox.

One clarification on IPs, because the topic gets oversold. With hosted Workspace or M365, the final outbound hop belongs to Google or Microsoft, so your main lever is domain reputation, not IP reputation. Dedicated IPs genuinely matter at the connection layer: the IPs your sending tool authenticates from, and how geographically consistent those sessions look. Hundreds of senders logging into mailboxes from the same recycled residential proxy pool is a real trigger for security locks and reauthentication loops. Inboxlogy assigns dedicated US and EU IPs, so your mailbox sessions aren't sharing a neighborhood, and your sending geography stays consistent with your tenant region.

Why do bulk-created Workspace and M365 accounts get suspended?

Because many cheap bulk-mailbox vendors create them through unauthorized channels: one giant reseller account, abused trial flows, or tenants registered under the vendor's name with the vendor as super-admin. When Google or Microsoft notices the pattern, they suspend at the account or tenant level, and you lose every mailbox under it at once. You find out when your campaigns stop sending.

The second problem is ownership. If the vendor holds the tenant and the domains, you cannot migrate, you cannot export mailbox data, and you cannot take the asset to a client when the relationship ends. You're renting an address you've spent three months building reputation on.

Two questions to ask any mailbox vendor, and the answers you want:

This is the specific reason Inboxlogy exists in this category: authorized Google Workspace and Microsoft 365 mailboxes with 100% ownership and full admin access. If you leave, the infrastructure is still yours. It's also what lets you hand a client's inboxes over at offboarding instead of deleting them.

How should mailboxes be spread across tenants?

Don't put 300 mailboxes in one tenant. Tenant-level suspension or throttling is a single point of failure, and a 300-user organization sending nothing but cold email to strangers is a conspicuous shape.

Split into multiple smaller tenants. One per client is the cleanest rule, and it doubles as your client-isolation boundary. Microsoft also enforces a tenant-level external recipient rate limit in Exchange Online on top of per-mailbox limits, scaled to your license count, so a dense single-tenant setup can hit a ceiling you didn't know existed. Check the current published figures before you size a tenant. Microsoft has changed them more than once.

How do you warm up hundreds of inboxes?

Warmup runs in your sending tool, not at the infrastructure layer. Instantly, Smartlead, and ReachInbox all include warmup networks, and that's where you configure it. Inboxlogy does not run warmup itself; it delivers the mailboxes and DNS, and you connect them to whichever tool you already use. If a vendor claims to do both, ask follow-up questions.

A workable ramp, per mailbox:

Three to four weeks from provisioning to full capacity is normal. Treat that as a hard constraint and provision ahead of demand. Selling a campaign on Monday and buying inboxes on Tuesday is how deliverability emergencies start. Keep a light warmup running permanently; it maintains engagement signals during campaign gaps.

Also: randomize send times and intervals, cap daily volume per mailbox in the tool (not just per campaign), and stagger cohort start dates so you're never ramping your entire fleet simultaneously.

What's the shared asset that can burn your whole fleet at once?

Your links. Sixty domains, 180 mailboxes, and every email points at acme.com/demo and one Calendly URL. Mailbox providers evaluate URL reputation independently of sending domain reputation, so a bad list on one cohort can degrade placement for every cohort that shares those links.

How to manage it:

How do you keep bounce and complaint rates under the thresholds?

Hard rules worth enforcing in process, not in good intentions:

If you're sending into the EU or UK, do the GDPR work properly. B2B legitimate interest can be a valid basis, but it requires relevance to the recipient's professional role, a clear identity, an easy objection path, and a documented assessment. "We bought a list" is not a lawful basis.

How do you monitor hundreds of domains without drowning?

You need three layers, and only the third needs daily attention:

Maintain a single inventory record: domain, registrar, DNS zone, tenant, mailbox addresses, client, provision date, warmup completion date, current daily cap, status. A spreadsheet works to about 100 mailboxes. Past that, keep it in a database and drive it from your provider's API. Inboxlogy exposes a full API for provisioning and management, which is what makes "spin up 40 mailboxes across 14 new domains for a new client" a script instead of an afternoon.

How often do you replace domains and inboxes?

Treat sending domains as consumables with a lifespan, not assets to be rehabilitated. Once a domain is genuinely burned (bad reputation in Postmaster, a DBL listing, reply rate collapsed), recovery is slow, unreliable, and usually costs more in opportunity than a $12 replacement.

Practical cadence: rotate out a portion of your fleet continuously, replace anything that degrades immediately, and keep the warmup reserve stocked so replacement is invisible to campaign output. Budget for it as a monthly line item rather than a surprise.

When you retire a domain: stop sending, keep the mailboxes alive long enough to catch late replies, retire its redirect links, and don't reuse the name.

How do agencies keep clients isolated from each other?

Strictly. Never share a domain or a mailbox between two clients, and never share a tenant if you can avoid it. The reasons are practical and contractual:

Because Inboxlogy mailboxes come with full ownership and admin access, that handover is a transfer rather than a deletion.

What does 200 inboxes actually cost?

Concrete math for a 200-mailbox fleet at 3 mailboxes per domain (~67 domains):

So roughly $615–645/month for the infrastructure layer of a 200-inbox fleet, before your sending tool and data. At 30 emails/day per mailbox that's ~6,000 sends/day of capacity. Compare that to buying mailboxes retail at list price per user, which is where most agencies' first attempt at this stops being viable. Monthly billing matters more than it sounds: fleets flex with client count, and annual commitments on infrastructure you rotate are a bad match.

What does a clean rollout look like?

FAQ

Can a burned domain be recovered?

Occasionally, if the damage was mild and caught early. Stop all sending, fix authentication, fix the list, then re-warm slowly over 4–8 weeks. But a domain costs about $12 and a recovery attempt costs weeks of uncertain capacity, so for most agencies replacement is the right call. Keep rehabilitation for domains with genuine brand value, which cold-email secondaries don't have.

Is it better to use many domains with few mailboxes, or fewer domains with more mailboxes?

Many domains, few mailboxes each. Domain reputation is the unit that gets burned, so distributing across more domains compartmentalizes risk and keeps per-domain volume in a range that looks like a real business. The tradeoff is DNS and inventory overhead, which is exactly the thing worth automating via API.

Do I still need warmup if I buy aged domains?

Yes. Domain age helps, but the mailbox is new and has no sending history of its own. Aged domains let you ramp somewhat faster and support slightly more mailboxes. They don't let you skip the ramp.

Does Inboxlogy handle warmup?

No. Inboxlogy provides the mailboxes, domains, DNS authentication, and dedicated IPs. Warmup runs inside your connected sending tool: Instantly, Smartlead, or ReachInbox. That separation is deliberate. You keep whichever campaign platform your team already knows, and the infrastructure stays yours regardless of which tool you switch to next.