Using Amazon SES?

Keep Amazon SES. Put a failover chain in front of it.

Amazon SES (Simple Email Service), AWS's sending service, is one of the cheapest, most dependable ways to send. What it doesn't do is route around itself, keep your messages, or tell a story per mail. That's the part teams end up building.

See it fail overHow Mailway compares

Nobody searches "Amazon SES failover" because Amazon SES is bad. They search it after the day it said no: a paused account, a rotated SMTP password one config missed, a region having a bad hour. The question is never which provider to replace Amazon SES with. It's what should happen to the next message when Amazon SES can't take it.

There are two honest answers. Build the chain yourself, which is a real project with more pieces than it looks, or put a gateway in front of the Amazon SES account you already have. This page lays out both, including when you need neither.

What Amazon SES already does well

Cheap, fast, and precise about its rules.

Price and scale

Pay-as-you-go pricing per recipient, with plans for heavier senders. The per-message rate stays low at transactional volumes (Amazon SES pricing).

Published enforcement thresholds

Amazon SES says exactly when it reviews an account: a 5% bounce rate or a 0.1% complaint rate, with a possible pause at 10% or 0.5%.

Rich events, if you wire them

Send, delivery, bounce, complaint, reject, delay, and more, published to SNS, EventBridge, Firehose, or CloudWatch.

Resilience inside Amazon SES

Global endpoints can spread sending across two AWS regions and shift traffic away from an impaired one.

Where it hurts

What Amazon SES leaves to you.

Failover stops at the Amazon SES boundary

Amazon SES global endpoints fail over between two Amazon SES regions. They work through the v2 API only, not SMTP, and you duplicate identities, configuration sets and quotas in both regions. An account-level problem, like a paused account or revoked credentials, follows you into the second region.

source: Amazon SES global endpoints
With Mailway in front

Your chain can hold a different provider. When Amazon SES refuses a message, the retry goes to the next provider in your chain five seconds later, over SMTP or API alike. Failover needs two providers, so it's available on Pro and up.

A pause is account-wide

At a 10% bounce or 0.5% complaint rate Amazon SES may pause the account's sending, and in serious cases it can pause without a review first.

source: Amazon SES enforcement FAQ
With Mailway in front

Transactional mail keeps moving through your next provider while you fix the cause. Failover buys time; it doesn't fix a list problem. If Amazon SES paused you for complaints, the same list will hurt the next provider's reputation too, so Mailway's per-project suppression list stops known-bad addresses before any provider sees them.

50 recipients per message, not adjustable

A recipient is any To, Cc, or Bcc address, and the 50 limit can't be raised.

source: Amazon SES quotas
With Mailway in front

A send above the cap is fanned out BCC-style across chunks of 50, touching only the recipient headers. The body and its DKIM signature stay as your app sent them (how).

History is opt-in, short, or paid

Virtual Deliverability Manager searches the last 30 days of message events, samples above 100 results, and only tracks single-recipient mail. Keeping message content means Mail Manager archiving: opt-in, priced per GB, 180 days by default, searched 30 days at a time.

source: Amazon SES Virtual Deliverability Manager
With Mailway in front

Every message is archived byte-for-byte, next to a timeline of every attempt and every event Amazon SES reports back through SNS, searchable by sender, recipient, subject, and state for as long as your plan keeps it (retention).

Build it yourself, or not

The pieces of a failover chain.

If you build it, these are the parts. None is exotic; together they are a service you now own, page for, and keep true to both providers' behavior.

A second provider
On your ownAn account, verified domain and credentials at another company.
With MailwayThe same. Mailway is bring-your-own-keys; you add the account in the console.
Retry and failover logic
On your ownTell an auth failure from a bad recipient from a throttle; never retry a permanent reject; don't re-dial the provider that just failed.
With MailwayBuilt in: errors are classified per attempt, and the retry goes to a provider the mail hasn't tried five seconds later.
Amazon SES's 50-recipient cap
On your ownSplit large sends yourself without breaking the message.
With MailwayHeader-only fan-out above the cap; the body and DKIM stay intact.
One suppression list
On your ownA bounce reported by Amazon SES has to stop sends through provider two.
With MailwayReported bounces and complaints land on one per-project list, checked before any provider.
Event ingestion
On your ownSNS on one side, the other provider's webhooks on the other, normalized into one model.
With MailwayAmazon SES events arrive through SNS into one timeline per message, beside the webhook events of the other supported providers. Gmail and generic SMTP servers don't report outcomes, so their sends stay accepted.
Archive and search
On your ownStore raw MIME, index it, run retention, build a search UI support can use.
With MailwayByte-for-byte archive, searchable by sender, recipient, subject, and state, retention by plan.
Proof
On your ownHash, sign and timestamp what left, if a dispute ever needs it.
With MailwaySigned, independently timestamped certificates on Business and up.
What doesn't change
  • Your Amazon SES account, your pricing, your sending reputation and your verified domains.
  • SPF and DKIM stay configured at Amazon SES. Mailway relays your message; Amazon SES signs and sends it.
  • You can keep sending to Amazon SES directly from other systems. Mailway only sees what goes through it.
When you don't need Mailway

If Amazon SES covers your volume, a pause has never cost you money, 30 days of event history answers every question anyone asks, and nobody needs the message itself months later, Amazon SES on its own is the right answer. A layer in front of it would be complexity you don't need.

If you do move

It's a config change, not a migration.

Add your Amazon SES account to Mailway (API or SMTP credentials), add a second provider behind it, and point your mailer at smtp.mailway.net with a Mailway SMTP credential. Your app keeps speaking SMTP; the quickstart is the whole integration.

Point Amazon SES's SNS notifications at Mailway and deliveries, bounces, and complaints land on each message's timeline (Amazon SES setup). Switching back is the same config block in reverse.

Amazon SES → Mailway — mailer config
const transporter = nodemailer.createTransport({
- host: "email-smtp.eu-central-1.amazonaws.com",
+ host: "smtp.mailway.net",
port: 587,
- auth: { user: OLD_USER, pass: OLD_PASS },
+ auth: { user: MAILWAY_USER, pass: MAILWAY_PASS },
});

Amazon SES SMTP endpoints are regional: email-smtp.<your-region>.amazonaws.com.

Amazon SES facts checked 2026 Q3 against the vendor's own pages

Other providers: SendGrid · Mailgun · Postmark · all providers

Your mailer config has
one block to change

Mailway is in private beta, and we onboard teams one at a time. Leave your email and we'll send your invite when it's your turn.

read the docs meanwhile →

join the waitlist — mailway.net

Your invite, one email away.

Mailway is in private beta, and we onboard teams one at a time. Leave your email and your invite arrives when it's your turn.