How to use subdomains to improve email deliverability

Key takeaways

• Mailbox providers score reputation per sending domain. Put marketing on its own subdomain and a complaint spike there stops taking your password resets with it.
• Subdomains contain damage, but they aren't a firewall. Providers still associate a subdomain with its parent domain, so a badly behaving subdomain can still cost you.
• Two subdomains cover most teams: one for transactional, one for marketing. Add more only when the owner or the risk profile changes.
• Each sending subdomain needs its own SPF, DKIM, and DMARC records, plus an aligned return-path. Misaligned bounce domains are the most common reason a correct-looking setup still fails DMARC.
• Nearly half of senders above 50,000 messages per month already separate marketing and transactional traffic across subdomains, according to Mailgun's State of Email Deliverability 2025.

Why one domain for everything is a risk

If your product sends both transactional and marketing email from the same domain, every campaign you send is a bet on your password resets.

Gmail, Yahoo, and Outlook evaluate sender reputation largely at the level of the domain that actually sends the mail. When your newsletter and your account alerts share example.com, they share a single reputation score. A subject-line test that draws complaints, a stale list that hits spam traps, or one bad import can push that score down, and the filtering that follows doesn't distinguish between the campaign that caused the problem and the login code your user is waiting on.

Splitting traffic across dedicated subdomains gives each stream its own reputation to build and its own blast radius. Send transactional mail from notify.example.com and marketing from newsletter.example.com, and a complaint spike on the marketing side stays mostly on the marketing side.

That separation buys you three things:

• Protection for critical flows. Signups, password resets, and MFA codes stop depending on how last week's campaign performed.
• Cleaner authentication. SPF, DKIM, and DMARC are easier to configure and enforce per stream when each stream has its own namespace.
• Room to change things. You can test a new provider, tighten a DMARC policy, or rebuild templates on one subdomain without gambling with product-critical mail.

What subdomains don't do

Most guides oversell this part. Subdomains get largely separate reputation, not fully independent reputation. Mailbox providers also track the organizational domain, so a subdomain inherits some of its parent's history and can damage it in return. Send garbage from newsletter.example.com long enough and it'll cost you example.com and everything under it.

Subdomains are a blast-radius control, not immunity. You get isolation, faster diagnosis, and a smaller thing to fix. You don't get permission to send mail people don't want.

The compliance angle

The bulk sender rules that Gmail and Yahoo introduced in February 2024, and that Microsoft began enforcing for consumer Outlook, Hotmail, and Live in May 2025, apply to anyone sending roughly 5,000 or more messages a day to a given provider. In short: aligned SPF and DKIM, a valid DMARC policy, spam complaints held well below 0.3%, and one-click unsubscribe on marketing mail.

We cover those requirements and the provider-specific gotchas in detail in email sender requirements. The part that matters here is that meeting them on a single mixed domain is possible but fragile. One stream's behavior sets the terms for every other stream, and marketing mail is where the enforceable requirements and the complaint risk both concentrate.

Subdomains let you apply the strict settings where they belong. Marketing gets an enforcing DMARC policy and one-click unsubscribe. Transactional keeps a conservative policy and a clean complaint history, and it stops being collateral damage.

Where subdomains earn their keep

Without separation, every routine change is a potential production incident. With it, each stream can be tested, tuned, and repaired on its own.

Do you actually need this yet?

If you send a few thousand messages a month, all of them transactional, from one provider, subdomain separation isn't your highest-value work. Authentication, list hygiene, and bounce handling matter more, and a new subdomain starts with no reputation at all, which means a warm-up period you didn't previously need.

Reach for subdomains when at least one of these is true:

• You send both transactional and marketing mail.
• You're approaching 5,000 messages a day to any single provider.
• Different teams own different email streams.
• You're planning a provider migration.
• You want to enforce DMARC on marketing without risking transactional delivery.

Adoption tracks with volume in practice. Only about 30% of the lowest-volume senders in Mailgun's 2025 survey had separated their streams, and for most of the rest that's a reasonable call.

Setting it up

1. Pick names that will still make sense in three years

Name subdomains for the job they do, not the tool that sends them. Avoid generic mail. and anything tied to a vendor you might replace.

