Domain separation for cold email teams

Why domain separation is non-negotiable for cold

The reputation model that inbox providers have built over the past fifteen years treats each sending domain as a distinct entity, and it treats the behavior at that domain as the primary signal for filtering decisions. A domain that sends welcome emails, password resets and invoices to existing customers has a specific behavioral profile: low complaint rate, high engagement, steady volume, recipients who explicitly opted in. A domain that sends unsolicited outreach has a completely different profile: higher complaint rate, lower engagement, bursty volume, recipients who never asked to hear from you. Trying to build a single domain's reputation around both profiles produces the worst of both worlds. The underlying mechanics of how inbox providers score sender reputation in the first place are worth a separate read in sender reputation fundamentals.

The math is not subtle. If your corporate mail complaint rate is 0.05% and your cold complaint rate is 0.4%, combining them means the blended rate sits at the higher end — well into the range where Gmail and Microsoft start applying filtering pressure. Your invoices, which would have been comfortably in the inbox on a clean corporate domain, now share the filtering treatment your cold campaign earned. The cold campaign, meanwhile, drags down an IP and domain reputation that the rest of the business depends on.

This is not a theoretical concern. It is the most reliable way to predict which organizations will have a deliverability crisis in the next year: look for the ones sending cold mail from their primary domain. It happens every time. The only variable is how quickly someone notices and how expensive the recovery becomes.

The four boundaries a serious program keeps separate

Domain separation is not a single decision. It is a set of four interlocking boundaries, each solving a different problem. A program that gets three right and misses one still ends up with contamination; the boundaries have to be complete.

Notice that none of these is about the technology of sending. The underlying ESP, the specific SMTP relay, the tooling layer — none of that appears in the table. Separation is an architectural concern that sits above the technology choice. A team using Lemlist or Smartlead can get separation right or wrong. A team using PowerMTA or a raw SMTP relay can get separation right or wrong. The choice of tool does not determine the quality of the separation; the discipline does.

Primary vs outreach domains: the core pattern

The first and most important boundary is between your primary corporate domain and the domains you use for outreach. This is the one that, if you get it wrong, no other decision can rescue.

The naming convention that works

Outreach domains should be related to your primary brand but clearly separate. Two patterns dominate in 2021, both functional:

The recommended default for most programs is the branded variant. Domains like getacmewidgets.com or acmewidgetshq.com are cheap to register, trivially recognizable as you when a prospect googles the brand, and don't carry the trust penalty of hyphens or unusual TLDs. They also let you register three or four variants for a trivial annual cost and build out a proper multi-domain program.

Domains to avoid entirely

• Unrelated domains — if prospects cannot connect the domain back to your company, every message looks more like spam. Names that don't reference your brand in any way undermine credibility.
• Very new TLDs with outbound-only reputation — TLDs with a heavy cold email presence get scored more aggressively by some filters. Research involving tens of millions of cold emails has shown that .biz and a few others underperform noticeably compared to .com and country-specific options.
• Hyphens plus numbers — acme-widgets-2.com reads like a disposable outreach domain, because it is a disposable outreach domain. Filters have been trained on exactly this pattern.

How many outreach domains do you actually need

The right number of outreach domains is a function of volume and risk tolerance. Too few concentrates your entire program on surfaces that can be individually blocked. Too many creates operational overhead that outweighs the risk benefit.

The underlying logic is the daily cap per mailbox. Practical industry consensus in 2021 is that a cold mailbox can sustainably send forty to fifty emails per day without triggering filtering pressure. That number drifted down over the preceding few years — it was closer to a hundred in 2017 — and it will probably drift down again as filters keep tightening. If you want to send three thousand cold emails per day reliably, you need at least sixty to seventy-five active mailboxes, and those mailboxes have to be distributed across several domains for reputation spreading.

A typical mid-market cold operation running around 30k/month looks like this: four outreach domains, each with three to four mailboxes, each mailbox capped at forty-five daily sends, with a 15-20% of that volume reserved for warmup activity rather than outreach. That is roughly fifteen mailboxes spread across four domains, delivering around 700-900 outreach emails a day sustainably. The volume-expectation framing is covered in more depth in cold email warmup expectations for serious outbound programs, which walks through the realistic ramp curve rather than the marketing-tool ramp curve.

The mailbox layer: inboxes per domain

Within each outreach domain, the mailbox structure affects both capacity and credibility. A domain with one mailbox is a solo sender; a domain with six mailboxes is a team. Recipients who pay attention to sender patterns can often detect the difference, and it influences trust.

A sensible mailbox pattern per outreach domain

