Email subdomain strategy for safer sending

Most companies start by sending everything from example.com — receipts, marketing newsletters, employee mail, the whole stream. It works until one of those streams misbehaves and the others start landing in spam. Subdomain separation is how you stop letting a Black Friday campaign hurt your password reset emails.

For the broader reputation plan, use the reputation hub and monitor the split with domain monitoring as each stream builds history.

The recommended layout

How separation actually protects you

Modern receivers (Gmail especially) maintain reputation per-domain, not just per-IP. If news.example.com racks up complaints, that reputation hit stays mostly local — mail.example.com retains its standing because it's a different reputation entity. Without separation, every subdomain shares one bucket.

DNS layout for the split

When to migrate

1. Stand up the new subdomain with DNS, SPF, DKIM, and a warming plan.
2. Send a test cohort (1-5K most-engaged users) for 2 weeks.
3. Gradually shift volume over 4-6 weeks while monitoring deliverability on both old and new.
4. Once new is at full volume, announce the change in a normal email so users see the new From: domain in context.
5. Keep the old domain warm with low-volume corporate mail; don't let it go silent.

Additional guidance: Email Subdomain Strategy: Separating Transactional, Marketing, and Cold

An email subdomain strategy means sending each mail stream — transactional, marketing, cold outreach — from its own subdomain (like txn.example.com and news.example.com) so mailbox providers score each stream's reputation separately. Your receipts keep landing even when a marketing campaign draws complaints. Set it up with per-subdomain SPF, DKIM, and DMARC, warm each subdomain gradually, and put cold outreach on a separate lookalike domain entirely — not a subdomain.

Everything else in this post is the mechanics of doing that without shooting yourself in the foot.

Why providers score reputation per domain and subdomain

Mailbox providers don't have one reputation score for "you." They maintain scores at multiple levels: the IP, the root domain, the subdomain, and even the From: domain seen by users. Gmail has weighted domain reputation heavily for years, and Yahoo explicitly moved to domain-reputation-first scoring in April 2025 — the domain and subdomain now lead, with the IP as a supporting signal.

Crucially, subdomains get partially independent scoring. Gmail's classifiers treat mail.example.com and txn.example.com as related but distinct senders. A complaint spike on mail.example.com tarnishes that subdomain first and the root domain second. That gradient is the entire opportunity: you can engineer where reputation damage lands by choosing where each stream sends from.

The flip side, which trips people up: "partially independent" cuts both ways. Subdomain reputation bleeds upward over time. Sustained abuse from promo.example.com will eventually drag example.com down with it, and your corporate mail (@example.com on Google Workspace or Microsoft 365) can end up in the blast radius. Subdomains are firewalls, not bunkers. For genuinely risky traffic, you need a different domain altogether — more on that below.

If you're fuzzy on how the domain layer and IP layer interact, read domain reputation vs IP reputation first. This post assumes that model.

The stream-separation model

Different mail streams have wildly different risk and engagement profiles. That's why they belong apart:

The standard layout:

• `txn.example.com` (or app., mailer.) — transactional only. This subdomain is sacred. Nothing promotional ever touches it.
• `news.example.com` (or mail., email.) — marketing and newsletters.
• `app.example.com` — product/lifecycle mail, if your volume justifies a third lane. Many teams fold this into txn..
• Cold outreach — a different root domain. example-mail.com, getexample.com. Not a subdomain.

Why does cold get a separate domain instead of a subdomain? Because the bleed-up risk is real and cold outreach generates complaint rates an order of magnitude higher than opt-in mail. A 0.5% complaint rate on cold.example.com is attached, via the organizational domain, to example.com in providers' reputation graphs. A lookalike domain quarantines that risk completely. (Yes, lookalike domains have their own problems — no inherited reputation, extra DMARC setup, and they can look phishy if done lazily. Cold email deliverability playbook covers the warm-up and setup specifics.)

Naming conventions are debated endlessly and matter less than people think. txn. vs app. vs mailer. is a taste call. What matters:

1. Human-plausible. The subdomain shows up in the From: address and mail clients. [email protected] looks like a phish; [email protected] looks like a receipt.
2. Stream-honest. Don't send marketing from txn.. Providers classify streams by content too, and mismatching erodes the trust you're trying to build.
3. Finite. Two to four subdomains is a strategy. Twelve is a red flag — see pitfalls below.

For more on why the streams themselves behave differently under filtering, see transactional vs marketing email.

DNS layout per subdomain: a working example

Each sending subdomain needs its own complete authentication stack. Here's a realistic DNS layout for the two-stream model, assuming your ESP asks you to delegate or CNAME for DKIM (adjust to your provider's actual records):

; --- Root domain: corporate mail only (Google Workspace) ---
example.com.            TXT  "v=spf1 include:_spf.google.com -all"
example.com.            TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; fo=1"

