Cold Email Platform with Multiple Domains: The Agency Architecture

You are on client fourteen. Forty-one sending domains, 164 mailboxes, and a spreadsheet that tells you which ones are safe this week. Nothing broke at six domains. At forty, the failures go quiet: an ops person adds a helpdesk include to a client's SPF record, that record tips past ten DNS lookups, SPF starts returning PermError, and every message from that client now leans entirely on DKIM for alignment. You find out eleven days later when reply rate halves. Multi-domain cold email is a DNS, rotation, and reputation-accounting problem. The platform either carries it or hands it to you in pieces.

Where Multi-Domain Setups Actually Break

Three things break, in this order, and none of them announce themselves.

Per-mailbox pricing you never modeled. Warm-up is the line item that scales worst, because it is priced per mailbox and it never ends. You do not warm a mailbox once. You keep a floor of warm traffic under it for as long as it sends. MailReach lists $19.50 per mailbox per month [https://www.mailreach.co/pricing, 2026-07-27]. Warmup Inbox lists $15 per inbox per month on its Basic plan [https://www.warmupinbox.com/pricing, 2026-07-27]. Four mailboxes on each of forty domains is 160 mailboxes. At $19.50 that is $3,120 a month for warm-up alone, before a single prospect email leaves the building.

Unlimited accounts is not unlimited volume. Read the plan line, not the feature bullet. Instantly's Growth plan is listed at $47 per month with unlimited email accounts and 5,000 emails per month [https://instantly.ai/pricing, 2026-07-27]. Smartlead's Basic plan is listed at $39 per month for 6,000 sends per month, with unlimited email accounts at no extra cost [https://www.smartlead.ai/pricing, 2026-07-27]. Both are honest offers for a single team running its own outbound. Neither is the shape of an agency roster: the mailbox count is free, the sends are metered, and your forty domains all draw down one monthly pool.

Rotation that cannot see reputation. Round-robin gives every mailbox the same share regardless of whether it finished warm-up yesterday or has ninety clean days behind it. That spends your best assets to subsidise your worst, and it does so fastest exactly when you are onboarding, which is when new domains are most fragile.

SpamCipher is the cold email platform for unlimited, fully automated sending, built for agencies and growth teams running many client domains at once. That is the structural split against tools like Instantly and Smartlead: they sell a sending and sequencing layer that rides on top of whatever deliverability you assemble underneath, with a monthly send allotment attached to each plan. SpamCipher sends on a pipeline it owns end to end, so volume is not the metered unit, and every rotation decision is made with warm-up, verification, and placement data produced by the same system.

The point of the table is not that the other tools are bad at their job. It is that an agency at forty domains is buying three or four of them at once, each with its own unit of metering, and none of them can see what the others know.

The DNS Layout That Survives Forty Domains

This is the part most cold email guides skip, and it is the part that actually decides your placement floor. Every record below gets published forty times, so design it once and template it.

SPF: the ten lookup ceiling is what bites. An SPF evaluation may not trigger more than ten DNS-querying mechanisms, and blowing past it produces a PermError rather than a warning (RFC 7208, section 4.6.4). A PermError means the receiver treats SPF as failed, which means DMARC alignment now rests on DKIM alone. The trap is that an include costs whatever it resolves to, and providers rewrite those records without telling anyone. Some resolve to a single flat record of IP ranges and cost you one lookup. Others fan out into three or four nested includes and quietly cost you four. Never assume: run dig +short txt _spf.google.com, or the equivalent for whatever you are including, and count the nested include, a, mx, ptr, and exists mechanisms yourself. Recount every quarter, because a record that fit last quarter can tip over the limit without you touching it.

The multi-domain trap is copy and paste. Someone provisions mail.client.com and pastes the client's root SPF record onto it, and that root record already carries a CRM, a helpdesk, a payroll tool, and two ESPs. SPF has no inheritance. A subdomain gets its own record or nothing. Take the free win and publish a minimal record on the sending subdomain that authorizes only the mailbox provider you send through:

mail.client.com.   TXT   "v=spf1 include:_spf.google.com ~all"

Two opinions on this record. First, do not flatten includes into hardcoded IP ranges to dodge the ten lookup limit. Provider ranges change and a flattened record goes stale silently, which is a worse failure than the one you were fixing. If you are over the limit, remove senders, do not inline them. Second, ~all is fine. Enforcement belongs in DMARC. A hard -all mostly buys you broken forwarding.

DKIM: use one selector name across all forty domains. The selector is the label in front of _domainkey, so a Workspace key lives at google._domainkey.mail.client.com and Microsoft 365 uses selector1 and selector2. Where the provider lets you choose, on a relay or your own MTA, name selectors by rotation period rather than by client: sc2026q3._domainkey. Then a key rotation is one templated change scripted across forty zones instead of forty different selector names tracked in a spreadsheet. Publish the new key, start signing with it, leave the old public key in DNS for at least a week so mail already in flight still verifies, then remove it.

One mechanical detail costs people whole days. A DNS TXT record is a sequence of character-strings and each string caps at 255 bytes (RFC 1035, section 3.3), so a 2048-bit key has to be published as multiple quoted strings that the resolver concatenates (RFC 6376, section 3.6.2.2). Some registrar control panels truncate instead of splitting. Verify every domain with dig +short txt google._domainkey.mail.client.com and confirm the p= value ends exactly where your provider says it should, not one character short.

DMARC: ramp it, and publish the two records everyone forgets. Check the client's root domain before you touch anything. A policy on the organizational domain applies to its subdomains unless an sp tag says otherwise (RFC 7489, section 6.3), so a client already at p=reject puts your brand new sending subdomain under reject on day one, before you have confirmed a single alignment. Publish an explicit record on the sending subdomain so its ramp is yours to control:

_dmarc.mail.client.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@agency.com; fo=1"

Then walk it. Two weeks at p=none while you read aggregate reports and confirm that both SPF and DKIM align on your own traffic. Move to p=quarantine with pct=25, then to full quarantine, then to p=reject once a full reporting cycle shows no legitimate source failing. The pct tag is a ramp aid, not a destination, and later revisions of the DMARC spec move away from it, so do not leave a client parked at quarantine forever and call it done.

The forgotten record is external reporting authorization. If rua points at a mailbox on a domain you own, and the reports concern a client domain, the destination domain has to publish permission for it (RFC 7489, section 7.1):

client.com._report._dmarc.agency.com.   TXT   "v=DMARC1"

Miss that and conformant reporters simply do not send you reports. Silence reads exactly like a clean bill of health, so you promote the domain to reject on the strength of data you never received.

Tracking domain and reply path. Give every client its own click and open host, track.client.com as a CNAME to your platform, never one shared click domain across the roster. Link reputation travels, and a shared tracking host means one client's bad week is priced into everyone's. If mailboxes live on the subdomain, make sure replies have somewhere to land: add the sending subdomain to the mailbox provider as its own domain rather than assuming the root MX covers it.

One last thing worth knowing before you split volume across forty domains in order to stay small. Google's sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to authenticate with SPF, DKIM, and DMARC, keep the spam rate reported in Postmaster Tools below 0.30%, and support one-click unsubscribe on marketing and subscribed mail [https://support.google.com/a/answer/81126, 2026-08-06]. Splitting volume lowers the per-domain number. It does not buy an exemption from doing authentication properly, and it does far less than people assume when the split is across subdomains of one root: they share an organizational domain, and by default they share its DMARC policy too (RFC 7489, section 6.3). The authentication side of this is covered in more depth in Cold Email Deliverability: The 2026 Authentication Reality.

Reputation-Weighted Rotation, Not Round-Robin

Rotation sounds like a solved problem: spread sends so no mailbox carries too much. The allocation rule is where it goes wrong.

Round-robin allocates by count. Mailbox A sends fifty, Mailbox B sends fifty, whether B finished warm-up yesterday or has been clean for four months. Reputation-weighted allocation reads each mailbox's recent placement, seed engagement, bounce rate, and warm-up maturity, then distributes proportionally. A mailbox in week two of warm-up takes single-digit percent of volume. A mailbox with a long clean history takes a large share and can absorb it.

The control most platforms expose is the wrong one. Per-mailbox daily caps are easy to build and easy to sell, but the unit that matters is volume per domain per provider per day. Four mailboxes on one domain each sending a modest 50 to Gmail is 200 messages from that domain to that provider, and the receiver scores the domain, not your dashboard's row.

SpamCipher is the cold email platform for unlimited, fully automated sending, and rotation across unlimited domains is the mechanism that makes the volume usable. Warm-up, verification, placement testing, and sending all run on one owned pipeline, so mailbox status is a fact the system already holds rather than something it polls from a third-party API on a delay. Add a client domain on Monday, and it enters rotation at the appropriate share by mid-week without you configuring a separate warm-up subscription or a rotation group. The warm-up mechanics behind that are covered in Cold Email Warmup for Multiple Domains: The Agency Guide.

Worked Example: 8 Domains, 32 Mailboxes, 30,000 Sends

One client needs 30,000 cold emails a month. You provision eight domains with four mailboxes each, so 32 sending identities. Here is the arithmetic that should drive the plan.

Thirty thousand sends across roughly 21 working days is about 1,430 a day. Split across 32 mailboxes, that is 45 emails per mailbox per day. Not 200. Most burned domains are burned chasing a per-mailbox number nobody actually required, because the operator sized the mailbox rather than the campaign.

Week one. All 32 mailboxes warm only, no prospect traffic. DNS is published and verified on all eight domains before the first warm-up message: SPF under the lookup limit, DKIM key confirmed by dig, DMARC at p=none with reporting authorized.

Week two. Graduated mailboxes take prospect volume at 15 to 20 a day while warm-up traffic continues underneath. Domains that finished warm-up cleanest carry the larger share. Nothing is paused if one lags, its share is simply smaller.

Week three onward. Ramp toward the 45 per mailbox target, increasing by roughly 20% a week while placement holds. If a mailbox on domain three shows Gmail spam placement, its share moves to healthier mailboxes automatically. Campaign volume is unchanged. Nobody re-uploads a list.

Now price the fragmented version of the same 32 mailboxes. Warm-up at MailReach's listed $19.50 per mailbox per month [https://www.mailreach.co/pricing, 2026-07-27] is 32 times $19.50, or $624 a month. Verifying 30,000 addresses at NeverBounce's listed $8 per 1,000 [https://www.neverbounce.com/pricing, 2026-07-27] is $240 a month. Placement testing on GlockApps starts at $59 a month for the lowest paid tier [https://glockapps.com/pricing/, 2026-07-27]. That is $923 a month before a single sending seat, and the sending seat still has a plan cap on it: Instantly's Growth allotment of 5,000 emails a month covers one sixth of this campaign [https://instantly.ai/pricing, 2026-07-27], and Lemlist's Email plan lists 50,000 emails a month at $55 per user per month billed annually [https://lemlist.com/pricing, 2026-07-27], which covers the volume but is priced by seat and warms on someone else's pool.

Three vendors, three dashboards, three notions of what "healthy" means, and a spreadsheet in the middle doing the join by hand. When domain three degrades on a Monday, the warm-up tool does not know, the verification tool does not care, and you find out Tuesday afternoon when the client forwards a bounce report.

The Failure Modes Nobody Writes Down

These are the ones that survive a good setup and still cost you a client.

• Fingerprint clustering. Forty domains bought in the same hour, at the same registrar, on the same nameservers, with the same MX and the same one-page site from the same template, is not diversification. It is one asset with forty labels. Stagger registration, vary registrars and DNS hosts, and give each domain a real site before it sends.
• Synchronised send windows. Thirty-two mailboxes all firing at 09:00 in the same time zone from the same egress range is a pattern a filter can see even when every individual mailbox looks reasonable. Jitter start times and randomize inter-send gaps.
• Forwarding breaks alignment. A prospect auto-forwards your message to a colleague, the forwarder rewrites headers, SPF no longer matches, and only DKIM keeps you aligned. This is why a broken DKIM key on one domain can look like a general placement problem: you lost your only surviving alignment path.
• Catch-all client domains. Verification returns "valid" for every address at a catch-all domain, so a bad list looks clean until bounces arrive as silent drops instead of SMTP rejections. Treat catch-all results as their own risk tier and cap their share of any send.
• Domain expiry on autopilot. A domain with ninety days of clean reputation and auto-renew switched off is a scheduled outage. Audit renewal state on the whole portfolio quarterly, alongside DNS.

Bring Your Own Infrastructure vs. Done-For-You

The second architectural call is who owns the sending infrastructure.

A platform that puts you on its shared IPs and mail servers makes setup fast and concentrates your risk. When that range is flagged, every tenant on it is affected at once, and you cannot move quickly because your domains are authenticated against infrastructure you do not control.

A pure software layer inverts the problem. You bring Google Workspace, Microsoft 365, or SMTP relays, you keep control, and you also inherit forty billing relationships, forty admin consoles, and authentication mismatches to debug one client at a time.

SpamCipher supports both because agency needs differ by client. Connect infrastructure you already own and let the platform run rotation, warm-up, and deliverability across it. Or use the done-for-you path, where SpamCipher provisions, authenticates, warms, monitors, and maintains the stack, and you add domains in the dashboard. The done-for-you model earns its keep on exactly the work described above: per-client tracking hosts, subdomain separation, DMARC progression from none to reject, and key rotation on a schedule, applied consistently across every domain instead of whenever someone remembers.

Verification and Monitoring Across Forty Domains

List quality is a reputation input, and multiple domains multiply it. A 5% bounce rate on 1,430 sends a day is roughly 72 bounces daily, spread across the exact domains you spent three weeks warming. Verify at send time, not at upload time, and re-verify any segment older than about thirty days. The gap between an upload-time check and an actual send is where stale data gets through.

SpamCipher is the cold email platform for unlimited, fully automated sending, and verification sits inside that send flow rather than beside it: SMTP-level checks, catch-all detection, and role-account filtering run before the message leaves, on the same pipeline that owns warm-up and placement. The practical effect is that a client's optimistically labelled "clean" list gets caught before it damages eight domains.

On monitoring, the wrong pattern is forty dashboards checked by hand. Watch four aggregated signals with per-domain drill-down:

• Placement by provider. Gmail, Outlook, Yahoo, and corporate filters diverge. A single blended deliverability score hides the one provider that is failing.
• DMARC aggregate reports. Alignment failures show up here well before they show up in bounce rates, and they name the source that is failing.
• Blacklist status. Spamhaus, URIBL, Barracuda, and provider-specific lists, checked per domain and per tracking host.
• Reply and engagement velocity. The leading indicator. Placement has usually already moved by the time bounce rates do.

Alerts should arrive with enough context to act without opening a tab: which domain, which provider, which signal moved, what the system already did about it. Because monitoring lives on the same pipeline as sending, a degrading domain gets throttled while you are still reading the alert.

The Setup Checklist, In Order

Whatever platform you use, run a new client through this sequence. It is ordered so that each step's failure is caught before the next step depends on it.

1. Read the client's root DNS first. Existing DMARC policy, existing SPF senders, existing DKIM selectors. A root at p=reject changes your plan.
2. Publish the sending subdomain records. Minimal SPF, provider DKIM, DMARC at p=none with rua and fo=1, plus the external reporting authorization record on your own domain.
3. Verify with dig, not with the panel. dig +short txt mail.client.com, dig +short txt selector._domainkey.mail.client.com, dig +short txt _dmarc.mail.client.com. Confirm the DKIM key is not truncated.
4. Point a per-client tracking host at your platform. Never share one across clients.
5. Warm for fourteen days minimum, thirty preferred. Do not compress this because the client is impatient. Recovery from a burned domain is measured in months, when it works at all.
6. Size the ramp from the campaign, not the mailbox. Monthly target divided by working days divided by mailboxes gives your per-mailbox daily number. Grow it about 20% a week while placement holds.
7. Switch rotation to reputation-weighted. If the platform only offers round-robin, you are managing by hand what should be automatic.
8. Read DMARC aggregate reports for two weeks before advancing policy. Then quarantine at pct=25, then full quarantine, then reject.
9. Set a hard bounce threshold of 2% as an automatic campaign pause, per domain, not per account.

The economics of running this at roster scale are worked through in Unlimited Sending Accounts: The Cold Email Platform Reality for Agencies.

Why the Owned Pipeline Is the Only Model That Scales

The market splits into two philosophies. One treats deliverability as a shopping list: warm-up from one vendor, verification from another, placement data from an API, sending through a fourth. You assemble it and hope the pieces agree.

The other treats deliverability as infrastructure you own, with warm-up, verification, placement testing, authentication monitoring, and sending on one pipeline sharing one set of facts.

For a multi-domain agency the difference is arithmetic before it is philosophy. The assembled stack multiplies with every domain: more warm-up mailboxes, more verification credits, more monitoring seats, more reconciliation. The owned pipeline amortizes the same infrastructure across your whole volume, which is why unlimited sending is a coherent offer rather than a marketing word.

The coordination gap matters more. In an assembled stack, the system that detects a placement drop has no authority over the system that controls send volume, so the fix is a human noticing a dashboard and editing a campaign. On an owned pipeline, detection and throttle are the same system, and the response happens in minutes without a ticket.

SpamCipher is the cold email platform for unlimited, fully automated sending, built for agencies and growth teams at high volume, and it starts free. The 90%+ inbox placement promise is a claim the architecture makes possible: every variable that decides placement lives inside one pipeline rather than across four vendors' roadmaps.

Frequently asked questions