Transactional Subdomain Strategy: Why mail. Beats the Apex

The domain you put in the From: header is the single biggest signal mailbox providers use to decide whether your password reset lands in the inbox or the spam folder. If that domain is your apex (example.com), every other system touching that name — your CRM, your support tool, your newsletter platform — is pulling on the same reputation rope. Splitting traffic onto a dedicated transactional subdomain is the cleanest fix.

This article walks through how to plan that split: why the apex is the wrong place to send from, where DKIM and DMARC records actually live, when to delegate a subdomain to your provider via CNAME, and the mistakes that show up most often when teams retrofit this.

Why a dedicated transactional subdomain beats the apex

Three forces push sending off the apex.

The first is reputation isolation. Mailbox providers track reputation per sending domain. If your marketing tool sends a promo from example.com and gets complaint-bombed, the reputation hit follows every other stream sending from example.com — including the password resets you cannot afford to delay. A transactional subdomain like mail.example.com gives that stream its own reputation surface, independent of whatever the marketing team does this quarter.

The second is the apex-CNAME problem. DNS forbids a CNAME record at a zone apex because the apex must hold SOA and NS records, and CNAME cannot coexist with other record types. Most modern email providers ask you to add CNAMEs (for DKIM, for tracking, sometimes for the whole sending domain). You can put those CNAMEs on a subdomain. You cannot put them on the apex. Trying to work around it with ALIAS or ANAME records is provider-specific and brittle.

The third is operational hygiene. When mail leaves tx.example.com, anyone reading bounce logs, DMARC aggregate reports, or blocklist queries can tell at a glance which system the traffic came from. When everything leaves example.com, you spend hours correlating selectors to figure out what sent what.

The three-stream model: site, transactional, marketing

The cleanest layout treats the apex as a brand identity, not a sending identity. Most consumer brands you receive mail from follow some version of this pattern, even if the exact names vary.

• example.com — the website, the marketing site, the corporate identity. It has MX records for inbound mail (so people can email hello@example.com) but is never used as a sending domain.
• mail.example.com or tx.example.com — the transactional subdomain. Receipts, password resets, OTPs, account notifications. Low complaint rate, high engagement, sub-second delivery expectations.
• marketing.example.com or news.example.com — the promotional subdomain. Newsletters, product announcements, drip campaigns. Higher complaint rate is expected and tolerated, because it is isolated from the transactional stream.

The win is that a bad newsletter send cannot drag your receipts into the spam folder, because Gmail and Outlook score marketing.example.com and mail.example.com as separate reputation entities. You can pause marketing for a week to repair a reputation hit without ever touching transactional flow.

DMARC subdomain policy and inheritance

DMARC has two policy fields: p= for the organizational domain and sp= for its subdomains. If you publish a DMARC record at _dmarc.example.com and omit sp=, every subdomain inherits p=. If you publish sp=, that value overrides p= for subdomains.

A common pattern looks like this:

_dmarc.example.com.   IN TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

This says: reject anything failing DMARC on the apex, reject anything failing DMARC on every subdomain, and use strict alignment for both DKIM and SPF.

Two nuances are worth knowing. First, a subdomain can publish its own _dmarc.<sub> record, which overrides the parent's sp= entirely. Some teams do this during cutover — they relax the policy on mail.example.com to p=quarantine while warming a new IP, then tighten it once aggregate reports confirm alignment. Second, sp= only applies if the subdomain does not have its own DMARC record. Once you publish _dmarc.mail.example.com, the parent's sp= is ignored for that subdomain.

If you are starting from a clean slate, publish DMARC at the apex with sp=reject and only add subdomain-specific records when a real reason appears.

DKIM record placement per subdomain

DKIM keys live at <selector>._domainkey.<sending-domain>. The sending domain is whatever appears in the From: header's domain part — that is also what the d= tag in the DKIM-Signature header has to match for alignment.

If you send from noreply@mail.example.com, the public key lives at:

selector1._domainkey.mail.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

