It is 22:00 on Black Friday. Marketing fired a campaign to a list that has not been cleaned since last year — a few thousand addresses that went dormant, some now recycled by Gmail into spam traps. Complaints climb past 0.3% in Postmaster Tools within the hour. By midnight the password-reset emails, the receipts, the "someone logged into your account" alerts — all signed with the same DKIM d= domain — are landing in spam. Support tickets pile up because people cannot get back into their accounts. Nobody touched the transactional code. The blast radius from one bad list took down the mail your users actually asked for.
This is the failure mode a shared sending domain guarantees eventually. The fix is not better subject lines or a warmup SaaS. It is DNS-level segregation: give each mail stream its own subdomain, each with its own SPF, DKIM, and DMARC, and each with its own reputation ledger at the mailbox providers. Subdomains are cheap, reversible reputation firewalls. This piece shows the exact records, the alignment bug that silently breaks DMARC when you split streams, and how to prove the wall is real before you trust it.
The blast radius problem
Gmail, Yahoo, and Microsoft do not score reputation on IP alone. They score it primarily at the domain level, and specifically at the domain that signs the message — the DKIM d= value and the return-path (SPF smtp.mailfrom) domain. Everything that signs with the same d= shares one reputation bucket. Your triggered receipts and your promotional blast are, as far as the filter is concerned, the same sender.
So when a campaign drives your complaint rate past Gmail's 0.3% enforced ceiling (the target you actually want is under 0.1%), the penalty does not land on "the marketing emails." It lands on the signing domain. Transactional mail riding that same d= gets filtered too. The user who asked for a password reset pays for the marketing team's stale list.
How mailbox providers scope reputation
Get the mental model right and every downstream decision is obvious. Reputation attaches to two things: the DKIM `d=` domain and the SPF return-path domain. Not the visible From: text — a filter does not care what the header display says, it cares which domain cryptographically signed the mail and which domain the bounce address belongs to.
Providers roll subdomain reputation upward toward the parent, but not sideways between siblings. If news.evilmail.pro gets torched, that damage does not directly poison mail.evilmail.pro — they are separate leaves. It can slightly drag the root evilmail.pro, because the parent aggregates its children. That single fact dictates the layout: the root domain should send nothing. Keep it as a clean DMARC parent and neutral reputation anchor, and no amount of marketing damage can pull it into a hole that then shadows the transactional child.
Two more provider rules from the Feb 2024 Gmail/Yahoo bulk-sender requirements, still enforced in 2026, shape the design. Any sender doing 5,000+ messages/day to Gmail needs SPF and DKIM and DMARC, with an aligned From:. Marketing streams additionally need one-click unsubscribe per RFC 8058 — the List-Unsubscribe-Post: List-Unsubscribe=One-Click header plus a working POST endpoint. Transactional mail is exempt from the unsubscribe rule, which is one more reason not to mix the two under one identity: the compliance surface is different per stream.
The subdomain layout that works
- `evilmail.pro` — corporate root and DMARC parent. Non-sending. This is the anchor you protect at all costs.
- `mail.evilmail.pro` (or
t.evilmail.pro) — transactional: receipts, password resets, security alerts, anything triggered by a user action. - `news.evilmail.pro` (or
e.evilmail.pro) — marketing and bulk: newsletters, promos, lifecycle campaigns.
Keep subdomain labels short — bounce and feedback-loop addresses live under them, and short is cleaner in headers. Avoid email., mailer., mail-out. and similar; they read as throwaway sender domains and some filters treat them with suspicion. If you split transactional across two ESPs (say, one for OTPs and one for everything else), give each its own subdomain so their reputations stay independent too.
Subdomain isolation is a DNS-scoped property, so it works even on shared IP pools. You do not need dedicated IPs for the wall to hold — reputation is domain-scoped, and two subdomains on the same shared pool still carry separate domain reputations at Gmail. Dedicated IPs are a separate, later optimization.
DNS records, per stream
Here is the full record set. Every subdomain gets its own DKIM keypair and its own return-path. Reuse one d= across both streams and you have rebuilt the shared bucket you were trying to escape — one keypair, one return-path, per subdomain, no exceptions.
; --- Transactional: mail.evilmail.pro ---
mail.evilmail.pro. TXT "v=spf1 include:_spf.esp-transactional.net -all"
s1._domainkey.mail.evilmail.pro. CNAME s1.dkim.esp-transactional.net.
_dmarc.mail.evilmail.pro. TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"
; custom MAIL FROM so the return-path aligns
bounce.mail.evilmail.pro. MX 10 feedback-smtp.esp-transactional.net.
bounce.mail.evilmail.pro. TXT "v=spf1 include:_spf.esp-transactional.net -all"
; --- Marketing: news.evilmail.pro ---
news.evilmail.pro. TXT "v=spf1 include:_spf.esp-marketing.net -all"
s1._domainkey.news.evilmail.pro. CNAME s1.dkim.esp-marketing.net.
_dmarc.news.evilmail.pro. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"
bounce.news.evilmail.pro. MX 10 feedback-smtp.esp-marketing.net.
bounce.news.evilmail.pro. TXT "v=spf1 include:_spf.esp-marketing.net -all"
; --- Root: sends nothing, governs children ---
_dmarc.evilmail.pro. TXT "v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]"
evilmail.pro. TXT "v=spf1 -all"Note the root SPF: v=spf1 -all says "nothing is authorized to send as the bare root." The root DMARC carries p=reject for the root itself and sp=quarantine as the default for any subdomain that lacks its own _dmarc record — a safety net, not the primary control. Each sending subdomain publishes its own _dmarc, which overrides sp= for that subdomain, letting you tighten each stream on its own schedule.
The alignment trap when you split streams
This is the bug that eats a day of debugging. DMARC does not just check that SPF or DKIM passed — it checks alignment: the passing domain has to match the From: domain. Under relaxed alignment (adkim=r/aspf=r, the default) a match at the organizational level counts, so d=mail.evilmail.pro aligns with From: [email protected]. Under strict (adkim=s/aspf=s) it must be an exact string match.
The trap: your ESP validly signs mail with their domain, d=esp-marketing.net. DKIM verifies — the signature is cryptographically fine. But esp-marketing.net does not align with From: [email protected], so DMARC fails despite a green DKIM. Same story on the SPF side if the return-path is the ESP's shared bounce domain instead of your subdomain.
The fix is exactly the record set above: a custom MAIL FROM domain (bounce.news.evilmail.pro) so the return-path is a subdomain of your From:, and branded/CNAME DKIM so the ESP signs with d=news.evilmail.pro instead of their own domain. Now both the SPF and DKIM identities are org-aligned subdomains of the visible From:, and relaxed alignment passes cleanly. Keep alignment relaxed on both streams unless you have a specific reason for strict. Strict adkim=s demands the DKIM d= be an exact string match to the From: domain, so it fails the moment your ESP signs with a subdomain of it — say d=m.news.evilmail.pro — where relaxed would have passed.
Rolling it out without breaking live mail
- 1.Stand up DNS first. Publish all records with the new subdomains' DMARC at
p=none. Let TTLs settle. - 2.Warm the new subdomains. Transactional warms itself — real triggered volume ramps organically as you cut traffic over, and it is inherently high-engagement mail. Marketing needs a graduated ramp on the fresh subdomain: roughly 50 → 500 → 5,000 → 50,000/day over 10–14 days, sending your most engaged segments first so early signals are positive.
- 3.Cut over `From:` and return-path per stream, one at a time. Transactional first (it is the higher-stakes stream and warms fastest), marketing second behind its ramp.
- 4.Watch the data for a week. Read DMARC aggregate (RUA) reports and Postmaster Tools domain reputation before you touch policy or decommission anything.
- 5.Tighten policy once RUA reports come back clean for ~7 days: move each subdomain from
p=nonetop=quarantine, then top=rejectfor transactional. Marketing can sit atquarantine
Verifying the wall is real
Do not trust the split until you have read it out of the headers. Confirm the records resolve, then send a live test to a Gmail account and inspect Authentication-Results.
# Records resolve as expected
dig +short TXT mail.evilmail.pro
dig +short TXT _dmarc.news.evilmail.pro
dig +short CNAME s1._domainkey.mail.evilmail.pro
# In the received message header (Gmail: "Show original"),
# every line below must be present and aligned:
# spf=pass (mailfrom=bounce.mail.evilmail.pro) smtp.mailfrom aligns
# dkim=pass header.d=mail.evilmail.pro d= aligns to From:
# dmarc=pass (p=QUARANTINE ... header.from=mail.evilmail.pro)Three checks prove isolation: smtp.mailfrom is your bounce subdomain (not the ESP's), header.d is your sending subdomain (not the ESP's), and dmarc=pass with a header.from= that matches. If header.d shows esp-marketing.net, your branded DKIM is not live and you have isolated nothing — you have only added a subdomain to the From: while reputation still accrues to the ESP's shared domain.
In Postmaster Tools you should eventually see two independent domain-reputation graphs, one per subdomain. A healthy curve sits flat at High/Medium; a degrading one steps down over days as complaint rate creeps up. The whole point of the split is that when the marketing graph dips, the transactional graph does not move.
Checklist before you trust the split in production
- Root
evilmail.prosends nothing and publishesv=spf1 -allplus root DMARC withsp=. - Each stream has its own DKIM keypair — no
d=is shared between transactional and marketing. - Custom MAIL FROM (
bounce.<sub>) is configured so the SPF return-path aligns to theFrom:domain. - Branded/CNAME DKIM live:
header.din real headers equals your sending subdomain, not the ESP's. Authentication-Resultson a live test showsspf=pass,dkim=pass,dmarc=pass, all aligned.
Subdomains cost nothing and undo cleanly — you can collapse or re-split streams by editing DNS. There is no reason to run your receipts and your newsletters out of the same reputation bucket in 2026. Draw the wall, prove it holds, and the next stale-list Black Friday campaign stays a marketing problem instead of a login outage.