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.

FeatureSNDRAmazon SES
Send APIPOST /v1/send with typed SDKSendEmail / SendRawEmail / v2 SendEmail (multiple)
Bounce / complaint eventsSigned webhooks delivered to your URLSNS topic → you wire up SQS or Lambda
Suppression listAuto-managed across all sendsAccount-level + per-config-set, build your own UI
Reputation dashboardPer-MTA + per-recipient-domain in real timeCloudWatch metrics + DIY
Sandbox approvalNo sandbox — verified domain = productionManual sandbox → production review
Quota jugglingPlan-based, no per-region opaque limitsPer-region 24-hour sending quota + max send rate
IP warmupManaged pool, automatic warmupDedicated IPs require manual warmup or DIA
Per-message price (1M emails)Higher (managed)Lowest in market ($0.10 per 1000)
Time-to-first-emailMinutes — DNS + SDK + sendHours to days for sandbox exit + SNS plumbing
Bring your own MTA / outboundManaged multi-MTA poolYes — 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. 1

    Install the SDK

    Add @rkiza/sndr alongside @aws-sdk/client-ses. Both can run in parallel during cutover.

    pnpm add @rkiza/sndr
  2. 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. 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. 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. 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.