1. Two to four mailboxes per domain. Below two, you're not using the domain's capacity efficiently. Above four or five, the pattern starts looking like an outreach-only domain that doesn't actually have a human team behind it.
2. Real-sounding names. john.martinez@getacmewidgets.com reads as a person; sales1@getacmewidgets.com reads as a system. When possible, use actual names of people on the sales team, with their consent and clear internal documentation about which name maps to which mailbox.
3. Profile pictures and signatures. A mailbox with a profile picture, proper signature, and reasonable metadata reads as more legitimate than a bare mailbox with no visual identity. The effort is small; the return on credibility is real.
4. Consistent sending hours. A mailbox that sends at 3 AM local time to the recipient looks suspicious. Spread sends across reasonable business hours in the recipient's timezone, not the sender's convenience.
5. Genuine reply handling. Replies to cold email should reach a human who responds, not a black hole. This is partly conversion hygiene and partly a reputation signal; inbox providers do observe reply rates.

Where the mailboxes physically live

The decision about which mail host to use for outreach mailboxes is less architecturally important than it sounds, but it does have practical implications. The two common patterns in 2021:

• Google Workspace or Microsoft 365 mailboxes. Familiar to the team, easy to set up, strong inbound reputation. The main friction is that these hosts rate-limit outbound sending fairly aggressively, and they will suspend accounts that exceed their terms of service around bulk cold mail.
• Dedicated outbound infrastructure with custom mailboxes. Mailboxes hosted on a provider specifically built for outbound campaigns. More permissive on volume, usually integrates directly with cold email tooling, but you lose the inbound reputation that Workspace and 365 bring.

A common hybrid pattern: use Workspace or 365 for the mailboxes themselves (for inbound reputation and familiar UX) while routing outbound through a separate sending infrastructure (for throughput and deliverability tuning). This is more complex to set up but combines the strengths of both.

DNS setup per outreach domain

Every outreach domain needs its own complete authentication record set. Shortcutting this with "we'll add DKIM later" is how cold programs start filtering into spam within the first hundred sends. The setup below is the minimum for any outreach domain going live in 2021.

DNS — per outreach domain# SPF: authorize the sending infrastructure
getacmewidgets.com.  IN  TXT  "v=spf1 include:spf.yourmailhost.com ~all"

# DKIM: sign outbound mail with a key under the outreach domain
google._domainkey.getacmewidgets.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
# Or for infrastructure providers that use CNAMEs:
s1._domainkey.getacmewidgets.com.  IN  CNAME  s1.dkim.providermta.com.

# DMARC: start at p=none during warmup, tighten once everything is aligned
_dmarc.getacmewidgets.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@acmewidgets.com; fo=1"

# MX: route incoming replies to the mailbox provider
getacmewidgets.com.  IN  MX  1 aspmx.l.google.com.
getacmewidgets.com.  IN  MX  5 alt1.aspmx.l.google.com.

# A record for the root domain (for web redirect - covered in a later section)
getacmewidgets.com.  IN  A   203.0.113.50

# PTR / reverse DNS alignment happens at the IP level, not the domain zone,
# but should be coordinated with your sending infrastructure provider.

Two details to get right per domain. First, the SPF include has to match whatever infrastructure actually sends the mail; an SPF that authorizes Google Workspace for a domain sent through a third-party ESP fails alignment and produces DMARC failures. Second, the DMARC rua address should route reports to an inbox you actually monitor, not admin@ that nobody reads. Cold programs benefit significantly from reading their DMARC reports; they surface alignment failures that would otherwise be invisible. For the deeper treatment of how multi-domain senders coordinate SPF, DKIM and DMARC across several domains — which is exactly what a cold program with four or five outreach domains has to manage — see authentication alignment and policy review for multi-domain senders.

Domain warmup: the discipline nobody enjoys

A fresh outreach domain has no sending history. To an inbox provider, it is an unknown entity, and unknown entities start filtering pretty aggressively until they prove themselves. Warmup is the process of establishing that proof by sending gradually increasing volumes of mail that looks like legitimate traffic — mail that gets opened, replied to, and engaged with — before any cold campaign starts.

A reasonable domain warmup trajectory

Two things that often surprise teams new to this pattern. First, the warmup never fully ends. A well-run program keeps fifteen to twenty percent of each mailbox's volume dedicated to warmup activity indefinitely, because that maintenance traffic is what keeps the mailbox's reputation healthy through the inevitable quiet periods and content changes. Second, the warmup trajectory above is the shortest sensible path; many programs add another two to three weeks for safety, and the results reliably justify the extra patience.

The mechanics of running warmup are usually handled by tooling. Services like Instantly, Lemlist's warmup feature, MailReach, Warmup Inbox, and Smartlead's built-in warmup all work the same way: they add your mailbox to a network of other mailboxes that exchange real-looking messages with each other, rate-adjusted to match your desired volume trajectory. The signals these messages generate — opens, replies, positive engagement — are what builds the mailbox's reputation.

