From Amazon SES
Keep SES underneath, gain the control plane you were about to build yourself.
You are not really leaving
OutSend sends through SES. Migrating from raw SES is not a change of provider — it is adding the control plane most teams end up building by hand: event storage, suppression handling, reputation scoring, webhook delivery, domain verification, and a UI that lets a human answer questions.
Field mapping
| SES v2 | OutSend |
|---|---|
Destination.ToAddresses | to |
FromEmailAddress | from |
Content.Simple.Subject.Data | subject |
Content.Simple.Body.Html.Data | html |
Content.Simple.Body.Text.Data | text |
ReplyToAddresses | replyTo |
MessageId | id in the response |
What you stop maintaining
- An SNS subscriber that parses notification JSON and writes it somewhere
- A suppression table, and the logic to check it before every send
- Bounce and complaint classification
- Per-domain DKIM key generation and DNS record management
- A retry policy that does not duplicate mail on a timeout
Idempotency keys alone remove a class of bug that most hand-rolled SES integrations still have.
Checklist
- Keep your existing SES identities — you can point OutSend at the same verified domains.
- Import your existing suppression list.
- Replace
SendEmailcalls withPOST /api/v1/emails. - Move your SNS topic subscription to OutSend’s endpoint so events flow into the log.
- Delete the SNS-parsing service you were maintaining. This is the good part.
Cost
You keep paying AWS for sending either way. OutSend’s subscription is for the control plane on top. If you would rather not pay for that, the core is open source — run it yourself and you are back to just an AWS bill.