Why separate sending domains — the reputation-contagion argument.

TL;DR

• Never send cold email from your primary domain — it’s the #1 cold-email rule. When reputation tanks, your founder@yourcompany.com emails start landing in spam too.
• Buy 5-10 lookalike .com domains (~$12 each): tryacme.com, getacme.com, acmehq.com. Three mailboxes per domain, max 20 sends per inbox per day.
• Sizing formula: (desired daily volume / 60) × 1.1 = number of domains. A 30-rep operation runs on 30-40 sending domains.
• Burned sending domain = $12 to replace. Burned corporate domain = 3-6 months of remediation with no support channel that helps.
• Use brand-adjacent names so recipients trust the From line. Never use the corporate brand verbatim with numeric suffixes.

The premise — domain reputation is shared across every sender on it

Gmail, Outlook, and Yahoo score reputation at three levels: per-IP, per-domain, and per-sender. The one that matters most for inbox placement — and the one most operators miss — is the domain-level score on your organizational domain (the registrable root).

That score at example.com is shared by every mailbox under it. ceo@example.com, billing@example.com, and sdr@example.comdon’t have separate scores. They have one score, updated by everyone’s combined behavior.

This is the entire argument. If you accept it, you stop asking whether cold outbound from the company domain is “safe enough” and start asking whether any cold volume is acceptable. The answer is no.

What happens when you cold-send from your real domain

The failure mode is predictable. You connect founder@yourcompany.comto a sequencing tool, load 800 prospects, and start sending. Week one: replies and a few unsubscribes. Week two: more unsubscribes, a handful of spam complaints (0.3 to 0.8% is typical on cold lists), and reply rate drops. Week three: messages that simply don’t arrive — sent folder shows them, no bounce, no recipient.

By week four your calendar invites are landing in prospect spam folders. By week six they’re landing in customer spam folders. By week eight invoices and password-reset emails — completely unrelated to cold sending — start failing. You usually find out when a customer asks why they never got their renewal notice.

Recovery is not a config change. It’s 90 to 180 days of clean behavior on Gmail, and there is no support channel that accelerates it. That’s the reputation contagion playing out in your real inbox.

Reputation contagion math

The contagion math follows from the fungibility property. Consider a corporate domain with five active senders: a founder, two account managers, a billing service, and a calendar invite flow. Add a sixth — a cold sequencing tool running 300 messages per day on a list with a 0.5% complaint rate. The cold sender contributes approximately 1.5 complaints per day; the transactional services contribute zero on tens of thousands of messages. The volume-weighted aggregate complaint rate at the domain level is still on the order of 0.005%, and an operator reasoning about “blended risk” concludes the addition is safe.

The conclusion is wrong because the major receivers do not weight by volume in the way the naive calculation assumes. The Gmail and Yahoo bulk-sender requirements, published February 2024, enforce a ceiling on the per-sender complaint rate, not the volume-weighted aggregate. Once a single sender on the domain crosses 0.3% sustained complaint rate, the receiver-side classifier begins applying domain-level penalties — not per-sender penalties — and the four innocent senders begin experiencing inbox-placement degradation that they did not cause and cannot remediate by changing their own behavior.

One bad campaign damages every sender on the organizational domain. There is no isolation primitive within the domain that prevents this. The only available isolation primitive is a separate organizational domain.

The per-domain inbox-count math

The number of domains is a function of three numbers: the per-mailbox sustainable sending volume, the per-domain mailbox count, and the total outbound volume the operation requires.

The per-mailbox sustainable volume on a warmed Google Workspace or Microsoft 365 mailbox, observed across hundreds of sending estates, is approximately 30 to 50 cold messages per day after the 6-to-8-week warmup ramp. The policy-layer cap is higher — Google Workspace permits 2,000 external recipients per day — but the deliverability cap from receiver-side classifiers is the binding constraint. Mailboxes that exceed 50 cold-context messages per day on a sustained basis are observably penalized at major receivers within four to six weeks.

The per-domain mailbox count is constrained by the receiver-side heuristic that a single domain producing high volume from a large number of mailboxes is statistically indistinguishable from a compromised domain. Two to three mailboxes per domain is operationally tolerated. Five begins to attract scrutiny. Ten mailboxes per domain producing cold-context traffic accelerates the domain’s reputation degradation independent of the message content.

For a 30-rep SDR operation: each rep needs roughly 80 to 120 sequenced messages per day, which against the 30-to-50-message ceiling requires two to three mailboxes per rep. At three mailboxes per rep and three mailboxes per domain, the operation needs one domain per rep — 30 domains. The number is robust to the exact parameter choices: a 30-rep operation runs on 30 to 40 sending domains.

