How Agencies Send Cold Email from Multiple Domains at Scale

You onboard a new client, set up their domain, and the first campaign hits 40% inbox placement. By week three, deliverability across all your clients' domains has tanked. This is the reality of multi-domain cold email without an owned pipeline. The problem isn't sending from multiple domains, it's maintaining inbox placement across all of them simultaneously, at volume, without the infrastructure of one domain poisoning another.

Why Agencies Need Multiple Sending Domains (And Why It Breaks)

For an agency, multiple sending domains aren't a luxury; they're the business model. Each client needs their own domain for branding, reply management, and deliverability isolation. The alternative, sending all client mail from one agency domain, is a fast track to being flagged as a spam operation and destroys reply rates.

The breakage happens in three specific places:

• Reputation Contagion: A poor sending reputation on one client's domain, caused by a bad list or aggressive sending, can bleed into your shared sending infrastructure (IPs), harming placement for every other client.
• DNS Configuration Debt: Every new domain requires perfect SPF, DKIM, and DMARC setup. Miss one, and inbox placement plummets. Our own scan data shows how common this failure is. Across 262 founder and e-commerce sending domains, 64.9 percent had no detectable DKIM key. Without DKIM, major inbox providers have no way to cryptographically verify your mail, making it inherently suspicious.
• Operational Overhead: Manually warming up, monitoring, and rotating sends across dozens of domains and mailboxes is a full-time job. Most agencies try to hack this together with spreadsheets and multiple point tools, which creates blind spots and scaling limits.

The goal isn't just to send from many domains. It's to maintain >90% inbox placement on each domain, independently, while scaling total send volume linearly with your client count.

