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.
Raw infrastructure · Amazon SES claims checked July 2026
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.
Side by side
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
- Pricing shape
- emails.sh Per email in monthly bands, with the dashboard, the logs, and the support inside that price rather than billed as four more line items.
- Amazon SES Per thousand outbound emails, long published at $0.10 per 1,000, plus data and attachment charges.
- Free tier
- emails.sh 3,000 emails a month with no sandbox to escape and no approval ticket. You verify a domain and send to anyone.
- Amazon SES A free allowance tied to AWS, historically generous when sending from EC2 or Lambda.
- Sending domains
- emails.sh One screen: add the domain, copy SPF, DKIM, and return-path records, watch them go green. Unlimited domains on every plan.
- Amazon SES Domain identity plus Easy DKIM CNAMEs, managed in the AWS console or by IaC.
- Deliverability posture
- emails.sh Reputation managed for you on shared pools, with the bounce and complaint thresholds enforced before an inbox provider enforces them on you.
- Amazon SES Excellent infrastructure, and your reputation is yours to manage. Bounce and complaint thresholds are enforced with account pauses.
- Receiving mail
- emails.sh Receiving is built in, not assembled from a rule set, a storage bucket, and a function you maintain.
- Amazon SES Receipt rules that write to S3 and trigger Lambda. Parsing and threading are yours.
- Logs and retention
- emails.sh 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.
- Amazon SES No delivery log by default. Publish events to SNS or Firehose and build the view.
- Templates
- emails.sh 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.
- Amazon SES A template API with substitution. No editor.
- SDKs and frameworks
- emails.sh 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.
- Amazon SES The AWS SDK in every language, which is a large dependency for one API call.
- Marketing and lifecycle
- emails.sh 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.
- Amazon SES Contact lists, topics, and subscription management. No campaign sending and no sequences.
- Webhooks
- emails.sh email.delivered, email.bounced, and email.complained, each signed with x-emailssh-signature so you can verify the body before you act on it.
- Amazon SES Event notifications via SNS or EventBridge rather than a direct HTTP webhook.
- Path for a coding agent
- emails.sh One skill install, then your assistant writes the send call correctly. Compare that with an assistant guessing at IAM policies and region endpoints.
- Amazon SES AWS documentation, which is thorough and very large. Assistants often guess wrong on IAM and regions.
- Support
- emails.sh 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.
- Amazon SES AWS support plans, priced separately from the service.
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.
- 01
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.
- 02
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.
- 03
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.
- 04
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.
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.
Looking for an Amazon SES alternative?
SES is the cheapest way to move email and it will stay that way. The question is not price per thousand, it is what a delivery dashboard, an inbound pipeline, and a set of language clients cost you in engineer weeks, and whether you would rather spend those weeks on your own product.
The free tier is 3,000 emails a month, 100 a day, no card, sending from your own verified domain, with delivery logs, webhooks, and inbound included. Enough to run real traffic through it before you decide.