Sending Subdomain Setup: Isolate Reputation and Protect Transactional Mail

Most teams send every kind of email from one domain until something breaks. Then a marketing campaign gets filtered, and suddenly password resets stop arriving too — because both were sent as yourdomain.com and both share the same reputation.

A sending subdomain fixes that by giving each class of mail its own identity: its own SPF record, its own DKIM key, and its own reputation at every mailbox provider. This guide covers why that matters, how reputation actually attaches to a name, which DNS records each subdomain needs, and the mistakes that quietly break the isolation you paid for.

Why One Domain for Everything Is a Risk

Reputation is a record of past behaviour. Receiving servers keep it per sending IP, per domain, and per subdomain, then weight it when deciding whether to accept, filter, or reject a message. That weighting is not symmetric: bad history spreads faster than good history, and a domain that has recently produced complaints will have its next message scrutinised harder regardless of what it contains.

When transactional and marketing mail share a domain, they share that scrutiny. A campaign sent to an old purchased list produces complaints, and the next password reset — a message the recipient explicitly asked for — inherits the damage. It is a single point of failure placed under the traffic you control least.

Separating them gives you three things:

• Blast radius. A mistake in a campaign affects only the marketing subdomain. Account security mail keeps flowing.
• Independent controls. You can pause, throttle, or fully re-warm one subdomain without touching the other.
• Cleaner diagnostics. If deliverability drops, you know which stream caused it, because the streams do not share a name.

There is a fourth, less obvious benefit: receivers increasingly evaluate subdomains separately when applying DMARC and when deciding how much to trust a sender. A domain with a long, clean transactional history does not automatically vouch for a brand-new promotional subdomain — and that is exactly the isolation you want.

How Reputation Attaches to a Name

Three different names appear in a message, and they do not all carry reputation the same way:

Field	What it contains	Reputation effect
From: header	The address the recipient sees	The primary reputation signal at most providers
DKIM d= tag	The signing domain	Reputation and DMARC alignment both depend on it
Return-Path / MAIL FROM	The envelope sender used for SPF and bounces	Reputation for bounces and SPF alignment

For DMARC, alignment is judged against the organizational domain — the registrable domain, so mail.example.com aligns with example.com under relaxed alignment. That means you do not need a separate registered domain to isolate streams; a subdomain is enough, and it keeps a single DMARC record and a single policy at the top.

The practical rule: send each stream from its own subdomain in the From: header, sign with a DKIM key scoped to that subdomain, and let DMARC at the organizational domain cover all of them.

Choosing a Naming Scheme

Pick names that describe the stream, and pick them once. Renaming later means re-warming from zero.

Subdomain	Use
mail.example.com	Transactional: password resets, receipts, security alerts
news.example.com	Marketing and newsletters
bounce.example.com	Return-Path for bounces (often configured by the provider)
t.example.com	Short transactional alias, if your provider requires one
em.example.com	Third-party ESP that insists on its own sending domain

Avoid names tied to a vendor or a campaign, and avoid numeric sequences like mkt1, mkt2. If you outgrow one subdomain you want to add capacity, not start over with a new identity and a new reputation.

The DNS Records Each Subdomain Needs

A subdomain is not automatically covered by the parent's records. SPF does not inherit downward, DKIM keys are per-selector and per-domain, and DMARC is published once at the organizational domain. Here is the complete set for mail.example.com:

; SPF for the subdomain — authorises the sending infrastructure
mail.example.com.            IN TXT  "v=spf1 include:mail.rovela.dev -all"

; DKIM — selector published at <selector>._domainkey.<subdomain>
rovela._domainkey.mail.example.com.  IN TXT  "v=DKIM1; k=rsa; p=<public key>"

; Return-Path / bounce domain
bounce.mail.example.com.     IN MX   10 feedback-smtp.rovela.dev
bounce.mail.example.com.     IN TXT  "v=spf1 include:mail.rovela.dev -all"

; DMARC — one record at the organizational domain covers every subdomain
_dmarc.example.com.          IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Four details in that block are easy to get wrong.