Not at _domainkey.example.com. The records are scoped per sending subdomain, which means you can rotate keys on the transactional stream without touching the marketing stream, and a leaked key on one side does not compromise the other.

Use distinct selector names per stream. A useful convention is tx1, tx2 for the transactional subdomain and mk1, mk2 for marketing — that way dig TXT tx1._domainkey.mail.example.com tells you instantly which stream and which rotation generation you are looking at.

When to hand a subdomain to your ESP (CNAME delegation)

Some providers ask you to delegate an entire subdomain to them via CNAME. The DNS looks like:

m.example.com.        IN CNAME  customer123.esp-provider.com.

Every record under m.example.com — DKIM selectors, tracking subdomains, sometimes even MX for bounce handling — is then resolved out of the provider's zone. The provider can rotate DKIM keys, add new selectors, and roll TLS certificates without ever asking you to touch DNS again.

This is convenient. It is also a soft form of lock-in. When you eventually migrate to a different provider, you cannot cut the CNAME until the new provider is also fully wired up, and you have to coordinate the swap during a low-traffic window. The tradeoff is worth it for teams that do not want to manage rotation manually. If you do want full control — especially over a transactional subdomain where uptime matters — keep the records in your own zone and add specific CNAMEs only for the keys the provider needs.

A reasonable default: delegate the marketing subdomain (lower stakes, faster setup) and self-host the transactional subdomain records.

Worked plan: a real-world layout

For a hypothetical example.com, the full DNS plan for email might look like this:

; --- Apex: website, corporate inbox, no outbound sending ---
example.com.              IN MX     10 inbound.mailprovider.com.
example.com.              IN TXT    "v=spf1 -all"
_dmarc.example.com.       IN TXT    "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

; --- Transactional subdomain: self-hosted DKIM, strict SPF ---
mail.example.com.         IN TXT    "v=spf1 include:_spf.sesmetric.com -all"
tx1._domainkey.mail.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0G..."

; --- Marketing subdomain: delegated to the ESP ---
marketing.example.com.    IN CNAME  customer42.esp-provider.com.

The apex publishes v=spf1 -all because nothing sends from it. The transactional subdomain has its own SPF that includes only the transactional provider. The marketing subdomain is delegated wholesale to the ESP, which manages its own SPF, DKIM, and tracking records under that zone. DMARC at the apex covers everything, with sp=reject ensuring strict policy inheritance for every subdomain.

This layout gives you reputation isolation, clean DMARC reports per stream, and the option to switch transactional providers by changing one SPF include and one CNAME pair — without ever touching the website or the marketing setup.

Common subdomain mistakes

A few patterns show up over and over when teams retrofit a transactional subdomain into an existing setup.

• Sending from the apex anyway. The subdomain is provisioned, but the application's From: header still says noreply@example.com. DKIM aligns to the apex, reputation never separates. Fix the From: domain in the application config; the DNS work is wasted otherwise.
• One subdomain for both streams. mail.example.com carrying both receipts and newsletters defeats the entire purpose. Split before the first promotional send, not after the first deliverability incident.
• Forgetting sp= on the organizational DMARC record. Without sp=, subdomains without their own DMARC record inherit p=. If you intend strict policy on all subdomains, set sp=reject explicitly — the implicit inheritance has bitten teams during audits.
• Putting DKIM records at the wrong zone. selector._domainkey.example.com will not authenticate mail from mail.example.com. The selector zone must match the From: domain, full stop.
• Mixing MX with a sending subdomain. Adding MX records to mail.example.com because the apex already has them feels symmetric, but it is unnecessary and can confuse bounce routing. Inbound mail belongs on the apex (or a separate inbound.example.com). Sending subdomains should not accept mail unless you have a specific reason.
• Trying to CNAME the apex. If your provider's setup guide tells you to add a CNAME for example.com, stop and use a subdomain instead. Every modern provider supports subdomain setups.

The goal is a setup where each sending stream has its own reputation, its own keys, and its own kill switch. A transactional subdomain is the smallest unit of that isolation, and once it is in place, every other deliverability decision gets easier.