Comparison
YourMail vs AWS SES
We are not an alternative to SES — we are built on it. Every message described here is dispatched through Amazon SES in London. So this page is not about whose delivery is better, because it is the same delivery. It is about how much of the system around it you want to write.
Side by side
No prices for AWS SES on this page. They change, and a stale price on a page that benefits us is the most common way a comparison misleads — check their pricing directly. Ours is on our pricing page.
| YourMail | AWS SES | |
|---|---|---|
| What it is | An API on top of SES. The mail leaves through SES either way; what differs is how much of the surrounding machinery you write. | The raw sending service. An AWS API, IAM permissions, and a set of primitives you assemble into an email system. |
| Time to first email | Sign up, copy a key, one POST. You can send from our shared test address before verifying any domain, so nothing blocks on DNS. | Create IAM credentials, verify an identity, request production access to leave the sandbox, then send. The sandbox step is a support ticket with a human on the other end. |
| Suppression | Hard bounces and complaints are written to a suppression list automatically and enforced on the next send, with a 422 naming the address and the reason. | An account-level suppression list is on by default for bounces and complaints. It is per-region; deciding what it means for a given send — and surfacing that to your application — is still yours to build. |
| Delivery events | Delivered, bounced, opened, clicked and delay events are recorded against the message and readable from the API and the dashboard. | SES publishes events to SNS if you create a configuration set with an event destination. You then write the subscriber, verify the signature, deduplicate, and store them. |
| Webhooks to your app | HMAC-SHA256 signed POSTs with exponential-backoff retries and per-attempt delivery logs, plus auto-disable on a persistently failing endpoint. | SNS to an HTTPS endpoint, with SNS's own subscription-confirmation handshake and message-signature verification to implement. |
| Managed unsubscribe | RFC 8058 one-click List-Unsubscribe headers are injected and enforced on bulk sends; transactional mail is unaffected. | Not provided. You generate the headers, sign the token, host the endpoint and honour the result. |
| Where mail is sent from | Sending is in the UK — London (eu-west-2), on AWS SES. Storage residency at rest is not claimed. See the UK page for exactly what is and is not asserted. | Whichever region you configure, London included. You control it directly. |
| Pricing shape | A flat monthly tier. The free tier needs no card, and the limits are the ones the API enforces. | Metered per message, billed with the rest of your AWS account. Priced very low per message, and lower still at volume. |
| Who holds the reputation | Your own verified domain, DKIM-signed — which is what DMARC alignment needs; we check for a DMARC record and flag it when it is missing, but we do not require one. Note our tenants share one AWS account, so SES enforcement is shared here too: that is exactly why bounce and complaint rates are graded per account and sending is cut off before one bad sender can reach the shared identity. | Your AWS account, and nobody else's. SES enforcement is account-wide, so one bad campaign can pause sending for every application you run in it — but the only sender who can do that to you is you. |
Where AWS SES is the better choice
Written by us, about a competitor, on our own site — so treat it as a starting point and not an audit. It is here because a comparison with nothing in this section is not a comparison.
You are already deep in AWS
If your infrastructure is already IAM, CloudFormation and SNS, SES is one more resource in a stack you have the muscle memory for. Adding a vendor to sit in front of it is a new dependency, a new key to rotate and a new bill, in exchange for code you may find you can write in an afternoon.
Volume, and the unit price at that volume
SES is metered per message and is priced very low at scale. Any flat tier eventually loses that arithmetic. If you are sending millions a month and have someone whose job includes deliverability, the raw service plus your own tooling is the cheaper and more controllable answer.
You need SES features we do not surface
Dedicated IPs, IP pools and warm-up plans, custom MAIL FROM per identity, Virtual Deliverability Manager, mail sent from inside a VPC — SES has a large surface and we expose the part a transactional API needs. If you need one of those, going direct is not a workaround, it is the right tool.
The honest summary
Everything on this page is buildable on SES directly. None of it is hard in isolation. The reason products like this one exist is that there are about eight such pieces, each individually a day's work, and the last two — suppression semantics and delivery-event reconciliation — are the ones that bite six months later when a bounce arrives before the record of the message it belongs to.
If that trade is worth a flat monthly fee to you, this is a reasonable purchase. If it is not, SES is genuinely excellent and you should use it directly.
If you are still stuck at the first step, the guide to leaving the SES sandbox applies whether or not you ever use us — the request is the same one we had to make.
AWS SES is a trademark of its respective owner. YourMail is not affiliated with, endorsed by or sponsored by AWS SES; the name is used here only to identify the product being compared. Everything above was written by us and reflects our understanding at the time of writing — check anything that matters against their own documentation.
Try it on the free tier
No card. Send from our shared test address before you have verified a domain, so you can see the whole path — queued, sent, delivered — before changing any DNS.