One domain per job: why password resets should not share a reputation with outreach

The problem: shared domain, shared fate

Most teams send every kind of mail from one domain, because that is the obvious thing to do and nothing appears to go wrong. Then a marketing send does badly, and two weeks later password reset emails start landing in spam - and nobody connects the two, because those systems share no code, no queue, and no vendor. They share the only thing that mattered: the domain in the From: header.

Reputation is not what you think

Receivers score several identities independently: the sending IP, the From: domain, the DKIM signing domain (d=), and the envelope sender's domain. The one you control most cheaply, and the one that follows you across every provider, is the domain. That domain accumulates one history. Your password resets - near-100% open rate, effectively zero complaints, universally wanted - contribute to it. So does the cold campaign that went to a list somebody bought in 2023. The receiver does not know which system emitted which message. It sees one domain with one blended history. This is why the failure is always asymmetric. Transactional mail is the best-behaved traffic you have, and it is the thing that gets hurt, because it is the thing that could least afford the hit.

The split

Separate by risk profile, not by team:

The first three are subdomains, and that is deliberate - subdomains inherit some of the organizational domain's standing, which is an advantage when the parent is healthy. Cold outreach is the exception. It gets a separate registered domain, not a subdomain, precisely because you do not want inheritance running in the other direction. Cold outreach is the highest-variance traffic you will ever send, and the whole point is that when a domain burns, it burns alone.

The tag that decides whether this works

Splitting into subdomains does almost nothing unless you publish sp= on the organizational domain.

v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:d****@yourcompany.com; pct=100

p= applies to the organizational domain. sp= applies to subdomains, and when it is absent, subdomains inherit p=.

Two consequences people discover the hard way:

• If you enforce p=reject without thinking about subdomains, every subdomain inherits reject - including ones you forgot you had, and including any that are not fully authenticated yet.
• Conversely, sp=none is a deliberate escape hatch. It lets you enforce the brand domain while leaving one lagging subdomain at monitoring, so a single unfinished migration does not hold up enforcement everywhere else.

Both are useful. Neither happens by accident.

Each domain authenticates on its own

Subdomains do not inherit SPF or DKIM. mail.yourcompany.com needs its own v=spf1 TXT record and its own DKIM keys - inheritance applies to DMARC policy, not to authentication records.

Some common ways this goes wrong:

• A second SPF record. One domain may publish exactly one v=spf1 record. Two are a permanent error, not a merge, and both look valid inspected separately. This happens most often when a website host and a mail provider each add one, months apart.
• The ten-lookup ceiling. Every include, a, mx, ptr, exists and redirect costs a DNS lookup, including the ones nested inside your includes. include:_spf.google.com alone is four. Four vendors will break a record that still looks short.
• DKIM signing with the wrong domain. If d= is your ESP's domain rather than yours, the signature verifies and DMARC still fails, because nothing aligned.

Worth checking the whole tree rather than the first record: SPF, DKIM and DMARC checker, or spf-audit if you would rather run it in CI.

New domains start with no history, which is not the same as good history

A freshly registered outreach domain has no reputation at all, and receivers treat absence of history with suspicion rather than neutrality. It needs two to three weeks of gradually increasing volume before it carries real traffic.

The part that catches people: warm-up traffic and real traffic come out of the same daily budget. A mailbox warming at twenty a day that also sends thirty real messages is sending fifty from a mailbox with no history, and it is not warming - it is being pushed past what its history supports while a dashboard reports progress.

Migrating without a gap

If you are on one domain today, do not cut over:

• Stand up the new subdomain with its own SPF, DKIM and DMARC, and confirm it aligns by reading the Authentication-Results header on a real test message.
• Move transactional first - it is your most valuable and best-behaved traffic, so it establishes the new subdomain's history quickly and honestly.
• Move marketing next, and watch complaint rate as a leading indicator.
• Move cold outreach to its own registered domain last, after warm-up.

Keeping the old domain sending throughout is fine. What you are building is history on the new names, and that takes weeks whatever order you do it in.

Why start now

The reason to start now rather than when something breaks: reputation recovers slowly, and separation only helps traffic you moved before the damage.