How to architect email subdomains for reputation isolation. The 4-stream model, naming conventions, and why [send.brand.com] beats [mail.brand.com].
Why Subdomains Matter for Deliverability
Mailbox providers do not trust domains in the abstract. They build reputation profiles for specific sending identities, and the granularity is finer than most senders realize.
Gmail's spam filter and Microsoft's, and Yahoo's tracks reputation at three levels: IP, domain, and subdomain. A complaint against news.yourbrand.com is recorded against that subdomain. It also bleeds slightly into the parent domain reputation, but the bulk of the damage stays where it occurred. Conversely, clean reputation on tx.yourbrand.com does not automatically lift the reputation of an underperforming news.yourbrand.com.
This is the entire foundation of subdomain strategy. By separating mail streams onto different subdomains, you contain blast radius. A bad campaign damages one subdomain. The rest of your sending is untouched.
The corollary is what happens when you do not separate streams. A SaaS company sends password resets, marketing newsletters, and account notifications all from noreply@yourbrand.com. A poorly targeted promotional campaign produces a 0.4% complaint rate. The next day, password resets start landing in spam. The customer cannot log in. Support tickets spike. The marketing campaign damaged transactional deliverability because both shared the same reputation profile.
This is not theoretical. It is the single most common deliverability emergency I have seen across enterprise senders. The fix is architectural, not tactical.
The Four-Stream Model
Most senders should think of their outbound mail as falling into four categories. Each category has different risk characteristics and should live on its own subdomain.
Stream 1: Corporate / Human Mail (Root Domain)
This is mail sent by actual humans from firstname.lastname@yourbrand.com. Sales outreach, support replies, executive communication, recruiting. It is low-volume, high-engagement, and irreplaceable you cannot afford to have this stream affected by any other sending.
Keep it on the root domain. yourbrand.com should be reserved for human-to-human mail. Nothing automated, nothing bulk.
Stream 2: Transactional Mail
Receipts, password resets, order confirmations, shipping notifications, two-factor codes. The recipient is expecting this mail. Engagement is high. Complaint rate is near zero.
Send from a dedicated subdomain like tx.yourbrand.com or transactional.yourbrand.com. Transactional mail builds reputation faster than any other stream because every message is opened, often within minutes. Isolating it on its own subdomain means that reputation works for you when other streams falter.
Stream 3: Marketing / Promotional Mail
Newsletters, campaigns, product announcements, drip sequences. Volume is high, engagement varies, and complaint rates are highest of any stream.
Send from news.yourbrand.com, mail.yourbrand.com, or similar. This is the subdomain that absorbs damage from poorly targeted sends. By containing marketing on its own subdomain, you protect everything else when a campaign underperforms.
Stream 4: Product / System Notifications
"Someone commented on your post." "Your weekly digest is ready." "John shared a document with you." This is mail that is technically transactional in intent but marketing in volume. Engagement is moderate, complaint rates are middle-of-the-pack.
Send from notify.yourbrand.com or alerts.yourbrand.com. It belongs on its own subdomain because it is too high-volume to share with transactional and too engagement-driven to share with marketing.
Subdomain Naming Conventions That Work
The subdomain name appears to recipients in two places: the visible From address (marketing@news.yourbrand.com) and, for mailbox UI that renders it, the unsubscribe link domain. Recipients form impressions from these strings.
Names that work:
tx,transactional- clear and unambiguousnews,mail,email- recognizable for marketingnotify,alerts- clear for system notificationssupport,help- for support stream if separatedaccount,auth- for security-related transactional
Names that work less well:
noreply- works as a mailbox name, not as a subdomainmailer,sender- feels machine-generatedm,n, single letters - opaque to recipientsmarketing- accurate but feels like an internal label
Names to avoid:
bulk,mass,blast- recipients see this and assume spam- Numbers and version suffixes (
mail2,mail-v3) - looks broken - Long compound names (
marketing-promotional-campaigns) - hurts perceived legitimacy
The naming itself does not directly affect deliverability. But mailbox providers track engagement with specific From-domains, and recipients are slightly less likely to engage with mail from bulk-mailer-3.yourbrand.com than from news.yourbrand.com. Small effect, compounded over millions of messages.
SPF, DKIM, and DMARC for Subdomains
Subdomains do not inherit SPF or DKIM from the parent domain. Each subdomain that sends mail needs its own authentication setup.
DMARC partially inherits via the sp= tag on the parent but the practical answer is to publish explicit DMARC records on subdomains that send.
SPF Per Subdomain
The SPF record on yourbrand.com does not authorize tx.yourbrand.com to send. They are separate DNS namespaces.
For each sending subdomain, publish a TXT record at the subdomain itself:
Note how each subdomain only authorizes the sending source for that stream. The marketing ESP is not authorized to send from tx.yourbrand.com. This is the architectural clarity that subdomain separation gives you and it constrains your SPF lookup count comfortably below the 10-DNS-lookup limit on every subdomain. (See SPF Records Demystified.)
DKIM Per Subdomain
DKIM signing requires a selector under the sending domain. For tx.yourbrand.com to sign with its own key:
Most ESPs handle this automatically when you add a sending subdomain. The selector is provided by the ESP; you publish the public key as a TXT record. The ESP signs outbound mail with the corresponding private key.
The result: a message from news.yourbrand.com is signed with a DKIM key under news.yourbrand.com, which aligns with the visible From-domain, which satisfies DMARC alignment.
DMARC Per Subdomain
The DMARC policy on the root domain applies to subdomains via the sp= tag. But explicit per-subdomain DMARC records give you finer control.
A common pattern:
The root is at p=reject because corporate mail is fully under your control. Transactional is at p=reject because it should never fail authentication. Marketing is at p=quarantine initially because high-volume campaigns occasionally have edge cases worth catching before full enforcement.
The rua= addresses are split per subdomain so aggregate reports route to the right operational owner. The marketing team gets marketing reports. The platform team gets transactional reports. Nobody has to filter through a single dmarc@ inbox.
The Migration Path: From Single Domain to Subdomain Architecture
Most senders start with everything on yourbrand.com and only consider subdomains after a deliverability incident. The migration is not complicated, but it requires sequencing.
Phase 1: DNS Preparation (Week 1)
Set up subdomains in DNS without sending from them yet. Each subdomain gets:
- An MX record (or no MX if you do not need to receive mail there)
- An SPF record listing only the relevant sending source
- A DKIM selector and public key from the relevant ESP
- A DMARC record at
_dmarc.subdomain.yourbrand.com
Verify all four resolve cleanly with dig. Run an MX-tester or mail-tester.com test to confirm authentication is configured correctly. Do not send real traffic yet.
Phase 2: ESP Configuration (Week 2)
Configure each sending platform to use its dedicated subdomain. This usually means:
- Adding a sending domain in the ESP UI
- Verifying the domain via DNS records the ESP provides
- Setting the From-address default to use the subdomain
- Updating the unsubscribe link domain to match (optional but cleaner)
Send test campaigns to seed addresses. Verify in Gmail's "Show original" that SPF: PASS, DKIM: PASS, and DMARC: PASS, and that the authenticated domain matches the From-domain.
Phase 3: Traffic Migration with IP Warming (Weeks 3-6)
This is where senders rush and break things.
Each new subdomain has zero reputation. Sending full marketing volume from a brand-new news.yourbrand.com on day one looks identical to a spammer registering a new domain. Mailbox providers will throttle aggressively.
You need to warm the subdomain the same way you would warm a new IP. Start small, ramp gradually. (See IP Warming in 2023: A 30-Day Schedule That Actually Works for the operational template.)
A reasonable ramp for a marketing subdomain:
- Days 1-3: Top 10% most-engaged segment, max 5,000/day
- Days 4-7: Top 25% most-engaged, max 25,000/day
- Days 8-14: Top 50% engagement, gradual ramp to 50% of normal volume
- Days 15-30: Full volume
Transactional subdomains warm faster because every message is opened. A 7-day ramp is usually sufficient.
Until the warming is complete, keep sending from the old domain in parallel. Migrate volume gradually. The old domain reputation is a buffer; do not give it up overnight.
Phase 4: Cutover and Cleanup (Week 7+)
Once all streams are sending stable volumes from their respective subdomains and reputation is established, cut traffic from the old domain entirely.
The old domain (yourbrand.com itself) is now reserved for corporate/human mail only. Lock it down: SPF authorizing only your corporate Workspace/Microsoft 365, DKIM signed for the same, DMARC at p=reject. Anyone who tries to spoof your root domain is rejected outright.
The Mistakes Senders Make
These are the patterns I see most often when reviewing subdomain architectures.
1. Subdomains exist but everything still sends from the parent. The DNS is set up, the SPF records are published, but the ESP was never reconfigured to actually use the subdomains. Cosmetic separation, no actual reputation isolation. Verify by sending real campaigns and checking the From-header in the received message. The visible domain should be the subdomain, not the root.
2. Subdomain SPF includes the parent domain. Someone published v=spf1 include:yourbrand.com -all on the subdomain, thinking it would inherit the parent. It does not work that way it just adds DNS lookups and pollutes the namespace. Each subdomain should authorize only its own sending sources.
3. DKIM signed with the wrong domain. The ESP is sending from news@news.yourbrand.com, but the DKIM signature is for yourbrand.com. Alignment fails. DMARC fails. The whole point of separation is undermined. Verify in "Show original" that the DKIM d= parameter matches the From-domain.
4. Treating subdomains as cosmetic. Some teams set up news.yourbrand.com and immediately route the unsubscribe link, the click tracking domain, and the reply-to address back to yourbrand.com. From a reputation perspective, this leaks signals. Click tracking on a different domain partially defeats the isolation. Keep the entire flow on the subdomain where possible.
5. Forgetting subdomains exist. Marketing creates a summer-2024.yourbrand.com for a campaign, sends a million messages, never publishes DMARC. Three months later, that subdomain is still live in DNS, still authorized to send via SPF, and now it is a target for spoofing. Decommission unused subdomains. Or, at minimum, lock them down with p=reject and an empty SPF that authorizes nothing.
A Concrete Architecture Example
For a typical mid-sized company sending across all four streams:
| yourbrand.com | Corporate/human mail (Workspace) |
| tx.yourbrand.com | Transactional (password reset, receipts) |
| news.yourbrand.com | Marketing campaigns |
| notify.yourbrand.com | Product notifications |
Four subdomains. Each authorizes one ESP. Each has its own DKIM signing. Each has its own DMARC policy and reporting. A complaint on news.yourbrand.com does not damage tx.yourbrand.com. A bug in the notification pipeline does not affect transactional delivery.
This architecture takes one week to set up cleanly. It survives ESP migrations, marketing campaigns gone wrong, and security incidents. It is the cheapest deliverability insurance you can buy.
Frequently Asked Questions
Should I use a subdomain or a completely separate domain for marketing?
Does subdomain reputation help my parent domain?
Can I use the same IP for multiple subdomains?
What about the Return-Path / bounce domain?
How does this interact with BIMI?
Is this overkill for small senders?
What if my ESP does not support custom sending subdomains?
Key Takeaways
- Reputation is per-domain. Mailbox providers track subdomain reputation independently from parent-domain reputation, which means subdomain architecture contains blast radius.
- The four-stream model: corporate/human on the root, transactional on tx., marketing on news. or mail., system notifications on notify..
- Each subdomain needs its own SPF, DKIM, and DMARC. Subdomains do not inherit authentication from the parent.
- Migration requires warming. New subdomains have zero reputation; ramp volume gradually over 4-6 weeks while keeping the old domain in parallel.
- The naming matters slightly. Avoid bulk, blast, version-numbered names. Prefer clear, recognizable subdomains.
- The architecture takes a week to set up. The protection lasts for years.
Most deliverability emergencies I have responded to could have been one-third the severity if the affected stream had been on its own subdomain. Build the architecture before you need it.
Related articles
Deliverability Incident Response: A Playbook for the First 4 Hours
When email reputation collapses, the first 4 hours determine the recovery timeline. Triage, containment, communication the operational playbook teams actually need.
List Hygiene Beyond Bounces: Engagement-Based Suppression Strategies
Bounce-based list cleaning is decades behind modern deliverability. The 90/180/365-day engagement model, sunset policies, and re-engagement that actually works.
DKIM Key Rotation: A Practical Guide for Production Environments
How to rotate DKIM keys in production without breaking signatures. Dual-selector strategy, 2048-bit key sizes, and the rotation cadence that actually works.