• notify.example.com for receipts, password resets, and system alerts
• newsletter.example.com or updates.example.com for campaigns and lifecycle mail
• auth.example.com for OTPs and MFA codes, if you want security mail isolated from everything else

2. Configure DNS and authentication per subdomain

Each sending subdomain needs its own records. Most providers give you copy-paste values.

; SPF
newsletter.example.com.  TXT  "v=spf1 include:sendgrid.net -all"

; DKIM
s1._domainkey.newsletter.example.com.  CNAME  s1.domainkey.u12345.wl.sendgrid.net.

; DMARC
_dmarc.newsletter.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

; Optional: MTA-STS for TLS enforcement
_mta-sts.newsletter.example.com.  TXT  "v=STSv1; id=20260701T000000Z"

One detail that catches teams out: DMARC inherits downward unless you say otherwise. A policy of p=reject on example.com applies to every subdomain that lacks its own _dmarc record. If you want a different posture for subdomains, either publish a record on each subdomain or set the subdomain policy tag on the root:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com"

Here sp=none keeps subdomains in monitoring while the root stays strict. Plenty of teams have published a strict root policy and quietly broken a subdomain they forgot was sending.

Verify before you send:

dig +short TXT newsletter.example.com
dig +short TXT _dmarc.newsletter.example.com
dig +short CNAME s1._domainkey.newsletter.example.com

Then send a test message to a mailbox you control and check the received headers for spf=pass, dkim=pass, and dmarc=pass. A dkim=pass on the wrong domain still fails alignment, so confirm the d= value matches the subdomain in your From address.

3. Warm up gradually

A new subdomain has no reputation. Ramp volume over one to two weeks, starting with the people most likely to open.

Treat those numbers as a starting point, not a formula. What actually drives a successful warm-up is engagement: high opens and near-zero complaints at each step. If complaints climb or delivery slows, hold volume steady until it recovers instead of pushing to the next tier.

4. Set up monitoring per stream

Google retired the old Postmaster Tools interface in favor of v2, and the domain and IP reputation dashboards didn't survive the move. Google no longer publishes a reputation score, so if you've been told to watch for "a reputation drop," that dashboard is gone. Most subdomain guides still recommend it.

What to use instead:

• Postmaster Tools v2 compliance dashboard, per subdomain. Add each sending subdomain separately so you get its own view. The compliance status page reports whether you're meeting Gmail's sender guidelines.
• Spam complaint rate, still the number that matters most. Keep it under 0.1%. The 0.3% figure is where trouble starts, not a target.
• DMARC aggregate reports, with a separate rua mailbox or tag per subdomain so you can tell which stream a failure came from.
• Provider webhooks and bounce logs, broken out by stream, to catch bounce spikes and spam-trap hits early.

If you're still calling the Postmaster Tools v1 API, it's being retired alongside the interface and the v2 schema differs, so that integration needs updating.

Common mistakes

Too many subdomains. Rotating through disposable subdomains to dodge blocklists is a pattern providers detect, and it can cost you the root domain and your IP range. Keep a small number of long-lived subdomains and build real reputation on them.

Missing basic DNS records. Some filters penalize sending domains that don't resolve. Publish A and MX records for sending subdomains even when you never expect a reply.

A misaligned return-path. You set up SPF and DKIM on the subdomain, but your provider still uses the root domain for bounce handling. SPF alignment breaks and DMARC fails. Point the return-path at the same subdomain, or a dedicated bounces.newsletter.example.com. This is the most common reason a setup that looks correct still fails.

A shared tracking domain. One open and click tracking CNAME across every stream leaks reputation between them. Give each major stream its own tracking domain.

Beyond transactional and marketing

Two subdomains are enough for most teams. Add more when ownership or risk genuinely differs, not for tidiness.

Each additional subdomain is another warm-up, another set of DNS records, and another thing to monitor. That cost is worth paying when a stream has a different owner or a different risk profile, and not otherwise.

Subdomain or a separate domain?

For cold outbound, where the whole point is keeping risk away from your brand, a separate domain makes sense. For everything else, subdomains are the better trade: recipients recognize the brand, you inherit some of the parent domain's standing, and you've got one domain to manage. A separate domain starts from zero on both reputation and recognition.

Security and brand features get easier too