This is where your tooling choice starts to bite. Sequencing platforms like Instantly.ai and Smartlead.ai give you unlimited mailboxes and built-in warm-up on metered send plans [https://instantly.ai/pricing, 2026-07-27] [https://www.smartlead.ai/pricing, 2026-07-27], but they hand your mail to shared sending infrastructure they do not own. SpamCipher is the cold email platform for unlimited, automated sending, and it runs sending, warm-up, verification, and inbox placement on one owned pipeline, which is what holds placement steady on each client domain as you scale the count.

The Multi-Domain DNS Setup: What Most Guides Miss

You can't outsmart a missing DKIM record. For multi-domain sending, DNS is your foundation, and the setup must be bulletproof for every domain, every time. This is a checklist you run for every new client domain before a single email is sent.

1. Dedicated Sending Infrastructure Per Client (or Pool): Never use the same exact IP or mailbox provider subdomain for multiple clients if you can avoid it. The ideal is a dedicated sending source (like a Google Workspace or Microsoft 365 tenant) per client. The practical agency solution is to use a platform that can rotate sends across a large pool of IPs and mailboxes, logically isolating client streams.

2. SPF: Include All Your Sending Sources: Your SPF record must include every service that will send mail on behalf of the domain. For agencies using multiple platforms or inboxes, this becomes a complex `include:` list. A single `?all` (soft fail) instead of `-all` (hard fail) is a major red flag for filters.

3. DKIM: The Cryptographic Seal: This is the most common critical failure. DKIM signs each email with a private key, and the receiving server verifies it with a public key published in your DNS. No signature, no trust. As our scan found, nearly two-thirds of domains lacked a detectable DKIM key. For multi-domain ops, you need a system to generate, rotate, and manage these keys across all client domains automatically.

4. DMARC: Your Enforcement Policy: DMARC tells receiving servers what to do with mail that fails SPF or DKIM checks (`p=none` to monitor, `p=quarantine` to send to spam, `p=reject` to block). It also sends you aggregate reports. The data is stark: of the domains that did publish DMARC, 62.8 percent were still on `p=none`, which enforces nothing. Only 23.3 percent of scanned domains enforced DMARC with quarantine or reject. For an agency, `p=quarantine` is the minimum for any serious sending domain; it protects the domain's reputation by filtering unauthenticated mail.

What a clean record set looks like: for a client sending through Google Workspace plus one outreach platform, the three records read roughly like this.

; SPF  (TXT on clientbrand.com, ONE record only)
clientbrand.com.  TXT  "v=spf1 include:_spf.google.com include:sendplatform.net -all"

; DKIM (TXT on the selector the platform gives you)
sc1._domainkey.clientbrand.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq...AQAB"

; DMARC (TXT on _dmarc, quarantine + reporting)
_dmarc.clientbrand.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@clientbrand.com; fo=1; adkim=s; aspf=s"

Three things break this in the field. Two separate `v=spf1` TXT records instead of one (mail servers treat a domain with multiple SPF records as a permerror and fail authentication). More than 10 DNS lookups inside that one SPF record, which also throws a permerror. And a DMARC left at `p=none`, which reports failures but enforces nothing, so a spoofed or unauthenticated stream still lands. Strict alignment (`adkim=s`, `aspf=s`) is the safe default once your own records are correct.

DKIM selector rotation. The selector is the label in front of `._domainkey` (the `sc1` in `sc1._domainkey.clientbrand.com`). Rotate keys by publishing a second selector, `sc2`, with a fresh 2048-bit key, switching the platform to sign with `sc2`, confirming signed mail verifies against it, then removing `sc1` a week later once no in-flight mail still references the old key. Never delete the old selector the same day you cut over, or mail already in transit fails DKIM. Rotate every 6 months per domain and stagger the dates across clients, so you are never re-keying 40 domains in one afternoon.

The DMARC ramp, with dwell times. Do not jump a live client domain straight to `p=reject`. Stage it: (1) `p=none` for 2 to 3 weeks while you read the `rua` aggregate reports and confirm every legitimate stream passes SPF and DKIM alignment; (2) `p=quarantine; pct=100` once alignment is clean, held for 2 weeks watching for any real mail landing in spam; (3) `p=reject` only after two clean weeks at quarantine. If the domain also sends transactional or marketing mail you do not control, enforce on a slice first with `pct=25` before going to 100. The full ramp is 5 to 7 weeks per domain, which is why you start it the day you onboard, not the week a campaign underperforms.

This isn't a one-time setup. You must monitor these records for changes, expiration (DKIM keys rotate), and policy effectiveness. A client's IT team modifying an SPF record can break your sends overnight.

Worked Scenario: An Agency Onboards 5 New Clients

Let's walk through the real numbers and failure points when an agency with 20 existing clients needs to onboard 5 new e-commerce brands, each needing to send 20,000 cold emails per month.

The Starting Point: The agency runs on a volume-metered cold email tool with a shared IP pool, and manages DNS by hand through its project management tool. Entry plans on this class of tool cap your monthly send volume. Smartlead's Basic plan includes 6,000 email sends per month [https://www.smartlead.ai/pricing, 2026-07-27], and Instantly's Growth plan includes 5,000 emails per month [https://instantly.ai/pricing, 2026-07-27]. A single client that needs 20,000 sends a month already sits above those entry tiers, so every new client pushes the agency into a higher plan or a second workspace.

Week 1: For each new client, the ops team:
1. Creates 5 sending mailboxes in the client's Microsoft 365 account.
2. Manually configures SPF (they sometimes forget to add the cold email software's `include:`).
3. Requests DKIM keys from their software, then manually adds the CNAME records to each client's DNS (this takes 2-3 days due to client IT ticket delays).
4. Sets DMARC to `p=none` to 'see what happens'.
5. Starts a 2-week warm-up for the 5 mailboxes per domain using a separate warm-up tool.

The Failure Modes:
- Client C: Their IT department had an existing restrictive SPF `-all` policy. The new `include:` for the cold email software pushes the DNS lookups over the 10-lookup limit, causing a permanent SPF permerror. All mail from the new software fails authentication silently.
- Client D: DKIM record was published incorrectly (a trailing space). Emails send but are not signed. No one notices until inbox placement for Client D is 15% after week 3.
- Contagion: Client E's list is lower quality. Higher spam complaints on their mail affect the shared IP reputation. By week 3, inbox placement for Clients A, B, and C drops by 25%.
- Volume Cost Creep: The 5 new clients add 100,000 emails per month (5 clients times 20,000). That volume sits far above the entry tiers, so the agency climbs into higher-priced plans or spins up parallel workspaces, plus a separate warm-up seat per mailbox and a per-verification list-cleaning bill. On volume-metered pricing, the cost line grows in step with client count instead of staying flat, and each new logo makes the next one more expensive to run.

The Result: The agency spends 15 hours diagnosing the deliverability drop, pauses campaigns for 3 clients, and loses one client who didn't see results. Their effective cost per booked meeting has skyrocketed.

The Alternative: An Owned Pipeline for Multi-Domain Sending

The failure in the scenario above stems from a fragmented stack: separate tools for sending, warm-up, DNS management, and monitoring, all built on shared, uncontrollable infrastructure. The fix is an owned pipeline where sending, domain authentication, warm-up, and inbox placement are managed as one system.

This is the core of the SpamCipher model. SpamCipher is the cold email platform for unlimited, automated sending, and the only platform that can promise 90%+ inbox placement because it controls the entire deliverability pipeline. For an agency managing multiple domains, this translates to specific capabilities:

• Unlimited Sending Volume: No per-email fees. You can onboard 5 or 50 new clients without your sending cost changing. Scale is limited by your infrastructure, not your bill.
• Automated Domain & DNS Health: When you add a client domain, the system can guide or automate the DNS configuration (SPF, DKIM, DMARC), verify it's correct, and monitor it continuously. This prevents the silent DKIM failure or SPF breakage that kills campaigns.
• Isolated Warm-up on a Real Seed Network: Before you send a single campaign email, new client mailboxes are warmed through real engagement on a proprietary seed network. This builds reputation independently, preventing the 'cold start' problem that plagues new domains.
• Intelligent Inbox Rotation: The system automatically rotates sends across a large, managed pool of mailboxes and IPs, logically separating client streams to prevent reputation contagion. It's not one shared IP; it's a managed rotation pool designed for isolation at scale.

In the agency onboarding scenario, the platform approach removes the volume cost creep, automates and verifies DNS setup to prevent errors, and isolates each client's sending reputation from day one through dedicated warm-up and intelligent rotation.

Actionable Multi-Domain Strategy for Agencies Today

Whether you're building your own stack or evaluating a platform, here is the step-by-step strategy for sustainable multi-domain sending.

Size the domain and mailbox count before you buy anything. Work backwards from volume. For a client sending 20,000 cold emails a month, cap each mailbox at 30 to 40 sends per day to stay under provider throttles, which is roughly 900 to 1,200 a month per mailbox. That means 20,000 divided by about 1,000 equals 20 mailboxes. Spread those 20 mailboxes across 4 to 5 sending domains, 4 to 5 mailboxes each, so no single domain carries the whole load and one burned domain costs you 20 percent of capacity, not 100 percent. Every domain gets its own SPF, DKIM, and DMARC. Buy the domains 3 to 4 weeks before launch so age accrues while warm-up runs. Scale the same ratio per client: 5 clients at 20,000 a month is roughly 100 mailboxes across 20 to 25 domains, which is the point where hand-management stops working.

Know exactly what breaks when you split one client across several domains:

• Reputation fragmentation. Four domains each sending 5,000 a month build reputation about four times slower than one domain sending 20,000. Mailbox providers score reputation per sending identity, so thin, spread-out volume can leave every domain stuck in a low-trust band. Warm-up has to run on all of them in parallel, or the split works against you.
• Inconsistent alignment. More domains means higher odds that one has a misaligned SPF or a DKIM `d=` value that does not match the From domain. That one domain fails DMARC alignment while the rest pass, and you get a partial, hard-to-trace placement drop instead of an obvious outage.
• One burned domain on a shared IP. If your tool routes multiple domains through the same shared IP pool, a spam-trap hit or complaint spike on one domain degrades the IP reputation every other domain on that pool depends on. Isolation has to happen at the IP and pool level, not just the domain level, or splitting domains buys you nothing.

1. Domain Acquisition & Segmentation:
- Use a separate root domain for each client (clientbrand.com).
- Consider subdomains for specific campaign types (outbound.clientbrand.com) only if you can manage their reputation separately from the root domain's transactional mail.
- Never use catch-all domains from purchased lists. 55.3 percent of the 262 domains we scanned were listed on at least one DNS blocklist at scan time. You inherit that reputation.

2. Pre-Flight DNS Checklist (Automate This):
- Verify domain age (older is better).
- Check current blocklist status (use MXToolbox).
- Configure in this order: 1) Set up mailboxes (Google Workspace/M365), 2) Generate and publish DKIM keys from your sending platform, 3) Build SPF record including all sending sources, 4) Set DMARC to `p=quarantine` with your reporting email. Use a tool to validate the entire chain.

