Cold Email Infrastructure for Agencies: Domains, Inboxes, and Client Isolation

The failure mode that kills agencies is always the same. You land a fifth client, you're already running 40 mailboxes, and to move fast you reuse a couple of domains that are already warm. Six weeks later that client ships you a scraped list with a 14% bounce rate, the domains get torched, and now three other clients' campaigns are sitting in spam through no fault of their own. You spend the next month apologizing and rebuilding instead of selling.

Agency cold email infrastructure is not just "more mailboxes." It's a set of boundaries that make one client's mistakes survivable. Here's how to draw them.

{"h2": "The one rule: blast radius stops at the client"}

Everything below follows from a single principle — no reputation asset should ever be shared across two clients. Reputation in cold email lives at three levels: the IP, the domain, and the mailbox. You don't control the IP if you're sending through Google Workspace or Microsoft 365 (and you shouldn't want to — shared-IP relays are exactly the thing that makes one bad sender everyone's problem). So the boundaries you actually control are the domain and the mailbox.

That means: separate sending domains per client, separate mailboxes per client, separate DNS, separate warm-up, separate suppression lists, separate reply inboxes. If you can't answer "which client does this domain belong to?" instantly, your isolation is already broken.

{"h2": "Who owns the domain — and why you should decide before onboarding"}

There are two workable models and one that causes lawsuits.

{"ul": ["Client-owned domains. The client registers the secondary domain, you get DNS access or send them records to paste. Slower to set up (you'll wait days on their IT team), but the asset and the reputation stay with them. Best for enterprise clients, anyone with a procurement process, and any contract where the client expects to keep the pipeline if you part ways.", "Agency-owned domains, assigned to one client. You register and control everything, which makes setup same-day. Spell out in the contract what happens at churn: do you transfer the domains, keep them, or burn them? Decide this on day one, not during an exit conversation.", "Agency-owned domains shared across clients. Don't. One bad list and you've socialized the damage across your whole book."]}

Whichever you pick, the mailboxes and domains should be nameable back to the client without a lookup table. Something like `getacme.co` for Acme with mailboxes `firstname@`, not `outreach-pool-07.com`. Naming discipline is what keeps a 200-mailbox operation from becoming unauditable.

{"h2": "Sizing: how much infrastructure does each client actually need?"}

Work backwards from the client's daily volume target, assume 20–30 cold emails per mailbox per day as a sustainable ceiling, and put two to three mailboxes on each domain. Here's the shape of it:

{"table": {"headers": ["Client daily volume", "Mailboxes needed", "Domains needed", "Realistic ramp to full speed"], "rows": [["50/day", "2–3", "1", "3–4 weeks"], ["150/day", "6–8", "2–3", "4–5 weeks"], ["400/day", "15–18", "6–8", "5–6 weeks"], ["1,000/day", "35–45", "14–18", "6–8 weeks"]]}},

Two things agencies routinely get wrong here. First, they quote a start date that assumes mailboxes are productive on day one — they're not, and a new mailbox pushed to 30 sends a day in week one is a mailbox you'll be rebuilding in week three. Build the warm-up ramp into the proposal and the first invoice. Second, they under-provision domains because mailboxes are cheap and domains feel like overhead. Concentrating 12 mailboxes on one domain means a single domain-level reputation hit takes out the client's entire capacity at once. The math on this is covered in more detail in how many mailboxes you need to send 1,000 cold emails a day.

{"h2": "DNS hygiene, per client"}

Each client's domains get their own SPF, DKIM, and DMARC — no shared include chains, no copying one SPF record across clients because "it's the same provider." A few agency-specific notes:

