# emails.sh vs Amazon SES

SES is the cheapest way to send email and gives you no product above the pipe. emails.sh trades unit price for logs, inbound, and an hour of setup.

Also searched as: Amazon SES alternative, AWS SES vs emails.sh, SES sandbox production access.

## What Amazon SES is

Amazon SES is the raw sending pipe. It is priced per thousand emails at a figure nobody else can match (long published at $0.10 per 1,000 outbound messages), it runs at AWS scale, and it integrates with the rest of AWS through IAM, SNS, CloudWatch, and the SDKs you already have. New accounts start in a sandbox that only sends to verified addresses at a low daily cap, around 200 a day, and you leave it by filing a production access request that describes your use case, expected volume, and how you handle bounces and complaints.

## Where Amazon SES is the better choice

If you send millions of messages a month, are already deep in AWS, and have an engineer who owns email, SES is almost certainly the right answer and the cost difference is not close. Everything above the pipe is yours to build, which is a real cost, but at high enough volume that cost is smaller than the per-email margin every other provider charges. Nothing here beats SES on price and we are not going to claim it does.

## Where emails.sh differs

SES sells you delivery and nothing else. There is no delivery log with a search box: you configure a configuration set, publish events to SNS or Kinesis Firehose, land them somewhere, and build the view yourself. Receiving means SES receipt rules writing to S3 and invoking a Lambda you maintain. Our argument is not that we are cheaper, it is that the dashboard, the per-message event history, the inbound pipeline, and nine language clients already exist, and that the hour you spend integrating here is a week you spend on SES.

### A delivery log you did not build

Ask SES "did message X arrive" and the answer is whatever pipeline you assembled from configuration sets, SNS topics, and a store. Here it is GET /v1/emails/:id and a searchable dashboard page, with delivery, bounce, and complaint events attached to the message.

### No sandbox and no approval ticket

SES starts you restricted to verified recipients at roughly 200 a day, and you leave by filing a request that AWS reviews. Verify a domain here and you send to anyone immediately, on 3,000 emails a month free. When you are shipping this week, that difference is the whole thing.

### Receiving without a Lambda

SES inbound means receipt rules, an S3 bucket, a Lambda to parse the MIME, and your own threading. Here inbound MX, MIME parsing, attachment extraction, and In-Reply-To threading are the product, and a reply is a row you can query rather than an object you wrote to a bucket.

## Moving from Amazon SES

This is the largest migration in this list, because leaving SES means deleting infrastructure rather than swapping a client. Do it in the order that lets you stop maintaining things.

1. **Replace SendEmail or SendRawEmail** The AWS SDK call with its Destination, Message, Body, and Subject nesting becomes a flat JSON body to POST /v1/emails with a bearer key. Credentials stop being IAM: no signed requests, no region endpoint, no role to assume from your task definition.
2. **Verify the domain again and re-add DKIM** SES Easy DKIM publishes three CNAMEs pointing at amazonses.com. Ours are separate records, so add them alongside and keep the SES ones until you are done. Your domain reputation does not move, so nothing needs warming.
3. **Retire the event pipeline** The configuration set, the SNS topic, the subscriber, and the store you built for bounce and complaint handling can be replaced by our signed webhooks. Run both for a week, confirm the numbers match, then delete the pipeline rather than leaving it half-alive.
4. **Move receiving last** If SES receipt rules feed an S3 bucket and a Lambda, keep them until sending is proven. Then repoint MX, let the last messages drain out of the bucket, and decommission the function. This is the step that removes the most code.

## Side by side (checked July 2026)

| | emails.sh | Amazon SES |
| --- | --- | --- |
| Pricing shape | Per email in monthly bands, with the dashboard, the logs, and the support inside that price rather than billed as four more line items. | Per thousand outbound emails, long published at $0.10 per 1,000, plus data and attachment charges. |
| Free tier | 3,000 emails a month with no sandbox to escape and no approval ticket. You verify a domain and send to anyone. | A free allowance tied to AWS, historically generous when sending from EC2 or Lambda. |
| Sending domains | One screen: add the domain, copy SPF, DKIM, and return-path records, watch them go green. Unlimited domains on every plan. | Domain identity plus Easy DKIM CNAMEs, managed in the AWS console or by IaC. |
| Deliverability posture | Reputation managed for you on shared pools, with the bounce and complaint thresholds enforced before an inbox provider enforces them on you. | Excellent infrastructure, and your reputation is yours to manage. Bounce and complaint thresholds are enforced with account pauses. |
| Receiving mail | Receiving is built in, not assembled from a rule set, a storage bucket, and a function you maintain. | Receipt rules that write to S3 and trigger Lambda. Parsing and threading are yours. |
| Logs and retention | A delivery log exists without you building one. "Did it arrive" is a URL, not a query across an event stream you set up first. | No delivery log by default. Publish events to SNS or Firehose and build the view. |
| Templates | Send html and text in the request, or store a template and reference it by id. No visual builder, because the markup belongs in your repo next to the code that sends it. | A template API with substitution. No editor. |
| SDKs and frameworks | Nine clients (node and typescript, python, php, ruby, go, rust, java, .net, elixir) plus curl, and framework guides from Next.js to Laravel, Rails, and Django. | The AWS SDK in every language, which is a large dependency for one API call. |
| Marketing and lifecycle | A contact list, segments, broadcasts, and lifecycle sequences exist here as API resources. On SES, list management is a contact list and a topic, and every campaign and sequence above it is yours to build. | Contact lists, topics, and subscription management. No campaign sending and no sequences. |
| Webhooks | email.delivered, email.bounced, and email.complained, each signed with x-emailssh-signature so you can verify the body before you act on it. | Event notifications via SNS or EventBridge rather than a direct HTTP webhook. |
| Path for a coding agent | One skill install, then your assistant writes the send call correctly. Compare that with an assistant guessing at IAM policies and region endpoints. | AWS documentation, which is thorough and very large. Assistants often guess wrong on IAM and regions. |
| Support | Email support on every plan including the free one, answered by the people who wrote the API. We are small, and that cuts both ways. | AWS support plans, priced separately from the service. |

## Questions

### Is emails.sh cheaper than SES?

No. Nothing is cheaper than SES per email, and if unit price is your deciding factor the decision is already made. What you are comparing is our per-email price against SES plus the engineer time to build the dashboard, the event pipeline, and the inbound parser.

### What is the SES sandbox?

Every new SES account starts restricted: you can only send to addresses you have verified, at a low daily cap of roughly 200 messages. You leave it by requesting production access and describing your use case, expected volume, and bounce handling. AWS reviews the request, and it can be rejected or limited.

### Does SES give me delivery logs?

Not out of the box. SES will publish delivery, bounce, and complaint events to SNS, EventBridge, or Firehose through a configuration set, but the searchable per-message view is something you build and pay to store. That gap is the most common reason teams leave.

### Can I use both?

Yes, and it is a reasonable steady state. Keep SES for high-volume bulk where the unit price dominates, and send the transactional traffic you actually need to debug through here. Authenticate the same domain in both and split in your own code.

All comparisons: https://emails.sh/vs
Docs: https://emails.sh/docs.md
Pricing: https://emails.sh/pricing.md