Should Transactional and Marketing Email Use Separate Subdomains?

Two kinds of mail, two kinds of reaction

Transactional mail is something the recipient asked for a moment ago: a sign-in code, a receipt, a reset link. It gets opened, and almost nobody marks it as spam. Marketing mail is something they agreed to at some point: some of it is welcome, some is ignored, and some gets reported. That is normal, but it is a very different record.

Resend puts the case for separating them in two parts. The first is reputation isolation: when something goes wrong (a signup form flooded with fake addresses, a campaign that gets reported), the damage stays on the subdomain that caused it. The second is sending purpose transparency: a subdomain per purpose tells inbox providers what kind of mail to expect from it, which helps them place it.

Google makes the same point about IP addresses. Its sender guidelines say that if you must send from several IPs, you should use a different one for each message type, account notifications on one and promotions on another. Subdomains are how most teams on a shared ESP get the same separation without managing IPs.

A layout that works

acme.com           people: Google Workspace or Microsoft 365
notify.acme.com    transactional: sign-in codes, receipts, password resets
news.acme.com      marketing: newsletters, product updates, promotions

Keep the root domain out of bulk sending entirely. It carries your team's everyday mail, and a reputation problem there is the slowest to recover from. Pick subdomain names that say what the mail is. Avoid lookalike domains such as acme-mail.com: Resend notes they read as suspicious to filters and recipients alike.

How SPF, DKIM and DMARC apply

SPF and DKIM are set up per sending subdomain, with the records your provider generates for it. DMARC is the one you can publish once: a subdomain without its own _dmarc record falls under the root domain's, using its sp= policy if set and p= otherwise. The full inheritance rules are in how DMARC applies to subdomains.

; DMARC once, at the root. Subdomains inherit sp=.
_dmarc.acme.com              TXT  "v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@acme.com"

; Each subdomain gets the DKIM key and SPF its own provider gives you.
resend._domainkey.notify.acme.com   TXT  "p=MIGfMA0..."
send.notify.acme.com                TXT  "v=spf1 include:amazonses.com ~all"

Alignment still works. Under DMARC's default relaxed mode a DKIM signature for notify.acme.com aligns with a From address on notify.acme.com, and with one on acme.com, because they share an organizational domain. Strict mode would break the second case, so leave alignment relaxed unless you have a reason not to.

What changes for marketing mail

Separating the streams also makes the rules easier to follow. Google requires marketing and subscribed messages from senders of 5,000 or more a day to support one-click unsubscribe, the List-Unsubscribe-Post header defined in RFC 8058. On a dedicated marketing subdomain every message needs it; on the transactional one, a sign-in code does not.

Set it up and check it

1. Write the root DMARC record, with the sp= you want for subdomains, in the DMARC record generator.
2. Add each subdomain at your provider and publish the records it gives you, then run each one through the deliverability checker.
3. Warm each new subdomain before sending at full volume. The ramp and the numbers to watch are in how to warm up a new sending domain.
4. Once reports arrive, read them in the DMARC report reader to confirm each subdomain passes.