Separating streams also lets you configure authentication and branding per stream instead of settling on one compromise for all of them.

DMARC. Enforce on marketing, where the requirements and the risk concentrate, while transactional stays in monitoring until you have clean aggregate reports.

BIMI. Displaying your logo in Gmail and Yahoo requires DMARC at quarantine or reject plus a verified mark certificate. You can set that up on a customer-facing subdomain without dragging internal tooling and system alerts into enforcement.

MTA-STS and TLS reporting. Publish different TLS policies per subdomain depending on which infrastructure sends the mail.

Migration checklist

Audit

• Inventory every system currently sending mail on your domain
• Check existing SPF, DKIM, and DMARC records, including the root sp= tag
• Pull recent complaint and bounce rates as a baseline
• Add your domains to Postmaster Tools v2 if they aren't there

Provision

• Choose stream-based subdomain names
• Add SPF, DKIM, and DMARC per subdomain
• Add A and MX records for each sending subdomain
• Confirm the return-path and tracking domain align with the subdomain
• Add MTA-STS and TLS-RPT if your infrastructure supports it

Verify and ramp

• Authenticate each subdomain with your provider
• Send test mail and confirm spf=pass, dkim=pass, and dmarc=pass with the right d= domain
• Warm up over 7 to 10 days, starting with engaged recipients
• Watch complaint rates at each step and hold if they rise

Operate

• Route DMARC aggregate reports per subdomain
• Track bounces and complaints by stream
• Alert on sudden engagement or bounce changes
• Move remaining templates once the new subdomain is stable
• Revisit DNS, DMARC policies, and thresholds quarterly

Where Courier fits

Running multiple subdomains means routing each message to the right sending identity, which gets tedious fast when it lives in application code. Courier handles the routing layer: you configure your email providers and sending domains once, then send by template and Courier applies the right provider and subdomain per stream. Adding a marketing subdomain or migrating a provider becomes a configuration change rather than a deploy.

Start sending with Courier or read the email provider setup docs.

Frequently asked questions

Do subdomains have separate email reputation from the root domain? Largely, but not completely. Mailbox providers score the sending domain, so a subdomain builds its own reputation. They also track the organizational domain, so a subdomain inherits some of its parent's history and can damage it. Subdomains limit blast radius rather than eliminating it.

Should transactional and marketing email use separate subdomains? Yes, once you send meaningful volume of both. Marketing mail carries most of the complaint risk and most of the enforceable bulk-sender requirements. Keeping it on its own subdomain stops a bad campaign from affecting password resets and login codes.

Does a DMARC policy on my root domain cover subdomains? Yes. Subdomains without their own _dmarc record inherit the root's p= value. Use the sp= tag on the root record to set a different policy for subdomains, or publish a _dmarc record on each subdomain.

How long does warming up a new email subdomain take? Usually 7 to 10 days for moderate volume, longer above a few hundred thousand messages a day. Engagement matters more than the calendar: start with your most engaged recipients, raise volume in steps, and pause when complaints climb.

Do I need SPF and DKIM on every subdomain? Yes. Authentication doesn't inherit the way DMARC policy does. Each sending subdomain needs its own SPF record and DKIM keys, and the DKIM d= domain has to align with the From address for DMARC to pass.

Is a subdomain better than a separate domain for email? For product and marketing mail, yes. Subdomains keep brand recognition and inherit some standing from the parent domain. Separate domains make sense for cold outbound, where isolating risk from your primary brand is the goal.

How many subdomains should I use? Start with two: transactional and marketing. Add more only when a stream has a different owner or risk profile. Each one costs a warm-up, DNS records, and ongoing monitoring, and providers treat large numbers of short-lived subdomains as a spam signal.

Will moving to a subdomain hurt my current deliverability? Temporarily, if you move too fast. A new subdomain starts with no reputation, so migrate one stream at a time with a proper warm-up and keep the old path live until the new one is stable.

Bottom line

Subdomain separation is infrastructure hygiene, not a deliverability trick. It won't rescue mail people don't want, but it does mean one bad campaign or one wrong DNS record stops taking your signups and password resets down with it.

Start with two subdomains, one transactional and one marketing. Authenticate both properly, align the return-path, warm up on engaged recipients, and monitor each stream separately. Add more only when a stream earns it.