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

Agencies avoid burned domains by spreading volume thin instead of stacking it: 2-3 mailboxes per domain, 20-40 cold sends per mailbox per day, a separate domain pool per client, and authorized Google Workspace or Microsoft 365 mailboxes they own outright. A 300-mailbox fleet is roughly 100-150 domains, not 10 domains working overtime. The domains that die get retired and replaced as a routine cost rather than rescued.

That's the whole model. Everything below is the operational detail: how to size a fleet, how to configure 100+ domains without DNS mistakes, how to ramp, how to spot a domain going bad two weeks before it flatlines, and when to stop trying to save one.

What actually burns a domain?

Volume alone doesn't burn domains. Concentration, complaints, and bad lists do. The specific causes, in rough order of how often they kill agency fleets:

• Spam complaints. Google publishes the threshold it cares about: keep your reported spam rate below 0.3%, and ideally under 0.1%, measured per sending domain in Postmaster Tools. Three complaints per thousand sends is not a lot of room. Complaints follow bad targeting far more than bad copy.
• Bounces from unverified lists. High invalid-address rates are the clearest "this is a scraped list" signal a receiving provider has. Hitting a spam trap, an address that exists only to catch senders who didn't earn it, can damage a domain immediately.
• Broken or misaligned authentication. SPF, DKIM, and DMARC that don't pass and align with the From domain. At scale this is usually a copy-paste error on domain #47, not a knowledge gap.
• Concentration. Ten mailboxes on one domain sending 50 each is 500 messages a day from one identity. The domain carries all the risk of all the campaigns, so one bad list segment takes down everything on it.
• Shared sending reputation you don't control. Cheap "SMTP panel" mailboxes often sit in pools alongside hundreds of other senders. You inherit their behavior, and you can't audit or fix it.
• Content fingerprints. The same template, the same tracking domain, and the same links across your entire fleet links every domain together in the eyes of a filter. One pattern gets classified, all of them inherit the classification.
• Ignoring opt-outs. The fastest way to convert a mild annoyance into a complaint is to email someone who already asked you to stop.

Note what's not on this list: domain age, sending on weekends, using the word "free," and most of the folklore. Those matter far less than list quality and complaint rate.

How many mailboxes should I put on one domain?

Two to three. Some agencies run five on well-established domains. The reason to keep it low isn't a published provider limit. It's blast radius. A domain is the unit that gets reputation-damaged, so a domain is the unit you want to be able to lose cheaply.

At three mailboxes and 30 sends each, a domain carries ~90 cold sends a day. If it goes bad, you've lost 90 sends of capacity and three mailboxes, and your other 100 domains don't notice. At ten mailboxes and 50 sends, you've built a single point of failure that costs you 500 sends a day when it breaks.

Per-mailbox daily volume: 20-40 cold sends is the conservative working range most agencies settle on for Workspace and M365 mailboxes, excluding replies and follow-ups inside existing threads. Pushing a single mailbox to 100+ cold sends a day is where agencies reliably get into trouble.

How many domains do I need for a given fleet size?

Work backwards from the sends you need, not from a mailbox count someone quoted you.

• Target: 9,000 cold sends per day across all clients.
• At 30 sends/mailbox: 300 mailboxes.
• At 3 mailboxes/domain: 100 domains.
• Plus a bench: 10-20% spare capacity, already provisioned and ramped, so a retirement doesn't cost you a campaign. Call it 110-120 domains and 330-360 mailboxes.

Two things fall out of that math. First, per-mailbox cost dominates your infrastructure budget at this scale, which is why pricing matters more than it looks. 350 mailboxes at $2.80/mailbox/month is under $1,000/month, while the same fleet at $7-10 per mailbox is a line item you'll feel. Second, you need domain registration and DNS to be automated, because 120 domains configured by hand will contain mistakes.

What does a 300-mailbox fleet actually look like?

The structural decision that separates agencies that scale from agencies that keep rebuilding is isolation. Risk should be contained inside a client, ideally inside a campaign.

A workable layout for ten clients:

• Per client: 10-12 secondary domains, 3 mailboxes each, giving ~30-36 mailboxes and ~900-1,000 sends/day.
• No domain shared across clients, ever. If Client A's SDR imports a purchased list, the damage must stop at Client A's pool. Shared domains turn one client's mistake into an agency-wide outage.
• A separate tracking domain per client (per pool is better). A shared tracking domain is a shared fingerprint across every campaign you run.
• Sub-pools inside a client: split the client's domains into two or three groups and run different campaigns, offers, or segments on each. When one offer draws complaints, you lose a sub-pool, not the client's whole fleet.
• A bench pool: 2-4 domains per client provisioned, authenticated, and ramped but idle, so a retirement is a swap rather than a three-week rebuild.
• The client's real brand domain: never in the sending fleet. See below.

