Your app sends two very different kinds of email: the password reset that must arrive in seconds, and the promotional newsletter that's nice to deliver. They feel like the same thing — both are "email your app sends" — so teams route them through the same infrastructure. That's a quiet mistake that can break both.
Transactional and marketing email have nearly opposite requirements, and mixing them puts your most critical messages at risk. Here's why separation matters.
Transactional email (password resets, receipts, alerts) and marketing email (newsletters, promotions) should use separate sending infrastructure — ideally separate domains or subdomains.
Why:
Separate them, and a bad marketing campaign can't take down your password resets.
Photo by Brett Jordan on Unsplash
The two categories look similar but have fundamentally different jobs:
| Transactional | Marketing | |
|---|---|---|
| Trigger | User action (reset, purchase) | Campaign / schedule |
| Criticality | Must arrive, fast | Nice to arrive |
| Recipient expectation | Expected, wanted | Often unsolicited |
| Spam complaint risk | Very low | Higher |
| Volume pattern | Steady, 1:1 | Bursty, bulk |
Transactional email is expected, wanted, and critical — the user just asked for it and is waiting. Marketing email is bulk, often unsolicited, and inherently draws more complaints and unsubscribes. These opposite profiles are exactly why sharing infrastructure is dangerous: the risky category can poison the critical one.
Here's the core danger. Deliverability depends heavily on domain reputation, and reputation is shared across all mail from a domain. Marketing email naturally accumulates spam complaints — some recipients always mark promotions as spam, no matter how clean your list. Those complaints damage the sending domain's reputation.
If your transactional mail shares that domain, it inherits the damaged reputation. Now your password resets and receipts — the messages that absolutely must arrive — start landing in spam because of complaints generated by your newsletter. The critical email pays for the marketing email's sins. Separation breaks this contamination: a marketing reputation problem stays contained to marketing, leaving transactional deliverability untouched.
The fix is to isolate the two streams so their reputations don't mix:
The principle is simple: your transactional reputation is precious and must be shielded from the higher-risk marketing stream. Isolate them so problems in one can't bleed into the other.
Of the two, transactional email deserves the fiercest protection because the cost of failure is immediate and severe. A marketing email that lands in spam is a missed opportunity. A password reset that lands in spam is a user locked out of their account, a support ticket, and an erosion of trust in your product. One is annoying; the other is a broken core experience.
That asymmetry is the whole argument for separation. You're protecting the email people depend on from the email people merely tolerate. By keeping marketing's reputation risk away from transactional infrastructure, you ensure the messages that matter most always arrive — regardless of how any given marketing campaign performs. This is foundational email infrastructure hygiene that pays off precisely when something goes wrong.
Q: Isn't separate infrastructure more complex to maintain? Slightly, but the protection is worth it — the alternative is letting a bad marketing campaign drag your password resets into spam. At minimum, separate subdomains keep reputations distinct with modest added complexity. The small operational overhead buys you insurance on your most critical messages, which is a trade almost always worth making.
Q: What's the minimum separation I need? Separate subdomains for transactional and marketing mail is the practical minimum, since reputation can track at the subdomain level. Separate domains or providers give stronger isolation. The non-negotiable rule is never sending bulk marketing from the same domain your transactional mail depends on — that's what exposes critical email to marketing's complaint risk.
Q: Why does marketing email generate more complaints? Because it's bulk and often unsolicited or only loosely wanted — some recipients will always mark promotions as spam regardless of how clean your list is. Transactional email, by contrast, is expected and wanted, so it draws far fewer complaints. That structural difference in complaint rates is exactly why their reputations must be kept apart.
Transactional and marketing email have opposite requirements — one is critical and expected, the other optional and complaint-prone — yet teams routinely send both through shared infrastructure. The danger is contamination: marketing's spam complaints damage a shared domain's reputation and drag your password resets and receipts into spam along with the newsletter.
Separate the streams — subdomains at minimum, separate domains or providers for stronger isolation — and authenticate both properly. Your transactional email is what users depend on; shield it from the higher-risk marketing stream so the messages that matter most always arrive, no matter how a campaign performs.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.

I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.

I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.

Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!