The Apple iOS 15 shift and what it changes

Apple launched iOS 15 this month, and with it Mail Privacy Protection, which changes how the Apple Mail client handles open tracking. The short version: Apple now pre-fetches images for Mail users with MPP enabled, which means the tracking pixel fires even if the recipient never actually opens the message. For cold email programs, this has concrete implications.

The practical response is not to panic about the open signal. Sensible cold programs were already weighting replies more heavily than opens, because replies correlate directly with business outcomes and opens are a proxy at best. MPP accelerates a transition that should have been happening anyway.

For measuring inbox placement — which actually matters operationally, and which open rates were partly proxying — the correct tools are seed lists. A seed list is a curated set of mailboxes across different providers (Gmail, Outlook, Yahoo, corporate Exchange environments) that you send test campaigns to, then observe where those test messages land: inbox, promotions tab, spam folder. Tools like GlockApps, MailReach, and Inbox Monster run this as a product. The seed list approach does not depend on open tracking and is unaffected by MPP.

Redirects, branding and recipient trust

An outreach domain that does not resolve to anything when a prospect visits it is a red flag. Even a prospect who is not explicitly checking will see browser behavior that reads as suspicious. The fix is trivial and should be part of every outreach domain setup: redirect the root of the outreach domain to your primary corporate site.

redirect — per outreach domain# At your DNS or via a simple web server:
getacmewidgets.com     → 301 redirect → https://acmewidgets.com
www.getacmewidgets.com → 301 redirect → https://acmewidgets.com

# Keep the redirect intentional:
#   - Use 301 (permanent) not 302 (temporary)
#   - Preserve HTTPS; don't downgrade to HTTP
#   - Match the canonical version of the target (www vs non-www)

The redirect does three useful things. First, it makes the outreach domain look legitimate when inspected; a prospect who googles the domain lands on your real brand. Second, it establishes a relationship between the outreach domain and the primary domain that filters can observe over time. Third, it means that when a prospect clicks a link in a cold email, they end up at your actual site, which is where you want them regardless.

A small detail that matters: the DNS for the outreach domain should include a proper A record at the apex, even if that A record just points to a lightweight redirect service. Domains that have no A record at all read as dormant or unregistered, which is a negative trust signal. The cheapest implementation is a static site on any hosting platform that serves a 301 to your primary domain; dozens of free options exist.

Tracking domains as a separate concern

Open and click tracking requires a tracking domain — the host that serves the tracking pixel and handles link redirection. By default, most cold email tools use a shared tracking domain owned by the vendor: Lemlist's tracking domain is one host, Instantly's is another, Smartlead's is a third. If you send from your outreach domain but track from a vendor's shared tracking host, you are creating exactly the kind of mixed-ownership signal that filters penalize.

The fix is a custom tracking domain — a subdomain of your outreach domain that serves the tracking function exclusively. Setup is straightforward; every serious cold email tool supports it.

DNS — custom tracking subdomain# CNAME the tracking subdomain to the infrastructure provider
t.getacmewidgets.com.  IN  CNAME  custom-tracking.yourmailtool.com.

# Once the CNAME propagates, configure the cold email tool to use
# t.getacmewidgets.com as the tracking domain for this outreach domain.
# The tool will generate links like:
#   https://t.getacmewidgets.com/open/abc123
#   https://t.getacmewidgets.com/click/def456

Three reasons this separation matters. First, a shared tracking domain has been used by thousands of senders, some of them bad actors, and its reputation reflects that; a domain-scoped tracking subdomain inherits your reputation, not someone else's. Second, custom tracking domains prevent the "all cold email from this vendor uses the same tracking host" filter rule that receivers sometimes build. Third, a tracking subdomain under your outreach domain reads as coordinated and professional; a vendor's tracking host reads as outsourced.

When separation fails in practice

Separation is a design discipline, and like all design disciplines, it fails when the underlying pressure gets high enough. The failure modes are predictable and worth naming explicitly so teams can watch for them.