Should I ever send cold email from the brand domain?

No. The brand domain carries invoices, password resets, support threads, and the sales team's live conversations. Cold outreach puts a reputation asset with real revenue attached behind the riskiest sending you do.

Use secondary domains instead, close variants that a prospect who looks them up finds credible: getacme.com, acme-hq.com, tryacme.io, acmehq.co. Practical rules:

• Stick to mainstream TLDs (.com, .co, .io, .net). Cheap bulk TLDs carry worse baseline reputation because of how they're used.
• Don't typosquat anyone. A homoglyph of another company's domain is a trademark problem and a filter trigger.
• Put something at the domain. A one-page site or a 301 redirect to the client's main site. A parked registrar page undercuts every email you send from it.
• Turn catch-all off. Catch-all makes your bounce data meaningless, because you stop learning which addresses were invalid, and it collects inbound spam.
• Skip subdomains of the brand domain. It feels tidy, but it links cold sending reputation to the domain you were trying to protect.

How do I configure 100+ domains without DNS mistakes?

Each sending domain needs MX records pointed at the mailbox provider, an SPF record, a DKIM key published, a DMARC record, and usually a CNAME for the tracking domain. That's five or six records per domain and 600+ records across a fleet of 120. Hand-entering that is how agencies end up with a pool that silently fails DKIM for a month.

Three rules that hold regardless of who you buy from:

• Automate record creation, then verify independently. Generate the records programmatically, then check them with an external lookup rather than trusting your provider's own green checkmark. Confirm SPF passes, DKIM signs with a key that resolves, and the DKIM domain aligns with the From domain.
• One SPF record per domain, under ten DNS lookups. Two SPF TXT records is a permanent fail, and it's the single most common fleet-wide misconfiguration.
• Start DMARC at p=none with a reporting address, then tighten. On cold sending domains p=none is adequate and keeps you compliant with bulk sender requirements. On the client's actual brand domain, work toward p=reject. That's a security control worth having.

This is the main reason agencies stop building fleets themselves. Inboxlogy automates SPF, DKIM, and DMARC at provisioning time and exposes a full API, so standing up 30 mailboxes with correct DNS for a new client is a scripted operation rather than an afternoon of console work. Retiring a pool is equally scripted, which matters because you'll do it repeatedly.

What's the right ramp schedule, and where does warmup run?

New mailboxes have no sending history. Going from zero to 40 cold sends on day one is the most avoidable way to burn a fresh domain. Ramp over three to four weeks:

• Week 1: warmup only, no cold sends.
• Week 2: warmup plus 5-10 cold sends per mailbox per day.
• Week 3: 15-20 cold sends per mailbox per day.
• Week 4 onward: 25-40, held steady. Stop increasing at the number you can sustain, not the number the mailbox tolerates.

Keep a low level of warmup running after the ramp rather than switching it off. And be clear on where warmup lives: Inboxlogy does not run warmup. Warmup runs inside your connected sending tool, Instantly, Smartlead, or ReachInbox, which is where your sequences, sending schedule, and warmup pool already are. Inboxlogy provides the mailboxes and the authenticated domains; your sending tool warms and sends from them. Treat any provider claiming its warmup alone will protect a fleet with suspicion: warmup generates engagement signal, it does not offset a bad list.

Which mailbox infrastructure holds up, and what should I insist on owning?

There are three common ways to get hundreds of mailboxes, and they are not equivalent.

• Authorized Google Workspace / Microsoft 365 mailboxes. Real tenants on the two platforms your prospects actually use. Best deliverability to Gmail and Outlook, legitimate admin tooling, and nothing to unwind later.
• SMTP panels and self-hosted mail servers. Cheapest per mailbox. You're often in a shared IP pool whose other tenants you can't see, and you inherit their behavior. Viable only if you genuinely want to run mail server operations.
• Grey-market Workspace resellers. Cheap, and the tenant frequently isn't yours. When the reseller's arrangement ends, your client's mailboxes end with it.

Regardless of vendor, insist on three things in writing:

• Domains registered in an account you control. If the vendor holds the registrar account, they hold the client's sending identity.
• Super-admin access to the tenant. You need to add and remove users, pull logs, reset credentials, and export mailbox data without filing a ticket.
• Month-to-month billing. You will retire domains. Annual prepayment on infrastructure with planned attrition is money you can't redeploy.

This is the specific gap Inboxlogy fills for agencies: authorized Google Workspace and Microsoft 365 mailboxes with 100% ownership and admin access, dedicated US/EU IPs rather than a shared reseller pool, $0 setup, and monthly billing, so a retired pool stops costing you the month you retire it.

How do I spot a domain going bad before it's dead?

