Separate your mail streams

Reputation attaches to the identity that sends, and if every kind of mail you send shares one identity, they all share one reputation. That's the entire argument for stream separation in a sentence: your password resets should not pay for your promotions' sins. The tool for separating identities is the subdomain, and doing it well is one of the few pieces of deliverability architecture you decide once and benefit from for years.

The three temperatures of mail

Most organizations send three broadly different kinds of mail, and it helps to think of them by temperature.

Transactional mail is the hottest: receipts, password resets, shipping notices, invoices. The recipient caused each message and is often actively waiting for it. Engagement is near-perfect and complaints are near-zero. A transactional message landing in spam is a genuine business failure (a user who can't reset a password is a user locked out).

Marketing mail is warm: the newsletter, the product announcement, the seasonal promotion, the launch email. Recipients opted in, but nobody is refreshing their inbox waiting for it. Engagement is decent on a well-run list, and some complaints are a fact of life even when you do everything right.

Then there's everything colder: re-engagement pushes to dormant segments, event blasts, partner mailings, and at the far end cold outreach to people with no relationship to you at all. This mail earns the worst engagement and the most complaints by its nature, however well it's executed.

The temperatures don't mix. That's the problem.

How one stream's sins land on the others

Recall from the sender reputation lesson where reputation lives: on the sending domain (the identity your authentication proves) and on the sending IP. Filters keep ledgers per identity. If your receipts and your re-engagement blasts both authenticate as yourbrand.com and leave through the same infrastructure, the ledger is shared, and every entry lands in the same account.

Now run the scenario. Marketing mails a segment that sat dormant for a year. Complaints spike for a week. The filter's ledger for yourbrand.com takes the damage, and the next password reset consults the same ledger. Nothing about the transactional mail changed, and its placement got worse anyway, because the identity it shares with marketing got cheaper. The coldest stream you run sets the price for the hottest one.

Separation reverses this. Give each stream its own sending identity and the ledgers split. A bad month for marketing stays a bad month for marketing.

The subdomain strategy

The standard pattern is one subdomain per stream, named plainly: mail.yourbrand.com for transactional, news.yourbrand.com for the newsletter, send.yourbrand.com or similar for other bulk streams. The names themselves carry no magic; filters don't reward news. for honesty. What matters is that each subdomain is a distinct authenticated identity, with its own DKIM keys signing with its own d= domain and its own SPF record. Each identity builds its own track record with every receiver.

This is also how ESPs already want to set you up. Klaviyo, to take a documented example, commonly configures its branded sending domain on a subdomain like send.yourbrand.com rather than the apex. When you configure a second tool, giving it its own subdomain rather than wedging it into the root domain's records also sidesteps a whole class of rot: the root's SPF record collecting an include per tool until it blows through the 10-lookup limit.

One honest caveat, because I promised honesty over tidiness: separation by subdomain is a firewall with known gaps. Subdomains are visibly related to their parent, and some receivers factor the organizational domain's overall standing into their judgment of any subdomain. Google's Postmaster Tools will show you reputation per authenticated domain, but nobody outside the filter teams knows exactly how much rollup happens across a domain family. Treat subdomain separation as containment that works well in practice, verified constantly at scale by every major ESP's architecture. Don't treat it as an airtight wall that makes the streams strangers.

DMARC has to cover the family

Separation multiplies the identities you're responsible for, and DMARC is where sloppy multiplication shows up.

The mechanics: a DMARC record at _dmarc.yourbrand.com covers subdomains by default. The sp= tag can set a different policy for subdomains than for the root, and any subdomain can publish its own record at _dmarc.news.yourbrand.com, which then takes precedence for mail claiming to be that subdomain. So far so good; the defaults are sane.

The failures are practical, and both turn up in domains we monitor. First, the strictness gap: a root record with p=reject, sp=none (or a forgotten explicit subdomain record at p=none) means anyone can spoof anything.yourbrand.com unchallenged while the root stands guard. Attackers check for exactly this. Second, the aim gap: the sending subdomain gets set up correctly, but the humans point everything else at the apex. A recurring failure case with Klaviyo setups, common enough that our checker copy calls it out, is a branded sending domain living at send.yourbrand.com while the DMARC policy work, and even the "is my domain healthy" checking, gets aimed at yourbrand.com. The two are separate zones. Grading the apex tells you little about the domain your mail actually authenticates as, which is why our reports grade each sending path separately rather than pretending one domain-level verdict covers every stream.

Protect the root

Under the subdomain strategy, the only mail still sending as plain yourbrand.com should be mail from human beings: the founder replying to a customer, one person emailing another. Everything automated rides a subdomain.

The root domain is the identity you can least afford to burn and the one you can never replace. A scorched news.yourbrand.com is a bad quarter and a rebuild. A scorched root follows every stream and subdomain you run, and every hiring email and invoice your company sends, for as long as you own the brand. Keeping automation off the root is cheap insurance on the only unreplaceable asset in your email setup.

When a separate domain is honest (and when it's a trap)

The obvious next step, a wholly separate domain, is the one to resist. For consented mail it solves nothing: your newsletter subscribers signed up with your brand, mail from your brand's domain is what they expect, and a subdomain gives you all the isolation you legitimately need while keeping the identity truthful.

The one case where a separate domain is standard practice is cold outreach. Cold email is unconsented by definition, it will take reputation damage however well it's targeted, and practitioners run it on separate domains bought for the purpose so the operating business's domain survives the experiment. I'd rather tell you that plainly than pretend it away, and it's worth noticing what the practice admits: if a kind of mail requires a disposable identity, the mail is the problem, and the separate domain is a blast shield around it, never a fix for it.

The trap inside this practice is the lookalike domain: yourbrand-mail.com or try-yourbrand.com. It feels clever: the brand stays visible and the real domain stays shielded. It is the worst of every option. A freshly registered domain with no history starts with the reputation of a stranger. A domain imitating another matches the single most phishing-shaped pattern receivers screen for, and domain blocklists list lookalikes aggressively. Worst of all, it trains your own audience that mail from almost-your-domain is legitimate, which is precisely the reflex a real phisher will exploit against them later. If mail is honestly yours, send it from your domain or a subdomain of it. If it needs to pretend, don't send it.

Before you architect any of this, know what your current setup actually looks like from outside: the free health check reads the records on any domain or subdomain you give it, which makes it easy to check the apex and the sending subdomain side by side. The difference between the two is often the whole story.

Once your streams are split, receivers start answering each of them: bounce codes, complaint reports, feedback loops. What that return channel says, per stream, is the machinery you met in Part 3. The next test of the architecture is moving house: switching ESPs without losing your reputation.

Terms from this lesson

• mail stream - a category of mail with its own audience and risk profile: transactional, marketing, or colder sends like re-engagement and outreach.
• transactional mail - mail an individual recipient's own action triggered: receipts, password resets, notifications. Highest engagement, least affordable to lose.
• stream separation - giving each mail stream its own authenticated sending identity so reputation damage in one stream is contained there.
• subdomain strategy - the standard separation pattern: distinct subdomains (mail., news., send.) per stream, each with its own DKIM and SPF and its own reputation ledger.
• sp= tag - the DMARC tag that sets a separate policy for subdomains. A strict root with a lax sp= leaves the whole subdomain family spoofable.
• root domain (apex) - the bare brand domain. Reserve it for human one-to-one mail; it is the one identity you cannot replace.
• lookalike domain - a separate domain imitating yours (yourbrand-mail.com). Phishing-shaped, reputation-free at birth, and corrosive to your audience's ability to spot real phishing.

Check yourself

1. Why can a marketing campaign hurt password-reset deliverability when both send as yourbrand.com?

Both streams share one reputation ledger, so complaints against marketing reprice the shared identityPassword resets and promotions compete for the same SMTP connectionMarketing mail consumes the domain's DKIM key allowanceIt cannot; filters always score transactional mail separately

2. A domain publishes p=reject with sp=none in its DMARC record. What is the exposure?

The root domain becomes spoofableSPF stops being evaluated for subdomainsSubdomains can no longer publish their own DMARC recordsMail claiming any subdomain of the family faces no policy, while the root alone is protected

3. When is sending from a wholly separate domain (rather than a subdomain) standard practice?

For any newsletter above a few thousand subscribersWhenever the root domain already has a DMARC recordFor cold outreach, as a blast shield so the operating domain survives the reputation damageFor transactional mail, to protect the marketing stream

4. What makes a lookalike domain like yourbrand-mail.com the worst option?

It costs more to register than a subdomainIt combines a stranger's reputation with the exact shape of phishing, and it trains your audience to trust imitations of your domainIt cannot carry DKIM signaturesSubdomains of it are not covered by DMARC