Alternatives
The SNDR alternative to Amazon SES.
A managed Amazon SES alternative. Same multi-region delivery quality without the SNS + SQS + Lambda glue, the manual reputation work, or the sandbox-to-production approval dance.
Amazon SES is the cheapest per-message email infrastructure on the planet — once you've built the surrounding system: an SNS topic per event type, a Lambda or SQS consumer for bounces and complaints, a suppression list you own, a reputation dashboard you build, an IP-pool rotation strategy you implement, and the IAM matrix to keep the whole thing safe. SNDR ships all of that out of the box on top of comparable upstream delivery. The trade-off is per-message price for engineer hours.
Side by side
SNDR vs Amazon SES
Every row links to where the underlying behavior is documented or implemented.
| Feature | SNDR | Amazon SES |
|---|---|---|
| Send API | POST /v1/send with typed SDK | SendEmail / SendRawEmail / v2 SendEmail (multiple) |
| Bounce / complaint events | Signed webhooks delivered to your URL | SNS topic → you wire up SQS or Lambda |
| Suppression list | Auto-managed across all sends | Account-level + per-config-set, build your own UI |
| Reputation dashboard | Per-MTA + per-recipient-domain in real time | CloudWatch metrics + DIY |
| Sandbox approval | No sandbox — verified domain = production | Manual sandbox → production review |
| Quota juggling | Plan-based, no per-region opaque limits | Per-region 24-hour sending quota + max send rate |
| IP warmup | Managed pool, automatic warmup | Dedicated IPs require manual warmup or DIA |
| Per-message price (1M emails) | Higher (managed) | Lowest in market ($0.10 per 1000) |
| Time-to-first-email | Minutes — DNS + SDK + send | Hours to days for sandbox exit + SNS plumbing |
| Bring your own MTA / outbound | Managed multi-MTA pool | Yes — full control if you want it |
Drawn from public documentation and pricing as of build time. We try to keep this fair — file an issue if anything is wrong.
Why teams switch
Where SNDR fits better than Amazon SES.
Engineer hours cost more than messages
A team using SES typically spends 2–4 engineer-weeks building the surrounding pipeline (SNS, suppression, dashboards, alerting). SNDR replaces all of it. The break-even on engineering cost is well under a million messages per month for most teams.
No sandbox, no quota approval
SES forces every new account through a sandbox phase and a regional quota approval. SNDR has none — verify your domain and send.
Bounce + complaint handling is one webhook, not a topic
SES routes bounce/complaint events through SNS, which most teams plumb into SQS, which most teams consume in a Lambda, which most teams persist to RDS. SNDR delivers one signed HTTPS POST to your endpoint.
Suppression that does the right thing by default
Hard bounces and complaints land on the suppression list automatically and are checked on every subsequent send. With SES you build this — and forget to clear it correctly when a customer cycles addresses.
You can still go raw
When you need full SMTP control SNDR exposes it, including DKIM signing, custom MIME, and header passthrough. You don’t lose the SES-level escape hatches by choosing managed.
Multi-MTA failover
SES is a single network. SNDR routes across a pool of MTAs we operate, with circuit-breaker drop-out for misbehaving boxes. A bad day at one upstream doesn’t become a bad day for your sends.
Migration
Moving off Amazon SES's SDK.
The SNDR SDK uses the same primitives as most modern email clients — install, instantiate with a key, call emails.send. In most codebases the migration is a focused diff.
- 1
Install the SDK
Add @rkiza/sndr alongside @aws-sdk/client-ses. Both can run in parallel during cutover.
pnpm add @rkiza/sndr - 2
Replace the send call
SES SendEmailCommand maps cleanly. The SNDR call is shorter because Destination/Message/Body are flattened.
// before import { SESClient, SendEmailCommand } from '@aws-sdk/client-ses'; const ses = new SESClient({ region: 'us-east-1' }); await ses.send(new SendEmailCommand({ Source: 'me@yourdomain.com', Destination: { ToAddresses: ['a@b.com'] }, Message: { Subject: { Data: 'hi' }, Body: { Html: { Data: '<p>hi</p>' } } }, })); // after import { Sndr } from '@rkiza/sndr'; const sndr = new Sndr(process.env.SNDR_API_KEY!); await sndr.emails.send({ from: 'me@yourdomain.com', to: 'a@b.com', subject: 'hi', html: '<p>hi</p>', }); - 3
Retire your SNS → SQS → Lambda pipeline
The whole bounce/complaint plumbing collapses into a single webhook handler. Verify the signature and switch on event.type.
import { verifyWebhookSignature } from '@rkiza/sndr'; app.post('/webhooks/sndr', express.raw({ type: 'application/json' }), (req, res) => { if (!verifyWebhookSignature(req.body, req.header('x-sndr-signature') ?? '', process.env.SNDR_WEBHOOK_SECRET!)) { return res.status(400).send('bad signature'); } const event = JSON.parse(req.body.toString('utf8')); if (event.type === 'email.bounced') { // No SNS, no SQS — just the payload, signed. } res.status(200).send('ok'); }); - 4
Migrate your suppression list
Export from SES (ListSuppressedDestinations) and import via the SNDR dashboard or API. Customer-domain suppressions persist; account-level retain their reason metadata.
- 5
Reuse your DNS, drop unused SES regions
SPF can keep the SES include during cutover. DKIM keys can co-exist (selectors are independent). After the cutover, remove SES include + delete unused regional configurations.
Want a hand migrating from Amazon SES?
We've helped teams move millions of monthly sends across providers without dropping a single delivery. Reach out and we'll walk through your stack.
No shade — Amazon SES is a great product. SNDR just optimises for different things.
Start building
Your next message starts here.
Connect your domain, create an API key, and send with SNDR.