The corresponding standing-infrastructure cost, at typical registrar renewal pricing of $12 to $15 per domain per year and mailbox costs of $6 to $12 per mailbox per month, is on the order of $1,200 to $2,800 per month all-in. The operator who attempts to reduce this by consolidating mailboxes onto fewer domains is reintroducing the contagion failure mode at smaller scale.

The lookalike-domain pattern as the operational primitive

The 30 sending domains are not random strings. They are brand-adjacent variants — the pattern conventionally rendered as try{brand}.com, use{brand}.com, get{brand}.com, {brand}hq.com, {brand}mail.com, and the corresponding .co and .net variants. The brand-adjacent name serves three operational purposes.

First, it produces a sender identity that a recipient finds plausible. A message from phillip@usebrand.com with a footer linking to brand.com reads as a legitimate outbound contact from the brand. A message from phillip@brand-outbound-sales-team.com reads as obvious cold outbound infrastructure and produces depressed reply rates independent of message content.

Second, it preserves brand-impersonation defense. A random cold-sending domain — random-string-42.com — does not benefit from the trademark association and provides no signal to recipients about the legitimate origin of the message. A brand-adjacent domain that the brand itself owns is, by construction, not a phishing attempt against the brand.

Third, the pattern allows the operation to retire and replace individual domains without a creative-brief decision each time. Domain 17 burns out at month nine; the replacement comes from the brand-adjacent naming list; the burned domain ages out. The pattern is durable across the inevitable individual-domain attrition.

TLS and brand-impersonation considerations

The brand-adjacent sending domain is, strictly speaking, indistinguishable at the SMTP-envelope level from a phishing domain targeting the same brand. The defensive posture that distinguishes the two is the authentication-record alignment: SPF authorizing the sending platform, DKIM signed with a key the brand controls, DMARC at p=reject from the day the domain enters production.

The cold-sending domain should run TLS — a valid certificate at the MX-pointed mail host, MTA-STS published, TLS-RPT configured (RFC 8460, RFC 8461). The cost is approximately zero; the alternative reads to receiver-side classifiers as infrastructure that has not been operationally maintained. The operator who omits it on cost-of-effort grounds is failing to extract a free reputational lift.

A brand-adjacent domain owned by the legitimate entity, with privacy-protected registration tied to the same registrant identity as the corporate domain, is the configuration that survives both the deliverability and impersonation-defense requirements simultaneously.

The recovery asymmetry — $12 vs months

If you only remember one thing from this chapter: a burned sending domain costs $12 to replace. New registration, new DNS, new mailbox, 6-to-8-week warmup ramp. Zero exposure to your real domain. You retire the burned one and the operation continues.

A burned corporate domain costs months. Stop all bulk sending entirely. Restore the one-to-one conversational baseline. Accumulate positive engagement at a rate Gmail accepts as evidence of intent change. During that window you run with degraded placement on transactional flows that have nothing to do with the original cold sending — missed renewal notices, failed 2FA codes, calendar invites lost to spam — and no vendor support shortens the timeline.

The replacement cost differs by three to four orders of magnitude. Once you see this, the sending-domain procurement stops looking like overhead and starts looking like the cheapest insurance in the entire stack.

The case against separate domains — where one domain suffices

The argument is not universal. A small population of senders run correctly on a single domain: senders whose outbound volume is low enough and whose recipient list is warm enough that the activity is not meaningfully distinguishable from one-to-one conversation. The empirical boundary is approximately 30 to 40 outbound messages per day from a single mailbox on a recipient list with prior relationship, prior consent, or warm referral.

An operator sending 10 personalized notes per day to handpicked recipients from a warm list — a founder running a fundraise from their personal mailbox, an account manager reaching out to existing customer contacts, a recruiter messaging candidates who opted into the pipeline — does not need separate sending domains. The activity, on receiver-side classifiers, looks like the conversational baseline the corporate domain already produces.

The threshold is a function of volume, list temperature, and complaint rate, not intent or content quality. Any operator above approximately 50 outbound messages per day on a list whose recipients did not directly request contact has crossed the threshold. The honest framing: if the operation has an SDR team, it needs separate sending domains; if the operation is a single founder doing handpicked outbound, it probably does not.

Cross-references — where this connects

Chapter 07 of the email cluster (subdomain architecture) extends this argument to whether a single sending domain can be partitioned into role-isolated subdomains — marketing, transactional, cold-outbound — to capture some of the isolation benefit without the per-domain registration cost. The answer is that subdomain partitioning provides some but not all of the isolation: organizational-domain reputation is shared across subdomains by default, and subdomain isolation is a complement to, not a substitute for, separate organizational domains.

