Email is the most underestimated piece of SaaS infrastructure. It is not glamorous. Nobody launches a product and brags about their email pipeline. But when a user does not receive their password reset, when an invoice notification lands in spam, or when your onboarding sequence stops converting, email infrastructure is suddenly the most important thing in your stack.
We have built and maintained email systems for SaaS products sending hundreds of thousands of messages per month. The single most important concept to grasp early is that not all email is the same. There are three distinct categories, each with different requirements, different infrastructure, and different rules.
Transactional Email
Transactional emails are triggered by a user action and expected immediately. Password resets, email verifications, order confirmations, two factor authentication codes, receipt delivery. The user is actively waiting for these.
Deliverability is everything with transactional email. A password reset that arrives 10 minutes late or lands in spam is a support ticket. A 2FA code that does not arrive is a locked out user. These emails need to be fast, reliable, and land in the primary inbox.
The architecture for transactional email is straightforward: your application triggers an API call to a transactional email service (like Amazon SES, Postmark, or a similar provider) with the recipient, template, and variables. The service handles delivery, retries, and bounce processing.
Key architectural decisions:
- Use a dedicated sending domain for transactional email. Do not share it with marketing. If your marketing domain gets a reputation hit, it should not affect your password resets.
- Send from a subdomain like `notifications.yourdomain.com` rather than your root domain. This isolates reputation.
- Implement proper authentication: SPF, DKIM, and DMARC are mandatory. Without all three, modern email providers will deprioritize or reject your messages.
- Build a retry queue. If the email provider returns a temporary failure, retry with exponential backoff. Store failed messages in a dead letter queue for manual review.
Measure transactional email by delivery rate (should be above 99%), time to inbox (under 30 seconds for critical flows), and bounce rate (keep hard bounces under 2%).
Marketing Email
Marketing email is what most people think of when they hear "email." Newsletters, product announcements, promotional campaigns, feature launches. These are sent in bulk to segmented lists, and the user did not explicitly request this specific message.
Marketing email operates under completely different rules than transactional. CAN SPAM and GDPR compliance are non negotiable. Every marketing email must include an unsubscribe link, a physical mailing address, and must only go to recipients who have opted in. Violating these rules can result in fines and, more practically, getting your sending domain blacklisted.
The infrastructure for marketing email is typically a dedicated email marketing platform or a self managed system with list management, segmentation, template rendering, and send scheduling. The key difference from transactional is that you are managing lists and segments, not individual triggers.
Architectural considerations:
- Separate sending infrastructure entirely from transactional. Different IP addresses, different domains, different providers if possible. A marketing campaign that generates a spam complaint spike should never impact your transactional delivery.
- Implement double opt in for new subscribers. Single opt in leads to higher complaint rates and list quality problems.
- Build preference centers so users can choose which types of marketing they receive rather than unsubscribing from everything.
- Rate limit sends to avoid triggering spam filters. Sending 100,000 emails in 5 minutes looks like spam. Spreading them over 2 hours looks like normal business communication.
Measure marketing email by open rate (industry average is 20 to 25%), click through rate (2 to 5% is healthy), unsubscribe rate (keep under 0.5% per campaign), and spam complaint rate (must stay under 0.1%).
Lifecycle Email
Lifecycle email is the category most SaaS products neglect, and it is arguably the most valuable. These are automated sequences triggered by user behavior or time based conditions: onboarding drip campaigns, re engagement sequences for inactive users, trial expiration reminders, usage milestone celebrations, and churn prevention nudges.
Lifecycle email sits between transactional and marketing. It is automated like transactional but persuasive like marketing. It is personalized based on actual product usage data, not demographic segments.
The architecture for lifecycle email is the most complex because it requires real time awareness of user behavior. You need an event pipeline that captures product usage (user signed up, user created first project, user invited a teammate, user has not logged in for 7 days) and a rules engine that determines which emails to send based on those events.
Here is a typical lifecycle email architecture:
1. Event collection: Your application emits events to a message queue (like a Postgres based job queue, Redis streams, or a managed service)
2. Rules engine: A service evaluates incoming events against defined rules. "If user signed up 3 days ago AND has not completed onboarding step 2, send onboarding reminder email"
3. Template rendering: Dynamic templates that pull in user specific data, their name, what they have accomplished, what they should do next
4. Delivery: Send through your transactional email infrastructure (not marketing) because these are individual, behavior triggered messages
The rules engine is where the real engineering challenge lives. It needs to track user state across time, handle edge cases (do not send a re engagement email to someone who just logged in 5 minutes ago), and respect frequency caps (never send more than one lifecycle email per day to the same user).
Unified Email Architecture
The biggest mistake we see is building these three systems independently with no shared infrastructure. You end up with three different template systems, three different analytics pipelines, and no unified view of what a user has received.
The ideal architecture shares common infrastructure at the lower layers while separating at the routing layer. Here is what that looks like:
- Shared: Template rendering engine, analytics and tracking (opens, clicks, bounces), suppression list management, DNS configuration and domain management
- Separated: Sending domains and IPs (transactional vs marketing), trigger mechanisms (API call vs list send vs event pipeline), compliance handling (unsubscribe for marketing, not for transactional)
A unified suppression list is critical. If a user marks your marketing email as spam, you should suppress all non essential email to that address across every system. If an email hard bounces from your transactional system, your marketing system should know immediately.
Monitoring and Observability
Email infrastructure needs monitoring just like any other production system. The metrics that matter:
- Delivery rate by category: Track transactional and marketing separately. A dip in transactional delivery is an emergency. A dip in marketing delivery is a problem to investigate.
- Bounce rate trending: A sudden increase in bounces indicates a list quality problem or a reputation issue. Catch it early.
- Spam complaint rate: This is the most dangerous metric. Email providers will throttle or block your domain if complaints exceed 0.1%. Monitor this in real time.
- Queue depth: If your email queue is growing faster than it is draining, something is wrong. Set alerts.
Build dashboards that show send volume, delivery rate, bounce rate, and complaint rate per sending domain, per email category, over time. When something goes wrong, and it will, you need to diagnose quickly.
DNS and Authentication Setup
Regardless of which email categories you are sending, the DNS foundation is the same and must be configured correctly:
- SPF records: Authorize which servers can send email on behalf of your domain
- DKIM signing: Cryptographically sign your emails so recipients can verify they have not been tampered with
- DMARC policy: Tell receiving servers what to do with messages that fail SPF or DKIM checks. Start with a monitoring policy (p=none), then move to quarantine, then reject as your confidence grows
Each sending subdomain needs its own set of these records. If you are running `mail.yourdomain.com` for transactional and `news.yourdomain.com` for marketing, each gets independent SPF, DKIM, and DMARC configuration.
Scaling Considerations
As your SaaS grows, email volume grows with it. A product with 10,000 users might send 50,000 transactional emails and 10,000 marketing emails per month. At 100,000 users, those numbers jump to 500,000 and 100,000. At a million users, you are looking at millions of emails per month.
The cloud infrastructure decisions you make early determine how painful this scaling is. Design your email pipeline with queues from day one. Never send email synchronously in a request handler. Always enqueue the message and let a background worker handle delivery. This keeps your API fast and gives you a natural buffer for handling spikes.
Building email infrastructure the right way is not a weekend project. It requires understanding deliverability, compliance, and distributed systems. But it is one of the highest leverage investments in your SaaS because every user interaction, from signup to payment to churn prevention, flows through email. If your SaaS product needs reliable email infrastructure that scales, let us talk.