Email Infrastructure for SaaS: What You Actually Need
SaaS email infrastructure is DNS, a transactional send API, and logs—not a marketing suite. The minimum that works, plus a short provider list.
4 min readJordan Hale
SaaS email infrastructure is not “pick an ESP with the longest feature list.” It’s a pipeline: authenticate a domain, send from your app over HTTPS, observe failures, and keep marketing reputation away from password resets.
Most teams overbuy. This article is the minimum that works — then a short provider shortlist as layers on top of that minimum.
The pipeline (what you actually need)
[App event] → [Your backend] → [Transactional provider] → [Inbox]
| |
v v
secrets + tokens logs + webhooks
|
v
DNS: SPF + DKIM (+ DMARC)
| Layer | Must-have | Nice-to-have later |
|---|---|---|
| DNS | SPF + DKIM on a domain you control | DMARC with reporting |
| Send path | HTTPS API, key only on server | Queues / retries for spikes |
| Content | HTML or text you own | Your own preview/CI for templates |
| Observability | Per-message logs | Webhooks → Slack/Discord/DB |
| Reputation | Transactional-only sending | Dedicated IP (high volume) |
| Suppressions | Stop emailing hard bounces | Automated complaint handling |
You do not need in year one: visual template studios, audience segmentation, A/B campaign tools, or an MCP server wrapping one HTTP call.
Deeper diagram for Notify’s path: Email pipeline.
Must-haves vs nice-to-haves
Must-haves
- Verified domain — production
fromwithout SPF/DKIM is spam practice - Server-side send — browsers must never hold the API key
- Transactional provider — resets, receipts, verify links
- A way to see what happened — dashboard logs at minimum
- Bounce awareness — eventually webhooks + suppressions
Nice-to-haves (buy with evidence)
- Multiple domains / brands
- Permanent log retention
- Multiple webhook endpoints
- Dedicated IPs
- Inbound email parsing
If you don’t have bounce tickets yet, don’t buy an enterprise suite “just in case.”
Provider shortlist (as layers)
Thin managed API — Notify
Role: App → HTTPS → delivery, with logs/webhooks and flat pricing.
Choose when: You want password resets, magic links, onboarding, and receipts without ESP sprawl. Pricing: Free $0 / 1,000 · Pro $10 / 10,000 · Scale $50 / 100,000 (pricing).
await fetch('https://notify.cx/api/email/send', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'x-api-key': process.env.NOTIFY_API_KEY
},
body: JSON.stringify({
from: 'noreply@your-verified-domain.com',
to: user.email,
subject: 'Reset your password',
message: html
})
});
Not when: You need a marketing cloud, or Postmark-grade deliverability branding for a risk committee, or SES unit economics at millions/mo.
Start: notify.cx · Quick start · Password resets
DX / template ecosystem — Resend
Role: Same transactional job with a broader developer ecosystem (React Email mindshare, polished docs).
Choose when: That ecosystem is the product for your team. Compare: Notify vs Resend.
Deliverability premium — Postmark
Role: Transactional specialist with a long reputation narrative.
Choose when: A missed OTP is an incident. Pay more; get the brand and ops maturity. Compare: Notify vs Postmark.
Raw infrastructure — Amazon SES
Role: Cheapest credible send at scale — you assemble the rest.
Choose when: AWS-native + SRE bandwidth + production access already approved. New accounts often wait in sandbox; that wait kills startups. Notify vs SES.
Incumbent suites — SendGrid / Mailgun
Role: Huge feature matrices; marketing + transactional under one roof.
Choose when: You’re already locked in or you truly need the suite. Wrong default for “we needed a reset email.” Lightweight exits: vs SendGrid · vs Mailgun.
Anti-patterns
SMTP from the app server
Works on localhost. Dies behind blocked port 25, shared IP hell, and no bounce pipeline. Use a provider’s API (or their SMTP relay as a conscious choice — not raw VPS SMTP).
Mixing marketing and transactional reputation
One blast to a purchased list can poison the domain that sends password resets. Separate domains/subdomains and products. Transactional APIs that refuse newsletter gravity help you stay honest.
Building SES glue too early
CloudWatch + SNS + IAM + suppression tables before your first paying customer is anxiety, not infrastructure. Start with a thin managed layer; move down-stack when volume makes margins hurt and you can staff ops.
Owning content in the ESP
If the vendor’s template studio becomes your CMS, migration gets expensive. Prefer HTML you generate in-app (or with your AI) and a dumb delivery pipe.
Decision tree
| Situation | Layer |
|---|---|
| Greenfield SaaS, resets + receipts | Thin API (Notify) |
| Team wants React Email ecosystem | Resend |
| Lost email = support incident budget | Postmark |
| 1M+/mo, AWS SRE team | SES |
| Already on SendGrid, migration cost > savings | Stay, then revisit |
Trial checklist (any provider)
- Time to first delivered message including DNS
- Find one message’s full timeline in logs
- Send to an invalid address — how fast do you learn?
- Webhook arrives for bounce/delivery within a minute
- Real monthly cost at your volume
Bottom line
SaaS email infrastructure is DNS + a transactional send API + observability. Everything else is optional.
Notify is the thin managed layer for teams who already own their HTML and want flat Pro pricing without a suite. Start there unless your job is deliverability premium, AWS unit cost, or an ecosystem you already love.
Resources
More in software-development
Venture
Write for entrepreneurs, founders, and builders.
Share startup lessons, growth tactics, and founder stories with readers on the same journey.
One free account across In Plain English, Stackademic, Venture, and Cubed.
How it works- Startups & entrepreneurship
- Marketing & growth
- Productivity & leadership
- Founder stories & lessons learned
Sign in
Google or GitHub
Complete profile
Takes a few minutes
Get approved & publish
Start sharing
Why write for Venture?
Entrepreneurship is rarely a straight path. The lessons worth sharing are learned while building.
Comments
Loading comments…