SaaS companies send two fundamentally different types of email that require separate infrastructure treatment: transactional email triggered by user actions (signup confirmations, password resets, billing notifications, 2FA codes) and marketing email sent in batches to user segments. When these streams share the same IP pool and domain, a spike in marketing complaints contaminates transactional reputation — and suddenly your password reset emails are landing in spam at the exact moment a user is locked out of their account.
| Email type | Priority | Separate IP needed? | Key delivery risk | Max acceptable bounce |
|---|---|---|---|---|
| 2FA / login codes | Critical — < 1s | Yes | Spam folder = user locked out | 0.1% |
| Password resets | Critical — < 2s | Yes | Delay = user churn | 0.1% |
| Order confirmations | High — < 5min | Recommended | Spam folder = support tickets | 0.5% |
| Shipping notifications | Medium — < 1h | Optional | Delays tolerated if rare | 1% |
| Account notifications | Medium — < 1h | Optional | Mixed with marketing rep risk | 1% |
| Weekly digest / summary | Low — best-effort | No — use shared | ISP throttling expected | 2% |
This guide covers the infrastructure architecture for SaaS transactional email: stream isolation, authentication requirements, delivery performance targets, and the monitoring setup that catches problems before they become user-facing incidents.
Transactional vs Marketing: The Infrastructure Separation Imperative
Transactional email and marketing email have completely different deliverability profiles:
| Dimension | Transactional | Marketing |
|---|---|---|
| Complaint rate | Near-zero (0.00–0.02%) | 0.05–0.5%+ depending on practices |
| Open rates | 60–80% (expected, needed) | 20–40% typical |
| Delivery speed requirement | Seconds matter (password reset, 2FA) | Minutes to hours acceptable |
| Recipient relationship | Opted in by account creation | Opted in to marketing specifically |
| ISP trust level | Very high — recipients want it | Moderate — some recipients tune out |
Mixing these streams on the same IP means the complaint rate that ISPs see is a weighted average of both streams. Marketing complaints arrive on the same sending IP and domain that your 2FA codes use. At Gmail, where domain reputation is tracked cumulatively, marketing campaign performance affects whether transactional mail hits the inbox.
The infrastructure solution: dedicated IPs and sending subdomains for each stream.
Stream isolation architecture
- Transactional email: sends from
tx.yourdomain.comormail.yourdomain.com, dedicated IP(s), managed through a transactional ESP like Postmark or AWS SES Transactional stream - Marketing email: sends from
marketing.yourdomain.comornews.yourdomain.com, separate IPs, managed through a marketing ESP like SendGrid Marketing Campaigns or Mailchimp - Product notifications: Optionally a third stream from
notify.yourdomain.comfor feature announcements and product updates
Each stream accumulates its own reputation independently. Marketing complaints don't affect transactional delivery. A transactional incident (an accidental spam trigger from a specific type of automated email) doesn't penalise your marketing campaigns.
Critical Transactional Email Types and Delivery Requirements
Not all transactional email has the same urgency. Categorise by delivery time requirement to inform infrastructure and monitoring choices:
Transactional Email Delivery Latency — ESP Comparison (median, seconds)
Received: from smtp.yourapp.com (smtp.yourapp.com [52.x.x.x]) by mx.google.com with ESMTPS id zz for <user@gmail.com>; Mon, 07 Apr 2025 14:22:03.421 +0000 (UTC) # Total delivery time from queue to Gmail MX: 0.7 seconds Authentication-Results: mx.google.com; dkim=pass header.i=@yourapp.com header.s=transact2025; spf=pass smtp.mailfrom=noreply@yourapp.com; dmarc=pass (p=REJECT) header.from=yourapp.com; Precedence: transactional X-Mailer: yourapp-transactional/2.1 # Precedence: transactional signals ISPs this is not bulk
Tier 1: Time-critical (must deliver in seconds)
- Two-factor authentication (TOTP codes, magic links) — codes typically expire in 5–10 minutes
- Password reset emails — users are locked out; delays cause support tickets immediately
- Email address verification on signup — users can't proceed until verified; delays abandon signups
- Payment confirmation — users expect immediate confirmation after a purchase
Delivery SLA target: 95th percentile delivery under 30 seconds from trigger. This requires an ESP with dedicated queuing priority for transactional mail, no shared queues with marketing batches, and a monitoring alert if p95 delivery time exceeds 60 seconds.
Tier 2: Important but minutes acceptable
- Invoice generation and billing notifications
- Account security alerts (new login from unrecognised device)
- Subscription renewal notifications
- Service degradation or incident notifications
Tier 3: Informational (hours acceptable)
- Weekly digest or usage summaries
- Feature announcement emails triggered by product usage events
- Inactivity re-engagement triggered by user inactivity (grey area with marketing)
Authentication for SaaS Transactional Email
Transactional email from SaaS must pass full authentication. The 2024–2025 Gmail and Microsoft bulk sender enforcement requirements apply to any domain sending 5,000+ messages/day, which most growth-stage SaaS companies hit.
SPF for transactional subdomains
# SPF record for tx.yourdomain.com
# Using AWS SES for transactional sending
v=spf1 include:amazonses.com -all
# Or using Postmark
v=spf1 include:spf.mtasv.net -all
# Or using SendGrid transactional stream
v=spf1 include:sendgrid.net -allDKIM for transactional subdomains
Each transactional ESP provides a DKIM CNAME or TXT record to publish at your sending subdomain. For DKIM alignment, the DKIM signing domain must align with your From: header domain:
# From header: noreply@yourdomain.com
# DKIM d= must be: yourdomain.com (exact match) or a parent domain
# For sending subdomains (tx.yourdomain.com):
# If using Postmark custom domain: publish Postmark's CNAME at:
# pm._domainkey.tx.yourdomain.com
# DKIM signature d= value: tx.yourdomain.com (or yourdomain.com)
# From: header domain: tx.yourdomain.com or yourdomain.com
# These must match under relaxed DKIM alignmentDMARC for transactional subdomains
# If tx.yourdomain.com is a subdomain, it inherits the root domain DMARC policy
# Unless you publish a separate record at _dmarc.tx.yourdomain.com
# Root domain DMARC (applies to subdomains without their own record)
# _dmarc.yourdomain.com
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@yourdomain.com
# Or publish subdomain-specific policy
# _dmarc.tx.yourdomain.com
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.comFrom Address Design for Transactional Email
The From: address in transactional email has both deliverability and user experience implications:
Reply-to vs From for no-reply addresses
Using noreply@yourdomain.com as the From: address is technically clean but creates a deliverability signal: recipients can't reply, and some ISPs treat no-reply senders more conservatively. Alternatives:
hello@yourdomain.com— friendly name, recipients can reply for supportteam@yourdomain.com— sends to a shared inbox your support team monitorsnoreply@yourdomain.comwith a visibleReply-To: support@yourdomain.com— functional no-reply with a clear escalation path
From name consistency
Use a consistent From name that recipients will recognise: "YourApp" or "YourApp Team" rather than a person's name for system-generated email. Consistent From names build recognition and reduce complaints from recipients who don't recognise the sender.
ESP Selection for SaaS Transactional Email
| ESP | Pricing (100K/mo) | Key feature | Best for |
|---|---|---|---|
| Postmark | ~$74/mo | Transactional-only policy, fastest delivery, Message Streams | Time-critical 2FA, password reset where speed is paramount |
| AWS SES | ~$10/mo | Lowest cost, Configuration Sets for stream separation | High-volume SaaS at cost-sensitive growth stage |
| SendGrid | ~$34.95/mo | Separate API products for transactional vs marketing | SaaS scaling into marketing; unified API |
| Mailgun | ~$200/mo (2025 pricing) | Routing rules, inbound email processing | Complex routing needs, bidirectional email flows |
Monitoring Transactional Email Delivery
The metrics that matter
- Delivery latency (p95 and p99): Time from event trigger to successful SMTP delivery. Alert at p95 > 30 seconds for Tier 1 email types.
- Bounce rate by type: Hard bounces should be suppressed automatically. Hard bounce rate above 0.5% on transactional email indicates a list quality or user data integrity problem (users entering fake email addresses).
- Complaint rate: Should be near-zero for genuinely transactional email. Any spike above 0.05% warrants investigation — either a transactional email is being miscategorised as marketing, or the volume type has shifted.
- Open rate for Tier 1: Password reset and 2FA open rates in the 50–70% range are healthy. Drops below 40% may indicate spam folder placement — users can't find or act on the email they need.
Alerting setup
Critical alerts for transactional email operations:
- Delivery queue depth exceeds 1,000 messages (infrastructure overload or block)
- p95 delivery latency exceeds 60 seconds for any Tier 1 template
- Authentication failure rate exceeds 0.1% (DKIM or SPF configuration issue)
- Hard bounce rate exceeds 1% in any 24-hour period (list quality issue)
- Any blacklist listing for transactional sending IPs (immediate escalation)
Common Transactional Email Failure Patterns and Fixes
Password resets going to spam at Gmail
Root causes: domain reputation damage from marketing stream on the same domain (solution: stream isolation), authentication misconfiguration (check headers), or too many failed password reset requests being generated triggering spam signals.
2FA codes delayed by minutes
Root causes: ESP queue congestion from marketing batch sends sharing the queue (solution: dedicated transactional queue or separate ESP), transient ISP throttling (monitor for 421 errors in delivery logs), or DNS resolution slowdowns.
Signup verification emails bouncing
Root causes: users entering invalid email addresses during signup (implement real-time email validation at the form level), or disposable email addresses that expire before verification (consider allowing only non-disposable domains).
