Transactional emails (password resets, order confirmations, receipts) should be sent from separate infrastructure — different subdomain, different IP, different ESP — than marketing email. This prevents marketing reputation damage from affecting critical transactional delivery. Transactional email should achieve 99%+ inbox placement.
Transactional Email Deliverability: Separate from Marketing
Why Separation Matters
Transactional emails — password resets, order confirmations, shipping notifications, account alerts — are the emails your users actually need. When they don't arrive, customers contact support, abandon carts, and lose trust.
Marketing emails carry inherent deliverability risk. Some recipients complain. Lists degrade. Campaigns occasionally miss the mark. If your transactional email shares infrastructure with marketing, one bad campaign can delay every password reset and order confirmation.
Separation isn't optional for serious senders. It's the foundation.
The Separation Architecture
Subdomain Strategy
| Stream | Subdomain | Purpose |
|---|---|---|
| Transactional | mail.example.com or notify.example.com | Password resets, receipts, alerts |
| Marketing | news.example.com or marketing.example.com | Campaigns, newsletters, promotions |
| Cold outreach | outreach.example.com | Sales emails (highest risk) |
Each subdomain builds its own domain reputation. Damage to one doesn't directly affect the others.
Dedicated IPs
Transactional email should send from dedicated IPs separate from marketing. On shared IPs with marketing, you inherit the reputation of every other sender — including ones running sloppy campaigns.
Separate ESPs
The strongest separation uses different ESPs entirely:
- Transactional: Postmark, Amazon SES, or SendGrid's transactional API
- Marketing: Your primary ESP (Mailgun, SendGrid marketing, etc.)
Postmark is worth calling out specifically — they only allow transactional email and reject marketing senders, which keeps their IP pools clean.
Practitioner note: I've seen SaaS companies lose password reset delivery for 48 hours because a marketing campaign hit a spam trap and blacklisted their shared IP. The fix took 3 days. Separate infrastructure would have prevented it entirely. After the incident, we split them onto Postmark for transactional and Mailgun for marketing — problem never recurred.
Authentication for Transactional Email
Authenticate every transactional subdomain independently:
- SPF record for each transactional subdomain
- DKIM signing with a unique selector per subdomain
- DMARC on the organizational domain with subdomain policy consideration
Example DNS setup for mail.example.com:
mail.example.com TXT "v=spf1 include:spf.postmarkapp.com -all"
pm._domainkey.mail.example.com CNAME [postmark-provided-value]
DMARC alignment should pass for the transactional subdomain specifically. Verify with a test email and header inspection.
Transactional Email Best Practices
Keep It Purely Transactional
Transactional emails should contain only the information the user expects:
- Order confirmation: order details, amounts, delivery estimate
- Password reset: the reset link, expiration time
- Shipping notification: tracking number, carrier, estimated delivery
Don't add "You might also like..." product recommendations. Don't include newsletter signup prompts. Don't add promotional banners. Every piece of marketing content increases the chance of spam complaints and blurs the reputation line.
Send Immediately
Transactional emails should send within seconds, not minutes. Users expect password resets instantly. Order confirmations should arrive before they close the browser tab.
Configure your transactional ESP for immediate delivery, not batched sending.
Monitor Separately
Track transactional deliverability metrics independently:
- Delivery rate: Should be 99%+
- Bounce rate: Should be under 0.5% (these are known addresses)
- Inbox placement: Test regularly with GlockApps or Mail-Tester
- Time to delivery: Monitor for delays that indicate throttling
Practitioner note: A high bounce rate on transactional email usually means your signup form doesn't validate email addresses. If someone typos their email during registration, every transactional email to that address bounces. Implement real-time email validation at signup — it's the cheapest fix for transactional deliverability.
Choosing a Transactional ESP
| Provider | Transactional Focus | Starting Price | Strengths |
|---|---|---|---|
| Postmark | Transactional only | $15/mo (10K emails) | Fastest delivery, cleanest IPs |
| Amazon SES | Both | $0.10/1K emails | Cheapest at scale |
| SendGrid | Both (API vs. marketing) | $19.95/mo (50K) | Good API, established IPs |
| Mailgun | Both | $15/mo (10K) | Flexible, good for developers |
For pure transactional delivery, Postmark is the strongest choice. Their no-marketing policy keeps IP reputation consistently high. For cost optimization at high volume, SES wins but requires more self-management.
Common Transactional Deliverability Problems
Mixed streams. Marketing and transactional on same infrastructure. Solution: separate immediately.
No authentication. Transactional subdomain missing SPF, DKIM, or DMARC. Solution: full authentication setup.
Stale addresses bouncing. Users with invalid emails generating hard bounces. Solution: validate at signup, suppress after first bounce.
Over-sending. Sending too many transactional emails per user (excessive notifications). Solution: consolidate notifications, respect frequency preferences.
Practitioner note: The most overlooked transactional deliverability issue is reply handling. If your transactional emails come from a no-reply address and someone replies, that email goes nowhere. Worse, if the no-reply address bounces the reply, some providers count that negatively. Use a monitored address and at least auto-respond to replies.
What to Do Next
If your transactional and marketing emails share infrastructure, separating them is the highest-impact change you can make. Start with a dedicated transactional subdomain and move to a transactional-focused ESP.
If you need help architecting the separation or diagnosing transactional delivery issues, schedule an infrastructure review.
Sources
- Postmark: Why Transactional Email Needs Separate Infrastructure
- M3AAWG: Best Practices for Transactional Messages
- Google: Email Sender Guidelines
- RFC 5321: Simple Mail Transfer Protocol
- CAN-SPAM Act: Transactional Message Exemptions
v1.0 · March 2026
Frequently Asked Questions
Should transactional and marketing email use the same domain?
No. Use a subdomain for transactional (e.g., mail.example.com) and a different subdomain for marketing (e.g., news.example.com). This separates reputation so a marketing deliverability problem doesn't block password resets and order confirmations.
What is a good deliverability rate for transactional email?
Transactional email should achieve 99%+ delivery and 95%+ inbox placement. If your transactional emails aren't hitting the inbox consistently, something is fundamentally wrong with your infrastructure or you're mixing marketing content into transactional sends.
Can I include marketing content in transactional emails?
Technically, but don't. Adding promotional content to order confirmations or password resets violates CAN-SPAM guidelines, risks spam complaints, and blurs the reputation line between transactional and marketing streams.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.