Transactional email — password resets, order confirmations, 2FA codes, account alerts — has a single deliverability requirement: it must reach the inbox close to 100% of the time. Users who do not receive password resets churn. Users who do not receive order confirmations dispute charges. Marketing email has a different profile: occasional spikes, broader audience, inevitable complaint events. Mixing the two on the same sending infrastructure means one bad marketing day damages the transactional stream — and there is no acceptable damage to transactional.
Run transactional and marketing on separate ESPs, separate subdomains, and separate authentication. Postmark or SES for transactional. Anything reasonable for marketing. Subdomain split: txn.yourdomain.com and mail.yourdomain.com (or similar). Independent DKIM keys, separate SPF, separate DMARC alignment. Monitor each stream independently. The architectural cost is small; the insurance value is enormous.
Why segregation matters
Mailbox providers track reputation at multiple levels: IP, domain, subdomain, and signing entity. When marketing complaints accumulate against the marketing subdomain on the marketing IP, the damage is contained. Transactional — on a different subdomain, different IP, different signing — continues to receive the high inbox rate transactional volume earns through high engagement and zero complaints.
Without segregation, all reputation accrues to one domain/IP combination. A bad marketing campaign that generates 0.5% complaints (a noticeable but not catastrophic rate for marketing) drops the shared reputation enough that password reset emails to Gmail users start landing in spam. Users do not receive their codes, support tickets spike, churn rises, and the cause is invisible from the marketing dashboard because the marketing campaign itself looked fine.
Transactional must be 99.9% inbox. Marketing optimises for engagement and tolerates filtering noise. The optimisation targets are incompatible on one infrastructure.
The subdomain split
Standard subdomain architecture for a sender at yourdomain.com:
- txn.yourdomain.com or mail.yourdomain.com: transactional only. Password resets, order confirmations, shipping notifications, account alerts, 2FA codes.
- news.yourdomain.com or email.yourdomain.com: marketing newsletters, promotional sends, lifecycle campaigns.
- notify.yourdomain.com: in-product notifications, mentions, comment alerts (treat as transactional if user-triggered, marketing if scheduled).
- yourdomain.com root: reserved for one-to-one business mail (sales conversations, support replies). Not bulk-sent.
Each subdomain is its own reputation entity at Gmail, Outlook and the rest. A reputation event on one does not spread to the others. Postmaster Tools tracks them as separate domains, which makes monitoring straightforward.
The naming convention matters less than the consistency. Pick names and stick with them; switching subdomain names mid-stream restarts reputation at the new name.
Separate ESPs
Different ESPs have different sweet spots. The match for each stream:
- Transactional: Postmark, AWS SES, Mailgun transactional plan, SparkPost transactional. These platforms specialise in low-latency, high-deliverability one-to-one messaging. Strict template controls. Per- recipient sending logs. Aggressive complaint management.
- Marketing: Klaviyo (ecommerce-heavy), Iterable, Customer.io, Braze, ActiveCampaign, Mailchimp, HubSpot. These platforms support segmentation, journeys, A/B tests and revenue attribution that transactional ESPs do not offer.
- Cold outreach (if applicable): a third stream on a third subdomain through a tool like Instantly, Smartlead or Lemlist. Cold outreach should never share infrastructure with either marketing or transactional.
Using separate ESPs is not just about isolation — each platform's feature set matches its stream. Trying to send transactional through Mailchimp introduces template- approval delays incompatible with real-time triggers. Trying to send newsletters through Postmark works technically but lacks the segmentation tools needed for scale.
Authentication per stream
Each subdomain needs its own SPF, DKIM, and DMARC alignment.
- SPF per subdomain: txn.yourdomain.com has SPF authorising the transactional ESP only. news.yourdomain.com has SPF authorising the marketing ESP only. No cross-authorisation.
- DKIM per subdomain: each ESP publishes its own DKIM keys at subdomain-scoped selectors (e.g.,pm._domainkey.txn.yourdomain.com for Postmark, k1._domainkey.news.yourdomain.com for Klaviyo). Independent keys; one compromise does not affect the other.
- DMARC per subdomain: publish DMARC at the subdomain level (_dmarc.txn.yourdomain.com and _dmarc.news.yourdomain.com ). Each subdomain's policy can differ — strict (p=reject) for transactional, monitoring or quarantine for marketing if you are still tuning.
- BIMI per subdomain: if you publish BIMI, do so at each subdomain that requires the verified logo. BIMI requires p=quarantine or p=reject DMARC at the subdomain.
The organisational DMARC at yourdomain.com root provides a fallback policy for any traffic not explicitly authorised by subdomain policies. Set it to p=quarantine after verifying no legitimate non-subdomain mail exists.
DMARC alignment matters more than you think
DMARC requires that either SPF or DKIM align with the From: domain to pass. For multi-stream setups, this means the From: address subdomain must match the DKIM signing subdomain or the SPF Return-Path subdomain. ESPs vary in how they handle this.
Postmark, SES, and Mailgun handle alignment cleanly when configured. Klaviyo and ActiveCampaign require explicit custom-domain configuration to get DKIM alignment with your subdomain instead of theirs. Mailchimp's legacy sending used to fail alignment in some configurations; their current setup is correct if you complete domain authentication.
Test alignment by sending a test message and inspecting the Authentication-Results header at the recipient. The line should read "dmarc=pass" with the d= value matching your subdomain. Anything else (relaxed alignment with the ESP's domain, or dmarc=fail with policy not applied) means the configuration is incomplete.
For most senders, Postmark is the right transactional choice. Their architecture refuses to send anything that looks marketing-like, their delivery times average under 1 second, and their per-message logs are inspectable. Above 1 million transactional sends per month, AWS SES becomes cost-effective. Below that, the time you save not debugging Postmark is worth the price.
Monitoring per stream
Each stream has different metrics that matter:
- Transactional: delivery rate (must be 99.9%+), delivery latency (must be sub-5-second median), bounce rate (under 1%), Postmaster reputation (must be High).
- Marketing: inbox vs Promotions/spam placement (target 90%+ inbox at Gmail, 80%+ at Outlook), open rates by segment, click rates, complaint rate (under 0.2%), unsubscribe rate, revenue per send.
- Cold outreach: reply rate (target 8-15% for well-targeted cold), bounce rate (under 2%), Postmaster reputation, sender-domain blacklists.
Run separate dashboards per stream. A unified deliverability dashboard that mixes transactional and marketing metrics obscures the events that matter — a transactional delivery rate dropping from 99.9% to 99.5% is an emergency, but a marketing inbox rate moving from 85% to 82% is a normal Tuesday. Mixed dashboards lose the signal.
IP considerations across ESPs
Most multi-ESP setups end up with shared IPs at each ESP — Postmark's IP pool for transactional, the marketing ESP's pool for marketing. This is fine. Postmark's pool reputation is consistently strong because their customer base is uniformly transactional. Marketing ESPs' pools vary; that variance is part of why isolation matters.
Above ~500,000 marketing sends per month, dedicated IP on the marketing ESP becomes worth considering. Below that, stay on shared. Transactional senders almost never need dedicated IP regardless of volume — Postmark's and SES's pools are managed for transactional deliverability and dedicated IP introduces warmup complexity without benefit.
Migrating from single-ESP to multi-ESP
If you are currently sending everything through one ESP, the migration to a multi-ESP setup is essentially two migrations: stand up the new transactional ESP at a new subdomain, then optionally move marketing to a new marketing ESP at a different subdomain. Each follows the 4-week dual-send pattern from any ESP migration.
Order matters. Migrate transactional first. Until transactional is on its own infrastructure, you remain exposed to marketing-event damage on the transactional stream. Once transactional is isolated, marketing migration can happen on a more relaxed timeline because the failure mode is bounded.