The SPF record must live on the subdomain itself. A v=spf1 record at example.com says nothing about mail.example.com. Each sending subdomain needs its own.

The DKIM key must be published under the subdomain you sign with. If the d= tag says mail.example.com, the key is looked up at rovela._domainkey.mail.example.com. A key published only at the root will not verify.

The bounce domain needs an MX record if you want to receive bounce messages rather than only webhook events. Some providers host this for you; if they do, point the MX at their host and stop.

DMARC stays at the root. Publish one record at _dmarc.example.com. If you later publish a subdomain-specific _dmarc record, it overrides the organizational policy for that subdomain — which is occasionally useful, and frequently the cause of a policy you did not intend.

For the record syntax itself, see the SPF setup guide and the DMARC guide. For how the three mechanisms fit together, the authentication overview is the place to start.

Delegation vs. Records at the Root Zone

There are two ways to manage a subdomain's DNS: publish the records in the parent zone, or delegate the subdomain to a different nameserver with an NS record.

Records at the root zone is simpler and is what most teams should do. You add TXT and MX records for mail.example.com alongside the existing records for example.com, all in one place. One dashboard, one audit trail.

Delegation is worth it when a different team or vendor manages the subdomain, or when the provider requires you to point NS at their nameservers. The catch is that whoever controls those nameservers can change SPF and DKIM for that subdomain, and your root-zone tooling will not show it. Delegation is also the only way to give a vendor control without handing them the whole zone.

Do not delegate the organizational domain itself, and do not delegate a subdomain you also publish records for — the delegation wins and your root-zone records silently become dead entries.

What Not to Do

Do not CNAME the sending subdomain to the provider's host. A CNAME on mail.example.com makes it resolve to the provider's server, but it does not transfer your SPF or DKIM records, and it creates a name that behaves unexpectedly for anything else that queries it. Publish the records explicitly instead.

Do not put include: for every provider on every subdomain. Each subdomain should authorise only the infrastructure that sends its mail. A marketing subdomain that also lists your transactional provider is authorising a sender that will never use it.

Do not use a wildcard SPF record. * IN TXT "v=spf1 ..." is not valid SPF and does not do what people hope; receivers query the exact name.

Do not skip DMARC alignment checks. With relaxed alignment (the default), mail.example.com aligns with example.com, so you do not need a separate policy. With strict alignment (adkim=s, aspf=s), the domains must match exactly, and every subdomain needs its own DMARC record. Most teams want relaxed alignment precisely because it lets subdomains share one policy.

Do not forget the subdomain in your SPF lookup budget. Every include on every subdomain counts against that subdomain's ten-lookup limit, not a global one — but a record that is already near the limit at the root will be near it here too if you copy it.

Test Before You Send

Before the first real message from a new subdomain:

1. Query the records: dig TXT mail.example.com +short, dig TXT rovela._domainkey.mail.example.com +short, dig TXT _dmarc.example.com +short.
2. Send a test message to check-auth2@verifier.port25.com and confirm SPF, DKIM and DMARC all pass, and that the DKIM domain is the subdomain you expect.
3. Check the From: header of the delivered message, not just the code that sent it. A display name can hide the real address.
4. Send to a Gmail and an Outlook address and inspect the authentication results in the message source.

If DMARC reports show the subdomain failing alignment while SPF and DKIM both pass, the usual cause is that the From: domain and the DKIM d= domain are different subdomains. Fix the signing domain rather than loosening the policy.

A Subdomain Is a New Sender

The isolation only works if you treat the new subdomain as a new sender. It has no history, so it needs the same care as a brand-new domain: start with engaged recipients, ramp the volume, and watch complaints and deferrals. The warm-up guide covers the schedule; the short version is that a subdomain spun up at full volume on day one is filtered just as readily as a new domain would be.

The payoff is worth the setup. Once each stream has its own name and its own history, a bad campaign costs you a marketing list, not your login emails — and that is the difference between an inconvenience and an outage.