Split your sending domains before you need to
Mailbox providers score reputation at the domain level. If your campaigns and your password resets share a domain, one bad send takes both down. Here is how to split them, why a subdomain does not inherit the root's standing, and what AWS recommends for MAIL FROM.
There is one piece of email setup that costs nothing on day one and is expensive to retrofit on day four hundred: deciding which domain sends what.
Almost everyone starts by sending everything from the root domain. Receipts, password resets, the monthly newsletter, the launch announcement — all from example.com. It works, right up until a campaign goes badly and your password resets stop arriving.
This guide is about avoiding that, and about the details people get wrong when they try.
Why the split matters
Mailbox providers score reputation largely at the domain level, not per message and not per campaign. Gmail and Outlook are building a picture of example.com as a sender: how often people open, how often they complain, how many addresses bounce.
That picture is shared by everything sending from that domain. So a marketing campaign with a stale list and a high complaint rate does not damage only your marketing. It damages your password resets, your order confirmations and your one-to-one replies, because as far as the receiving side is concerned they all come from the same sender.
The asymmetry is what makes this worth acting on. Marketing email is the risky, high-volume, occasionally-badly-targeted stuff. Transactional email is the stuff that absolutely must arrive — nobody ever sent a password reset that the recipient did not want. Letting the first put the second at risk is a bad trade, and it is entirely avoidable.
The practitioners who have been through it are blunt about it:
Use a subdomain. Separate the marketing sending profile from other kinds of email so that deliverability issues in marketing don’t affect the rest of the business.
Inbox providers score reputation mostly at the domain level, so if a campaign gets flagged the damage stays on the subdomain and your receipts and actual conversations keep landing.
The setup
A sensible split for most businesses is three-way:
| Traffic | Domain | Why |
|---|---|---|
| Personal and one-to-one mail | example.com | Your actual conversations. Should never be at risk. |
| Transactional — receipts, resets, confirmations | mail.example.com | Must arrive. Low volume, near-zero complaints. |
| Marketing — campaigns, newsletters, lifecycle | news.example.com | Higher volume, higher variance, occasional mistakes. |
If three feels like too much to start with, do two: keep the root for personal and transactional, and put marketing on a subdomain. That single split captures most of the benefit.
Do not go further than three. Every additional sending domain is another reputation you have to build and maintain from zero, and a scattering of low-volume domains is worse than a couple of well-established ones.
What the visible From address should be
Keep it recognisable. hello@news.example.com is fine and honest, but if your brand reads better as hello@example.com you have another option: send from a friendly address while the technical sending identity lives on the subdomain.
That is what the MAIL FROM setting is for, and it is worth understanding.
The part almost everyone misses
A subdomain does not inherit the root domain’s reputation.
This surprises people. You have been sending from example.com for six years with a spotless record, you create news.example.com, and you assume the good standing carries over. It does not. To a mailbox provider, news.example.com is a new sender with no history.
Two consequences:
- The subdomain needs its own SPF, DKIM and DMARC records. They are not inherited. A DMARC policy at the organisational domain does apply to subdomains by default, but the DKIM signing keys and SPF authorisation are per-domain and must be published for each.
- The subdomain needs its own warmup. Starting a new subdomain by sending 50,000 campaign emails on day one is the same mistake as starting a new domain that way — it just feels safer because the root is established.
Warm it the way you would warm anything: start with your most recently engaged contacts, in the low hundreds, and roughly double the volume every three to four days while watching bounces and complaints rather than opens. If complaints climb, stop increasing and hold until they settle.
Custom MAIL FROM, and why AWS asks for a dedicated subdomain
Every email has two sender addresses. The From header is the one your recipient sees. The MAIL FROM — also called the envelope sender or return-path — is the one mail servers use for bounce handling and for SPF alignment. By default with SES, that second address belongs to Amazon rather than to you.
Setting a custom MAIL FROM domain fixes that, and it is worth doing for two reasons: your bounces come back to your own domain, and SPF then aligns with a domain you control, which strengthens DMARC.
AWS is specific about the shape it wants:
Amazon specifically recommends that the custom MAIL FROM domain be a dedicated subdomain that is not also used to send or receive normal email.
So bounce.example.com or mail-from.news.example.com — a subdomain that exists only for this purpose. Not the root domain, and not the subdomain you already send campaigns from.
Setting it up in SES needs two DNS records: an MX record pointing at the SES inbound endpoint for your region, and a TXT record publishing SPF for that subdomain. SES will show you both and verify them for you.
The records you need, per sending domain
For each domain or subdomain you send from:
- DKIM — three CNAME records if you use SES’s easy DKIM. Non-negotiable; unsigned mail is treated as suspicious by default now.
- SPF — a TXT record authorising your sender. If you use a custom MAIL FROM, this goes on that subdomain.
- DMARC — a TXT record at
_dmarc.<domain>. Start atp=nonewith a reporting address so you can see what is happening before you enforce anything.
Start DMARC at p=none. It changes nothing about delivery and turns on the reports, which is the only way to find out that some system you had forgotten about is still sending as you. Move to p=quarantine and then p=reject once the reports are clean — which usually takes a few weeks of looking, not a few minutes.
Common mistakes
Splitting after the damage. The split protects the domain that has not been harmed yet. Moving marketing to a subdomain after your root domain’s reputation has already suffered does not repair the root — it just stops making it worse.
Too many subdomains. One marketing subdomain, well warmed and consistently used, beats five sending sporadically. Reputation is built by predictable volume.
Cold outreach on any of them. If you are doing genuine cold outreach, a subdomain is not enough separation. Use a different domain entirely and accept that you may burn it. Never put cold traffic anywhere near the domain your customers receive receipts from.
Forgetting the warmup on a “safe” subdomain. Covered above, and it is the single most common version of this mistake.
Assuming the From address is what gets scored. The authenticated domain is what matters. A friendly From address on a domain with no DKIM signature is not doing what you think it is.
How this looks in Selva Mail
Each sending domain is added and verified independently, with its own DKIM records, its own DMARC record and its own live DNS check. Senders are attached to a domain, so a marketing sender on news.example.com and a transactional sender on mail.example.com are separate identities that happen to live in the same workspace.
That means the split above is a configuration decision rather than an architectural one — you are not running two installs or paying twice to keep your campaigns away from your password resets.
DMARC aggregate reports are ingested and summarised per domain, so once you have set rua you can see which sources are sending as you and whether they pass, without setting up a separate parser.
The short version: put marketing on a subdomain, give it its own DKIM, SPF and DMARC, warm it like the new sender it is, and point MAIL FROM at a dedicated subdomain that does nothing else. It takes twenty minutes at the start and saves an incident you would otherwise spend a fortnight recovering from.
