Why teams use a subdomain
Mailbox providers track reputation for the domain that authenticates the mail. If your transactional and marketing email share one domain, a bad campaign affects both. Splitting them - for example notify.example.com for app email and news.example.com for marketing - lets each build its own record, and keeps your people's day-to-day mail on example.com out of it entirely.
| Typical sender | |
|---|---|
| Receipts, password resets, alerts | notify.example.com or mail.example.com |
| Newsletters and campaigns | news.example.com or marketing.example.com |
| Your team's own mailboxes | example.com |
How SPF, DKIM and DMARC work on a subdomain
- SPF: publish a TXT record on the subdomain itself. The parent domain's SPF record does not cover it.
- DKIM: the key lives at
selector._domainkey.notify.example.com, and messages are signed withd=notify.example.com. - DMARC: if the subdomain has no record of its own, the parent's
_dmarc.example.comapplies, using itssp=tag if it has one. With relaxed alignment (the default), a DKIM signature for the subdomain aligns with a From address on the subdomain or the parent.
The SPF vs DKIM vs DMARC guide shows the records, and the email DNS checker reads them back.
The trade-offs
- A new subdomain has no history, so start with low volumes of mail people expect.
- Recipients see the subdomain in the From address; choose a name that obviously belongs to you.
- Replies go wherever Reply-To points, so set it to an address someone reads.