1. Sales team "just sends one" from corporate. Somebody forgets the discipline and sends a prospecting email from their primary corporate account. Filters correlate the corporate domain with outreach behavior; the effect is small per occurrence but compounds quickly. Fix: lock corporate accounts out of cold email tooling entirely.
2. Newsletter mixed onto cold infrastructure. Marketing starts sending newsletters from an outreach domain because "it's already set up." The newsletter's engagement pattern differs from cold; the mixing degrades both. Fix: newsletters belong on their own distinct sending path, separate from cold domains.
3. Outbound reputation bleeds via replies. Replies from cold outreach route to a corporate inbox, and autoresponders or shared mailbox rules copy them into the corporate thread. This creates visible corporate-domain traffic to the cold recipient, which muddies the separation. Fix: keep reply handling on the outreach domain's inboxes; forward to a human as needed but not through automation that reveals the corporate domain.
4. Contact forms and webhooks on outreach domains. Prospects who reply through a contact form on the redirected outreach site send mail into the primary domain. Fix: contact forms belong on the primary site only, accessible via the redirect target.
5. Shared SPF include that authorizes the primary domain's hosts. Some teams add the cold tool's SPF include to their primary domain "just in case" and leave it there after cold moves off. The cold tool's historical traffic pattern lingers on the primary domain's SPF. Fix: audit SPF records quarterly; remove includes for any sending source that no longer sends from that domain.
6. Warmup tools authorized on outreach domains after warmup is done. The warmup service's include stays in SPF after the warmup phase ends. Marginal issue, but worth cleaning up as part of hygiene. Fix: audit and remove unnecessary includes.

Frequently asked questions

Can we just use a subdomain instead of a separate domain?

Technically yes, and some programs do. Subdomains inherit the parent domain's reputation in some respects, which cuts both ways: the subdomain benefits from the parent's clean reputation initially, but bad behavior on the subdomain can still affect the parent domain. For serious cold programs, fully separate domains are the safer default. Subdomains work for small-volume testing or for organizations that cannot register additional domains for administrative reasons.

How long should we warm up before real outreach?

Four to six weeks is the standard range. Programs that rush this and go to full volume after two weeks consistently underperform programs that wait. The time cost is real; the deliverability benefit is larger.

What if our current cold campaign has already damaged our primary domain?

Move the cold workload off immediately to outreach domains. Let the primary domain rest — no cold mail for ninety days minimum. Meanwhile, keep corporate transactional traffic flowing normally. Reputation recovery on a primary domain is slow but measurable; after three to six months of clean sending, the primary domain typically returns to baseline.

Should we use dedicated IPs for cold email?

At sustained volumes above roughly 100k cold emails per month, yes. Below that, shared infrastructure with solid separation at the domain level is usually sufficient. The volume threshold for dedicated IPs in cold is similar to the volume threshold for dedicated IPs in other workloads; the underlying framework is covered in how to choose between dedicated infrastructure and shared sending layers.

How do we handle replies at scale?

Route replies from each outreach mailbox to a unified reply-handling queue that a human monitors. Most cold email tools have this built in. The key is that replies get seen by a human and get real responses; autoresponders for cold email are a negative trust signal.

What if a prospect unsubscribes from one of our outreach domains?

Suppress them globally across all domains in your program, not just the one they unsubscribed from. A prospect who says "no" on one domain should not get another prospecting email from a sibling domain the next week; that pattern is how cold programs earn complaint-rate problems.

Is it okay to reuse outreach domains for multiple campaigns?

Yes, provided the campaigns share a coherent sending profile — similar audience, similar volume, similar content type. Rotating fundamentally different campaigns through the same domain creates inconsistent reputation signals.

Closing perspective

The organizations that run successful cold email programs in 2021 share a specific set of habits. They treat cold as a workload category in its own right, with its own infrastructure and its own reputation boundary. They register multiple outreach domains, run sensible numbers of mailboxes per domain, and resist the pressure to push individual mailboxes past their sustainable capacity. They warm domains patiently and keep maintenance warmup running indefinitely. They respond to the iOS 15 shift by weighting replies over opens rather than chasing metrics that are becoming less meaningful. And they treat domain separation as a discipline that gets protected through quarterly audits rather than as a setup decision that gets made once and then drifts.

The organizations that struggle tend to share a different set of habits. They start cold outreach on the primary domain because it was expedient. They discover the problem after corporate mail starts going to spam. They move the cold operation to outreach domains as a remediation rather than as a design choice, which works but leaves a tail of residual reputation damage on the primary. They either under-invest in mailbox count (pushing existing mailboxes past their sustainable limit) or over-invest (registering more domains than they can operate well). They treat warmup as a delay rather than as a product, and they skip tracking-domain separation because it seemed like a detail.

The difference between the two groups is not technical sophistication; it is architectural discipline. The actual tooling question — which cold email product to use, which mailbox host, which sending infrastructure — is secondary to getting the separation boundaries right. A program with clean separation can use almost any competent tooling and succeed. A program with muddy separation will struggle no matter how polished the vendor stack is. The work to do first is the boundary design. Everything else follows.

For teams starting out or rebuilding after a deliverability crisis, the path is clear: register a small cluster of outreach domains, set up proper DNS per domain, establish a mailbox pattern that respects per-mailbox limits, run a full warmup cycle before sending any real outreach, and build operational habits that protect the separation over time. None of this is fast or glamorous work. All of it is the difference between a cold program that produces reliable pipeline and one that produces deliverability fires.