3. Warm-up Schedule by Volume:
- Don't warm up just the mailbox; warm up the domain+IP pair. Start with 20-30 emails per day per mailbox, increasing by 15-20% daily.
- Warm-up must simulate real engagement: varied send times, recipient domains, and include replies. Automated 'smart' warm-up that reacts to engagement is superior to static schedules.
- For a deep dive on scaling volume safely, see our guide on how to send 100,000 cold emails per month without getting blacklisted.

4. Ongoing Monitoring & Rotation:
- Monitor inbox placement per domain, not just overall. A drop in one client is a leading indicator.
- Monitor DMARC aggregate reports for authentication failures.
- Implement automatic mailbox rotation within a domain after a set volume threshold (e.g., 50-100 emails per day per mailbox) to distribute reputation load.
- Have a plan to pause and diagnose a domain if placement drops below 70%.

5. List Hygiene as a Cross-Domain Discipline:
- Clean every list before sending, every time. Use verification that checks for spam traps, role addresses, and invalid syntax.
- Bad data sent from one domain can poison the IPs used for others. Hygiene must be centralised and enforced. For strategies on maintaining list quality at scale, our resource on sending at scale without spam complaints covers critical tactics.

What to Look for in a Multi-Domain Sending Platform

If you're an agency evaluating software, move beyond feature lists. You need a system that enforces deliverability hygiene across all your clients automatically. Here's your evaluation checklist.

