Email sending subdomains: when you actually need one

Nearly every guide telling you to set up an email sending subdomain was written by an ESP whose next step is handing you a CNAME record. The advice is not wrong. It is just missing the part where a subdomain buys you exactly one thing, and most senders do not need that thing yet.

Here is the version we would give a colleague. A subdomain separates the reputation of one mail stream from another. That is it. It does not improve inbox placement, it does not make Gmail like you more, and on day one it makes things slightly worse. Whether that trade is worth making comes down to how many kinds of mail you send.

What an email sending subdomain actually is

Three domains travel with every newsletter and most people only ever look at one. The From header is the display address your subscriber reads. The envelope sender, which shows up in the Return-Path header, is where bounces go. The DKIM signature carries a d= tag naming the domain that cryptographically signed the message.

Mailbox providers build reputation on the second and third. A From header is cheap to forge, so Gmail and Yahoo weight what survives authentication instead: the SPF-checked envelope domain and the DKIM signing domain. Which means putting mail.yourbrand.com in the From line changes nothing at all if the Return-Path still resolves to your ESP's shared bounce domain and d= still says sendgrid.net.

Setting up a sending subdomain is a DNS job, not a From-line job. You publish the CNAME or TXT records the ESP gives you, the ESP starts signing as your subdomain, and the envelope sender moves with it. Skip the DNS part and all you have done is rename a label. If any of that is unfamiliar, our guide to SPF, DKIM and DMARC for newsletters covers the records themselves.

What the headers of real newsletters show

We read Return-Path, Message-ID and List-Unsubscribe hosts on every newsletter that lands in the Newsletrix corpus, because that is how our ESP detection works. Across the roughly 12,000 sends we hold raw headers for, three setups repeat.

The first is plain root-domain sending. From, Return-Path and the unsubscribe host all sit on brand.com. It is common among smaller senders, and among anyone who configured their ESP in an afternoon three years ago and never went back to DNS.

The second is a dedicated subdomain with everything lined up. From at [email protected], Return-Path on bounces.mail.brand.com, unsubscribe host on the same subdomain. This is the setup the advice is aimed at, and among the larger senders we track it is the most common of the three.

The third is the one worth pausing on. The From header shows a clean branded address while the Return-Path still lands on shared ESP infrastructure: sendgrid.net, klaviyomail.com, hubspotemail.net, amazonses.com, mail.beehiiv.com, e.customeriomail.com. From the inbox the brand looks like it runs its own sending setup. It does not. It shares a bounce domain, and usually an IP pool, with every other account on that plan.

None of the three is wrong for every sender. The third is only a problem if somebody on the team believed they were on the second. You can check any brand's setup, including your own, with the Newsletrix ESP detector, and the same header trail is what gives away a competitor mid-migration. It is also the reason header-level tracking beats screenshot archives like MailCharts when you care about how mail is sent rather than how it looks.

When you do not need a sending subdomain

The honest version, which ESP documentation rarely prints: if you send one kind of mail, to one list, from one platform, your root domain is fine. Reputation isolation has nothing to isolate.

Google and Yahoo's bulk sender requirements start at 5,000 messages a day to Gmail addresses. Under that line you still owe them SPF, DKIM, DMARC and one-click unsubscribe, but nobody is keeping a per-subdomain scorecard on you that is worth managing separately. A new subdomain at that volume is a liability, because it begins with no history and you do not send enough to build any.

There is a running cost too. Every subdomain is another record set to keep correct, another DKIM key to rotate, another property in Postmaster Tools, another thing that breaks quietly when somebody migrates DNS providers. We have watched a sender lose most of a week because a CNAME for a subdomain nobody remembered still pointed at an ESP they had left eight months earlier.

Four triggers that mean you do need one

Transactional and marketing mail leaving the same domain. This is the split that pays off for almost everyone. Receipts, password resets and shipping notices have to arrive, and marketing is where the complaints come from. A promotional campaign that annoys people drags the shared reputation down, and the first casualty is the mail subscribers asked for. Move marketing to its own subdomain and leave transactional where it sits.

An ESP migration. You are rebuilding signing infrastructure anyway, so it is the cheapest moment to separate streams. It also gives you a clean read: if old and new both sign as the same domain, you cannot tell which one is responsible when placement moves.

Cold sends and reactivation campaigns. Mail aimed at people who have ignored you for a year produces complaint rates several times a normal send. Run that from the domain your receipts leave from and you will be reading our complaint rate benchmarks for the wrong reasons.