{"ul": ["Set DMARC to `p=none` with an `rua` address you actually monitor during the first 30 days, then move to quarantine once you've confirmed alignment. Route aggregate reports to a per-client address so you can tell whose domain is failing.", "Keep SPF to a single include where possible. Agencies accumulate includes — the verification tool, the old ESP, a forwarding service — and quietly blow past the 10-lookup limit on a client domain they set up nine months ago.", "Set up a catch-all or forwarder on every sending domain so replies to a decommissioned mailbox don't hard-bounce back to a prospect.", "Put a real page on each sending domain. A one-page redirect to the client's site with a working MX and a visible company name is cheap insurance against domain-age and content checks."]}

{"h2": "Isolation that isn't technical"}

Domain separation is the easy half. The harder half is data and workflow separation, and this is where most agency tooling falls over.

{"ul": ["Suppression lists must be per client, with a global override. If Client A unsubscribes someone, that person shouldn't be silently removed from Client B's list — different companies, different consent. But your agency's own do-not-contact list (competitors, legal complaints, personal grudges) should apply everywhere. You need both layers.", "Reply inboxes must be separable. A unified inbox across 45 mailboxes is a productivity win right up until a junior SDR replies to Client A's prospect from Client B's context. Filter by client first, status second.", "Reporting must be client-scoped. You will eventually give a client read-only access, or export a report. Nothing in that view should reference another client's campaigns, lists, or mailboxes.", "Access control follows the account team. The freelancer writing copy for one client does not need login access to the infrastructure of the other eleven.", "Data processing obligations. If you're touching EU or UK contacts, you're a processor acting on the client's instructions. Per-client data boundaries make that defensible; a single shared lead database does not."]}

{"h2": "What you can safely share"}

Isolation doesn't mean rebuilding everything twelve times. Share the things that carry no reputation and no personal data: sequence templates and timing structures, subject-line patterns that have tested well, your spam-score checklist, your onboarding runbook, your ICP research process, your QA step before any campaign goes live. Share playbooks, not pipes.

{"h2": "Monitoring across the whole estate"}

Once you pass roughly 50 mailboxes, per-client checking stops scaling and you need one view that ranks every mailbox across every client by risk — bounce rate, reply rate, spam-complaint signals, authentication failures, sudden drops in verified engagement. The point is to catch a single degrading mailbox before it drags its domain down. We've written about monitoring hundreds of mailboxes without spreadsheets in detail; for agencies the only addition is that every alert needs a client tag attached so you know whose retainer is at risk and who to call.

{"h2": "Offboarding without leaving a mess"}

Churn is part of the model, so write the exit path into your runbook now:

{"ul": ["Pause all sequences immediately — not "at the end of the billing cycle," immediately. Emails going out after a contract ends are a real liability.", "Export the client's leads, suppression list, and reply history and hand it over. It's their data.", "Decide the domain's fate: transfer to the client, park it with forwarding for 90 days so in-flight replies don't bounce, or let it lapse. Never recycle it for a different client — the domain carries history tied to the old sender identity.", "Cancel or re-assign the mailboxes. A dozen forgotten $4–6/month mailboxes per churned client adds up fast."]}

{"h2": "How Sendvanta handles this"}

Sendvanta supports separate client workspaces, which is the practical version of everything above: each client gets its own mailboxes, domains, lead data, suppression list, unsubscribe handling, reply inbox, and reporting, while you keep one login and one cross-client view of deliverability health. Health scoring runs per mailbox and per domain, and when a client's risk thresholds are crossed the platform slows or pauses that client's sending without touching anyone else's.

Connecting your own Gmail, Microsoft 365, or SMTP mailboxes is free on every plan, including the $0 Free plan (1,000 active leads, 3,000 emails/month, up to 10 of your own SMTP mailboxes). Paid plans start at $29/month and can also buy managed mailboxes at $4/month each and register sending domains for a one-time $20 — useful when a client wants you to stand up infrastructure the same week. Sendvanta never routes mail through shared IPs, so a client's reputation is genuinely theirs. You can see the full feature set at /features.

The agencies that survive their own growth aren't the ones with the most mailboxes. They're the ones where a single bad client list is a one-client problem.