KoltrixSeparate subdomains for transactional and marketing mail
Splitting streams across subdomains contains reputation damage. How to structure them, align SPF and DKIM per subdomain, and what it cannot protect.
On this page(7 sections)
If your newsletter has a bad month, should your password reset emails suffer for it? With everything sent from one domain, they might.
Putting different mail streams on different subdomains is one of the cheapest ways to keep a reputation problem in one stream from spreading to the others.
Why streams should be separated
Receivers build reputation for the domains they can authenticate. If marketing campaigns, product notifications and account security emails all use example.com as the From and DKIM domain, they share one reputation. A campaign that generates complaints lowers that shared score, and the next password reset is judged partly on it.
Mail streams behave very differently:
| Stream | Typical engagement | Complaint risk | Cost of a delay |
|---|---|---|---|
| Security and account (resets, verification codes) | Very high | Very low | Severe |
| Transactional (receipts, alerts) | High | Low | High |
| Product notifications (mentions, digests) | Medium | Medium | Medium |
| Marketing (newsletters, promotions) | Lower | Higher | Low |
Separating them lets each stream build a reputation that matches its own behavior.
A practical structure
A common layout for a SaaS company:
example.com staff mailboxes (people)
mail.example.com transactional and security mail from the app
notify.example.com product notifications and digests
news.example.com marketing and newslettersNames vary. What matters is that each stream has its own subdomain and that the mapping is documented and enforced in code, so a developer cannot send a promotional email from the transactional subdomain because it happened to be configured.
Some teams use the root domain for transactional mail, since recipients recognize it best, and put only marketing on a subdomain. That works too. The key is that the highest-risk stream is isolated from the most critical one.
Configuring authentication per subdomain
Each subdomain needs its own records. For news.example.com:
SPF
SPF is evaluated against the envelope sender, so configure a bounce subdomain for the stream and give it a record:
bounce.news.example.com. TXT "v=spf1 include:spf.marketing-provider.example -all"If the provider uses its own bounce domain, SPF will not align, and DMARC will rely on DKIM. That is acceptable as long as DKIM aligns.
DKIM
Sign with the subdomain itself, using a selector the provider gives you:
mk1._domainkey.news.example.com. CNAME mk1.dkim.marketing-provider.example.Signing with d=news.example.com gives the stream its own reputation at receivers that track domains at that granularity. Signing marketing mail with d=example.com would undo much of the separation.
DMARC
Subdomains inherit the parent's policy through the sp tag unless they have their own record. You can rely on inheritance, or publish a record per stream to get separate aggregate reports and independent policies:
_dmarc.news.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"With relaxed alignment, the default, bounce.news.example.com and news.example.com both align with a From address at news.example.com.
MX and replies
Give each sending subdomain somewhere for replies and bounces to go. Replies to newsletters should reach a monitored mailbox; bounces should reach your provider's bounce processor.
What subdomains do and do not protect
They help with
- Containing complaint-driven damage. A marketing campaign with high complaints hurts
news.example.commore thanmail.example.com. - Diagnostics. Postmaster Tools and DMARC reports become per-stream, so you can tell which stream has a problem.
- Operational clarity. Each stream maps to one provider configuration, one set of keys and one owner.
They do not fully isolate
- The organizational domain still matters. Receivers know
news.example.comandmail.example.comshare a parent. Exactly how much reputation flows between subdomains and parent is not published and varies by receiver. Treat separation as damage limitation, not a firewall. - Brand perception is shared. Recipients who are annoyed by marketing may report your transactional mail too, because it is from the same company.
- Link and content signals. If every stream links to the same domains, link reputation is shared.
- Bulk sender status. Gmail counts mail from subdomains together with the primary domain when determining whether you are a bulk sender, so splitting streams does not move you under the 5,000-a-day threshold.
The last point matters: subdomains are a reputation tool, not a way to avoid bulk sender requirements.
Common mistakes
- Mixing streams anyway. A "quick" promotional message sent through the transactional configuration contaminates the stream you most need to protect.
- Signing with the parent domain. Using
d=example.comfor every stream erases most of the separation. - Too many subdomains. Each one needs enough steady volume to build its own reputation. Five subdomains each sending a few hundred messages a week is worse than two well-used ones.
- Forgetting DMARC coverage. A subdomain with no record of its own inherits the parent's policy, which may not be what you intend during a rollout.
- Moving streams to a fresh subdomain to escape a problem. The new subdomain has no history, and the behavior that caused the problem follows it.
Rolling it out
- Inventory your current mail streams and the systems that send each one.
- Choose subdomain names and document which stream uses which.
- Configure SPF bounce domains, DKIM selectors and DMARC records for each subdomain.
- Move one stream at a time, starting with the lowest-risk move, and warm up volume on any subdomain that is new.
- Verify alignment with real messages and DMARC reports for each stream.
- Add a guard in code so each message type can only be sent with its assigned From domain.
Key takeaways
- Separate subdomains give each mail stream its own domain reputation, so marketing problems do not drag down critical transactional mail.
- Configure SPF, DKIM signing with the subdomain itself, and DMARC per stream.
- Separation limits damage but does not fully isolate; the parent domain and brand remain shared.
- Subdomains do not change bulk sender status at Gmail, which aggregates subdomains with the primary domain.
- Keep the number of subdomains small and the mapping enforced in code.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