Several brands under one root domain. Different audiences, different expectations, different complaint profiles. Separate subdomains.

Notice what is missing from that list. "It looks more professional" is not a trigger. Subscribers do not read the Return-Path.

The DMARC trap: p= versus sp=

This is the one that catches teams who did everything else right. A DMARC record published at _dmarc.brand.com carries a p= tag setting the policy for that domain. Subdomains inherit p= unless you publish sp=, the subdomain policy tag, explicitly.

It fails in two directions. You spend six months climbing to p=reject, then stand up mail.brand.com, and the inherited reject policy starts bouncing your own mail because DKIM alignment on the new subdomain is not finished yet. Or somebody fixes that by adding sp=none and never takes it back out. Now the root is at p=reject, the compliance report says enforced, and every subdomain underneath it, including ones nobody created, is unprotected.

If you publish sp=none, put a calendar reminder on it the same day. Temporary DNS is the most permanent thing in email. And if you are working toward BIMI, note that enforcement has to be real across the domains you send from, not just on paper at the root.

Warming a new sending subdomain without tanking your reputation

Google Postmaster Tools tracks domain reputation per subdomain, and for that purpose a subdomain is a separate domain. A fresh one does not inherit your root's good standing. It has no history. Not bad history, none, and Gmail's response to an unknown domain that suddenly sends volume is to throttle it.

So start with the people who open. Take subscribers who clicked in the last 30 days and send only to them for the first week or two, then roughly double volume every couple of days while watching the complaint rate. Google's line is 0.3 percent as a hard ceiling and 0.1 percent as the number to stay under. Cross 0.3 and throttling arrives quickly. Our deliverability benchmarks and the Postmaster Tools guide cover what the dashboards should look like while you ramp.

One opinion we will defend: do not do this in Q4. November and December are when your volume peaks, when everybody else's volume peaks, and when filters are least forgiving of anything unfamiliar. A warm-up that takes three weeks in February takes longer in November and costs you revenue while it runs. Migrate in a boring month, even when the boring month is inconvenient for the roadmap.

The naming decision nobody should agonise over

mail., news., email., em., send., e. All fine. No sender's inbox placement has ever turned on that choice, and we have seen teams spend a fortnight on it.

Two things do matter. Pick a name you will not want to change later, because renaming means warming again from zero. And never reuse a subdomain that previously sent something else, especially anything cold, since the reputation follows the name. Keep it one level deep while you are at it: deeply nested hosts add nothing and make DNS harder to read at 2am. The same logic applies to your click-tracking domain, which is a separate decision people often bundle in by mistake.

If you want a concrete next step, go read your own Return-Path. Open the last newsletter you sent yourself and look at the raw header. If the From says brand.com and the Return-Path says sendgrid.net, you now know which of the three setups you are running, and whether that was a decision or an accident.

Frequently asked questions

Do I need a subdomain to send email?

Not if you send one kind of mail to one list from one platform. A sending subdomain isolates reputation, and isolation only helps once you have two streams worth keeping apart. Below Google and Yahoo's 5,000-messages-per-day bulk sender threshold, with no transactional mail on the same domain, sending from your root domain is fine and gives you one less DNS record set to maintain.

Is sending from a subdomain better for deliverability?

No. A subdomain does not raise inbox placement on its own. It separates the reputation of one mail stream from another, so a marketing send that draws complaints cannot drag your password resets into spam. A brand new subdomain is temporarily worse for deliverability than your established root domain, because it starts with no sending history at all.

Should transactional and marketing email use the same subdomain?

No. This is the one split that pays off for almost every sender. Transactional mail such as receipts, password resets and shipping notices has to arrive, and marketing mail is where complaints come from. Put marketing on its own subdomain and leave transactional where it is, so a bad campaign cannot take your receipts down with it.

Does a new sending subdomain start with zero reputation?

Yes. Google Postmaster Tools tracks domain reputation per subdomain, so a fresh one has no history rather than good history inherited from the root. Gmail throttles unknown domains that suddenly send volume. Warm the subdomain over two to four weeks, starting with subscribers who opened or clicked in the last 30 days, and keep the spam complaint rate under 0.1 percent.

What is the difference between DMARC p= and sp=?

The p= tag sets the DMARC policy for the domain the record is published on. The sp= tag sets the policy for its subdomains. Subdomains inherit p= when sp= is absent, so a root domain at p=reject also rejects unaligned mail from every subdomain under it. Adding sp=none to work around a failing subdomain quietly removes enforcement from all of them, including subdomains you never created.

Related reading