Chapter 08 of the email cluster (domain age) extends this argument to when a freshly registered sending domain enters production. Domain age is itself a receiver-side reputation input — domains under 30 days old are explicitly penalized — and the procurement cadence must lead the operational ramp by approximately 60 days, with domains registered, DNS-configured, and resting before warmup begins.

Common operator failures observed in production

• Running the first sequence from the corporate mailbox “just to test.”The test is not reversible. The reputation impact of a 200-message cold sequence with a 0.5% complaint rate persists in receiver-side scoring for months, and there is no “undo” primitive available. The correct test is from a sending domain that the operator is willing to retire if the test reveals a problem.
• Buying 10 sending domains for a 30-rep operation. The per-domain mailbox count is then forced above the operationally tolerated three, and the per-mailbox volume is forced above the empirical 50-per-day ceiling. The operation reproduces the contagion failure mode within the sending estate itself, just at a slower rate than running on the corporate domain.
• Buying 30 sending domains under a single registrar account with sequential creation timestamps.The pattern is detectable from the registrar’s perspective and from the receiver’s perspective via passive DNS and WHOIS history. The receiver-side classifiers treat 30 domains registered within the same 24-hour window as a single sending entity for reputation purposes, partially defeating the isolation benefit. Chapter 04 details the cadence and registrant-entity decision that mitigates this.
• Using a naming pattern that is obviously algorithmic. Thirty domains named brand01.com through brand30.com are immediately identifiable as a cold sending estate and lose the brand-adjacent benefit. The pattern must be naturalistic enough to read as a legitimate brand-owned variant rather than as numbered sending infrastructure.
• Pointing the sending domains at the corporate DNS provider for operational convenience. The pattern matches across the 30 domains at the DNS-provider level and provides a fingerprint that some receivers correlate against. The dedicated-DNS decision is Chapter 05, but the rough rule is that the sending domains should not share DNS infrastructure with the corporate domain in any externally observable way.
• Renewing all 30 domains on the same date.The renewal-date clustering reproduces the pattern signal that the staggered registration was intended to suppress. Renewals should be staggered or, more conservatively, the registrar’s auto-renewal should run on the original registration cadence rather than a consolidated billing date.

Pre-procurement checklist

• The outbound volume requirement quantified — number of reps, target messages per rep per day, total daily volume
• The domain count derived from the volume requirement, conservatively rounded up (30-rep operation = 30 to 40 domains)
• The brand-adjacent naming pattern decided — the specific prefixes and suffixes that will generate the 30 candidate names
• The TLD mix decided — predominantly .com, with .co and .net as documented fallbacks (Chapter 02)
• The registrant entity decided — the legal entity the domains will be registered to, and the relationship of that entity to the corporate brand
• The registrar selection made, with the privacy posture and bulk-registration tooling evaluated (Chapter 03)
• The DNS hosting decision made, ahead of registration, so the nameserver assignment can be set at the moment of registration (Chapter 05)
• The mailbox provider selection made, with the per-mailbox cost and SMTP-versus-API integration decision settled (Chapter 06)
• A 60-day lead time established between the procurement and the start of warmup, so the domains can age before entering production (Chapter 08 of the email cluster)
• A retirement-and-replacement budget established — the operation should expect to replace 10 to 20% of the sending estate per year, and the procurement workflow should be reusable rather than one-time

Where this fits

This chapter is the foundation of the procurement stack. The remaining six chapters of this cluster build downstream from the conclusion that the operation requires 30 to 40 separate sending domains: Chapter 02 selects the specific names, Chapter 03 selects the registrar, Chapter 04 executes the buying workflow, Chapter 05 configures DNS, Chapter 06 selects the mailbox provider, and Chapter 07 provisions the mailboxes and hands the estate to the authentication-record configuration of the email-infrastructure reference.

The case for separate domains is, ultimately, an argument about which asset the operation is willing to put at risk. The corporate domain is the asset the business runs on. The sending domains are the assets the business sends from. Conflating the two is the most common error in the cold-sending stack, and it is the error that is most expensive to reverse once committed. The $12 per domain is the price of not making it.

Related chapters

• How to Choose a Cold Email Domain — selecting the names for the lookalike-domain estate.
• How to Buy 30 Cold Email Domains in One Session — the procurement workflow for the estate.
• Should I Use a Subdomain for Cold Email? — the subdomain-vs-separate-domain decision tree.
• How to Name Your Cold Email Inboxes — the per-mailbox naming decision once the domains are bought.