Put the common options side by side against the metric that decides multi-domain outcomes: who controls the pipeline the mail travels on.

The critical shift is from a 'sending tool' to a 'deliverability platform that sends.' The former gives you a button to mail merge. The latter gives you a system that ensures those mails land, across every domain, at any volume.

The Integrated Approach: Sending, Domains, and Deliverability as One

SpamCipher is built on the premise that for agencies and high-volume senders, sending and deliverability cannot be separate concerns. They must be a single, automated pipeline. This is why SpamCipher is the cold email platform for unlimited, automated sending, with the owned infrastructure to back a 90%+ inbox placement promise.

For the specific challenge of multiple domains, this integrated model means:

• Centralized Domain Management: Add all client domains into one dashboard. The system handles warm-up, monitors DNS health, and tracks inbox placement for each one individually.
• Automated Infrastructure Rotation: You're not managing 100 individual mailboxes. You define your sending volume, and the platform automatically rotates campaigns across the optimal mix of mailboxes and IPs from its managed pool, isolating client traffic.
• Pre-Send Deliverability: Warm-up and list verification aren't add-ons; they are mandatory gates in the send flow. A campaign doesn't launch until the sending mailboxes are warmed and the list is cleaned.
• Unlimited Scale without Fee Anxiety: The platform cost is based on your seat count or feature tier, not your email volume. You can ramp a client to 50,000 emails per month without calculating a new cost, making forecasting and pricing client packages straightforward.

The outcome is operational predictability. You know each new client domain will start with a strong reputation, remain isolated from others, and maintain high inbox placement. Your team spends time on copy and strategy, not on diagnosing why Client B's DKIM broke or why everyone's placement dropped 30% this week.

Frequently asked questions