AWS SES Email Stack for SaaS Builders
How to think about Amazon SES as part of a SaaS email stack: what SES is and isn't, the layers you build on top of it, the sandbox/SNS setup, and where it fits versus a full API.
Overview
Amazon SES is the cheapest, most scalable way to actually deliver email at volume — but it's deliberately just the delivery engine, not a complete email tool. SaaS builders who treat SES as a finished product get frustrated; those who treat it as the bottom layer of a stack get reliable, near-free sending. This guide is about what SES gives you, what you have to build on top, and when it's the right base.
What SES is — and isn't
SES is a raw sending API/SMTP with excellent deliverability and pricing measured in fractions of a cent per email. What it is not: a dashboard for non-developers, a template editor, a contact/list manager, a campaign tool, or a reply inbox. It gives you sending and event notifications (via SNS), and expects you to build or buy everything else. That's why "using SES" really means "building a stack on SES."
Two setup steps trip everyone up: exiting the sandbox (new SES accounts can only send to verified addresses until you request production access, explaining your bounce/complaint handling), and wiring SNS so bounces and complaints flow back into suppression. Skip the second and your reputation erodes silently.
- SES = raw delivery API/SMTP, near-cost pricing, great deliverability
- Not: dashboard, templates, lists, campaigns, reply inbox
- Exit the sandbox (request production access)
- Wire SNS bounce/complaint → suppression
The layers you build on SES
On top of SES you add: a sending app for an API/dashboard/key management (useSend is the open-source choice, or a hosted API), domain authentication, and a workflow layer for campaigns, replies, and analytics. The common pattern is useSend-on-SES for a Resend-style developer experience with near-cost delivery, then a workflow layer on top.
Use SES as your base when you want the lowest delivery cost at scale and are comfortable building (or assembling) the layers above it. If you'd rather not, a fully hosted API (Postmark, Resend) bundles the layers at higher per-email cost. Mailbase fits above SES-backed useSend (BYO at €5/mo) so you get the workflow without building it. See transactional email for SaaS and best transactional email services.
- Add: sending app (useSend), domain auth, workflow layer
- Common pattern: useSend-on-SES + a workflow layer
- SES base = lowest cost at scale, more to assemble
- Don't want to build? A hosted API bundles it at higher cost
Common Mistakes
- Sending product-critical mail and marketing from the same domain/reputation.
- Skipping idempotency, so retries create duplicate sends.
- Ignoring bounce and complaint webhooks until suppression breaks.
- Treating an email API as “fire and forget” with no event logging.
Sources & Further Reading
Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.
Related guides
More on aws ses email stack and the surrounding transactional email workflow:
FAQ
Is Amazon SES a complete email solution?
No — SES is the delivery engine (a raw sending API/SMTP with great pricing and deliverability), not a complete tool. It has no dashboard for non-developers, templates, list management, campaigns, or reply inbox. You build or buy those layers on top, which is why "using SES" means building a stack on it.
How do I build an email stack on AWS SES?
Put a sending app like useSend on top of SES for an API, dashboard, and key management; authenticate your domain with SPF/DKIM/DMARC; wire SNS so bounces and complaints feed suppression; and add a workflow layer for campaigns, replies, and analytics. SES is the bottom layer, not the whole thing.
When should I use SES instead of a hosted API?
Use SES (usually via useSend) when you want the lowest delivery cost at scale and are comfortable assembling the layers above it. Choose a hosted API like Postmark or Resend when you'd rather pay more per email to skip the building and get a dashboard and features out of the box.
Why are my SES emails only going to verified addresses?
Your account is still in the SES sandbox. New SES accounts can only send to verified addresses until you request production access, where AWS asks how you handle bounces, complaints, and unsubscribes. Exit the sandbox and wire up SNS notifications before sending real volume.