; --- Transactional subdomain (ESP #1) ---
txn.example.com.        TXT  "v=spf1 include:esp1.example.net -all"
s1._domainkey.txn.example.com.  CNAME  s1.domainkey.u123.esp1.example.net.
s2._domainkey.txn.example.com.  CNAME  s2.domainkey.u123.esp1.example.net.

; --- Marketing subdomain (ESP #2) ---
news.example.com.       TXT  "v=spf1 include:esp2.example.com -all"
k1._domainkey.news.example.com. CNAME  k1._domainkey.esp2.example.com.

; --- DMARC reports for subdomains inherit the root policy (sp= applies to all subs) ---

Notes on what you're looking at:

• SPF is per-subdomain. Each subdomain's TXT record includes only the ESPs that actually send for it. Keep each record under the 10-lookup limit; a bloated record silently fails as permerror.
• DKIM is per-stream with distinct selectors. s1/s2 on txn. belong to the transactional ESP; k1 on news. belongs to the marketing platform. Never share selectors across streams — you want to be able to revoke or rotate one without touching the other, and per-stream keys make forensic analysis of aggregate reports far easier.
• DMARC inherits downward. The root's p=reject plus sp=reject covers every subdomain automatically — you don't need a DMARC record per subdomain unless one stream needs a different policy (e.g., p=none on a new subdomain during warmup while the root stays at reject). The sp= tag is exactly the lever for that; we detail it in DMARC subdomain policy (sp= tag).

Verify every record after publishing — DNS typos are silent killers. Run each subdomain through the free SPF checker to confirm the record resolves, stays under the lookup limit, and includes the right senders.

Pitfalls that quietly wreck subdomain strategies

1. Spawning too many subdomains. Each fresh subdomain starts with zero reputation. Ten subdomains means ten cold starts and ten reputations to sustain. Worse, the pattern "new subdomain every quarter" is a classic snowshoe-spam tell (snowshoeing = spreading volume across many identities to dodge filters). Filters recognize it. Keep it to two to four, each with real, steady volume.

2. Forgetting each subdomain needs its own warmup. Reputation doesn't transfer downward from the root. A brand-new news.example.com sending 100k on day one gets throttled and bulked exactly like a new IP would. Ramp each new subdomain over 2–4 weeks, starting with engaged recipients.

3. Splitting one stream across subdomains. Receipts from txn.example.com on Monday and mail.example.com on Tuesday splits the engagement signal and confuses per-subdomain scoring. One stream, one home.

4. Letting the root domain send marketing. The root is where your human corporate mail lives. Every marketing complaint against example.com directly threatens the deliverability of your CEO's email to investors. Push all bulk streams off the root; keep the root for people.

5. Inconsistent From alignment. DMARC alignment requires the visible From: domain to match the authenticated domain (relaxed alignment allows subdomains of the organizational domain). Sending from news.example.com while DKIM-signing as the ESP's shared domain passes SPF-but-not-alignment setups are the #1 cause of "we set up DMARC and everything failed." Always sign with your own subdomain.

A migration plan for teams sending everything from the root

If you're currently blasting all streams from example.com (extremely common in companies that grew organically), here's the sequence that doesn't break anything:

Week 0 — Inventory. List every sending source: ESPs, CRMs, support desks, WordPress, billing systems. Aggregate DMARC reports are the cheat code here — they enumerate everything sending as your domain.

Week 1 — Pick the first mover: marketing. Marketing has the most to gain and tolerates ramping. Stand up news.example.com: SPF, DKIM selectors, verify with the SPF checker, confirm DMARC alignment passes.

Weeks 2–5 — Warm `news.` Move marketing volume gradually: 10% of campaigns week one, 25%, 50%, 100%. Watch placement per campaign.

Week 6 — Move transactional to `txn.` Transactional is easier to move (engagement is sky-high, so warmup is fast) but riskier to break (password resets can't fail). Migrate in low-traffic windows and watch bounce rates hourly for the first 48 hours. For the dev side of testing transactional mail during the move, an email sandbox helps.

Week 7 — Clean the root. Update the root's SPF to include only corporate mail. Move DMARC to p=reject with sp=reject if you haven't already. Lock it down.

Ongoing — Monitor per subdomain. Set up DMARC monitoring with alerts so drift — a new tool sending as the root, a broken DKIM selector, an SPF record that stopped resolving — pages you before Gmail notices. And before any big send from a young subdomain, run a message through the free email deliverability tester to catch authentication or content regressions.

The whole migration takes six to eight weeks. Most of that is warmup patience, not labor.

The forgotten senders: auditing third-party tools

The most common way a clean subdomain strategy dies isn't a bad campaign — it's a tool nobody remembered. Support desks (Zendesk, Intercom), CRMs, billing platforms, survey tools, and calendar apps all send email as your domain, and each one was probably configured years ago by someone who's since left. They default to sending from your root domain or, worse, from whatever subdomain felt convenient during setup.

Before you finalize any subdomain architecture, enumerate everything. The reliable method is DMARC aggregate reports: publish a DMARC record with a rua address, wait two weeks, and read the XML. Every source sending as your domain shows up with its SPF/DKIM pass rates. Teams routinely discover three to five senders they didn't know they had.

Then assign each tool to its proper lane:

• Support replies and ticket notifications → transactional (txn. or a dedicated support.)
• CRM-triggered sequences → marketing (news.), because they generate complaints like marketing
• Billing and invoices → transactional, always — dunning mail in the spam folder is how churn happens silently

After migration, the audit isn't done — it's continuous. New tools get connected, old credentials get reused for new purposes, DNS records get edited by well-meaning colleagues. DMARC monitoring with alerts is the tripwire: when a new source appears or an existing one starts failing alignment, you find out from your dashboard instead of from a deliverability incident.

Do subdomains really isolate reputation? (Setting expectations)

Yes, with asterisks. In practice:

• Day-to-day filtering is strongly per-subdomain. Marketing complaints on news. will not keep receipts from txn. out of the inbox. This is the win you actually bought.
• Sustained abuse bleeds up. Months of spammy behavior on any subdomain degrades the organizational domain. Subdomains buy you fault isolation and blast-radius containment, not immunity.
• User-visible trust doesn't fully transfer. Recipients who trust example.com may side-eye news.example.com at first. Clear, consistent From names ("Acme News") mitigate this.

That's why the complete strategy has two tiers: subdomains for streams that belong to your brand, separate domains for traffic (cold outreach) that shouldn't be in the same reputation family at all.