The lagging indicator is reply rate collapse, and by the time you see it the domain has been in the spam folder for a while. Watch these instead, per domain and per mailbox:

• Hard bounce rate. Investigate above 2-3%; pause the pool above 5%. A spike almost always means a list problem, not a domain problem. Fix the list before you blame the domain.
• Soft bounces and deferrals mentioning reputation or rate limits. These arrive in plain language in the SMTP response. Read them. They are the earliest honest signal you get.
• Reply rate per domain, not per campaign. Same copy, same list, same offer: if one domain's reply rate drops while its siblings hold, the domain is the variable.
• Spam rate in Google Postmaster Tools for any domain with enough Gmail volume to report. Above 0.3% is Google telling you directly.
• A small manual seed check. A handful of real Gmail and Outlook accounts you own, checked weekly by hand. Don't optimize against automated "inbox placement scores"; they're a rough proxy and easy to overfit to.
• Authentication drift. Re-verify SPF/DKIM/DMARC on the whole fleet monthly. Records get edited, DNS providers get migrated, keys get rotated.

When should I retire a domain, and can I save a burned one?

Retire when bounce rates stay elevated after you've cleaned the list, when reply rate stays flat across multiple clean campaigns while sibling domains perform, or when Postmaster shows a sustained high spam rate. Pull it, swap in a bench domain, and move on.

Can you recover it? Sometimes, partially, by stopping all cold sending for several weeks and running only warmup and genuine conversation. But recovery is slow, unreliable, and competes for attention with work that pays. At a few dollars a mailbox, a replacement domain costs less than the hours you'd spend nursing a damaged one. The expensive mistake is the sunk-cost loop: agencies that keep campaigns running on a declining pool for another month lose far more in results than the domain was worth.

Budget for attrition from the start. Keep the bench stocked, and treat domain replacement as a normal line item like any other consumable.

What list and copy discipline does the whole fleet depend on?

Infrastructure determines whether you can deliver. Targeting determines whether you get to keep delivering. The strongest fleet in the world burns down under a purchased list.

• Verify every list before import, and drop or quarantine catch-all and role addresses (info@, sales@, support@) into a separate low-volume bucket.
• Maintain one global suppression list across every client. Opt-outs, past customers, competitors, and anyone a colleague is already in conversation with. Double-contacting the same prospect from two of your clients generates complaints and embarrasses both.
• Process opt-outs immediately and across the fleet, not just within the campaign that triggered them.
• Keep messages plain. Text, one link at most, no images, no tracking pixel, a real signature with a real physical address. Open tracking buys you a noisy metric and costs you a link to a shared tracking domain. Many agencies have dropped it entirely and optimize on replies.
• Vary copy across pools. Identical templates fleet-wide let a single classification decision affect every domain you own.
• Stay inside the law. CAN-SPAM requires accurate headers, a physical postal address, and a working opt-out. EU and UK recipients bring GDPR and ePrivacy considerations that vary by country. Get this reviewed once properly rather than guessing per campaign.

What does the weekly operating cadence look like?

Running a fleet of this size is a routine, not a project:

• Daily: check deferrals and bounce spikes; pause any pool crossing 5% hard bounces.
• Weekly: per-domain reply rates, manual seed check, process the suppression queue, advance any ramping mailboxes one step.
• Monthly: full fleet authentication audit, Postmaster review for high-volume domains, retire and replace flagged domains, top the bench back up.
• Quarterly: review per-client capacity against actual pipeline, and cut mailboxes you aren't using. Idle mailboxes are the quietest cost in an agency.

FAQ

How long does it take to get a 300-mailbox fleet to full sending volume?

Three to four weeks. Provisioning domains and mailboxes with correct DNS can happen in a day if it's automated, but the ramp is the constraint and it can't be compressed safely. Plan the build four weeks before the campaigns are supposed to launch.

Is Google Workspace or Microsoft 365 better for cold email?

Both work, and most agencies at scale run a mix. A practical reason to split: it diversifies your fleet, so a change in one provider's filtering doesn't affect all of your capacity at once. If your prospects are concentrated on one platform, having some mailboxes on that same platform is a reasonable hedge.

Do I need dedicated IPs for cold email?

What you need is to not share sending reputation with senders you can't see or control. Shared pools on cheap panels are the actual risk, because your results move with other tenants' behavior. Inboxlogy runs dedicated US/EU IPs for this reason. Regional choice also matters for latency and for data-residency commitments you may have made to EU clients.

Can I just use one domain with 50 mailboxes instead?

You can, and it'll work until it doesn't, at which point you lose 50 mailboxes and every campaign running on them in the same hour. The domain-to-mailbox ratio isn't about deliverability limits, it's insurance. Spreading 150 mailboxes across 50 domains costs almost nothing extra and converts a catastrophic failure into a routine one.