# Amazon SES vs Resend Source: https://wraps.dev/versus/amazon-ses-vs-resend Resend sends through Amazon SES, so this is not an argument about whose delivery network is better. It is an argument about who owns the account, the reputation and the event history — and what the layer on top is worth. These are not two competing delivery networks. Resend sends through Amazon SES, so the packets leaving for Gmail take substantially the same path either way, and most arguments about whose deliverability is better are arguing about the wrong thing. The real axis is ownership. On SES the account, the reputation, the quota and the event stream are yours, and so is every operational feature you decline to build. On Resend all of that belongs to Resend, and what you get in exchange is a product that works this afternoon. ## At a glance |   | Amazon SES | Resend | | --- | --- | --- | | What it is | Raw sending infrastructure from AWS | Developer-first email API built on SES | | Published pricing | $0.10 per 1,000 emails on à la carte. New accounts are defaulted to the Essentials plan at $0.16 per 1,000; Pro is $105/mo + $0.22 per 1,000 and Enterprise $500/mo + $0.23 per 1,000. Plans are per-account, per-Region. | Free 3,000/mo (100/day). Pro $20 at 50K and $35 at 100K. Scale starts at $90 for the same 100K and runs to $350 at 500K. Overage $0.65–0.90 per 1,000. Marketing contacts billed separately at $40/mo per 5,000. | | Best for | Teams already on AWS with an engineer willing to own the plumbing. | The fastest path from an empty project to a sent email, especially with React Email. | | Watch out for | Production access is an application AWS can refuse, and new accounts start sandboxed to verified addresses. No dashboard, no templates, and nothing stores your events until you build it. | Logs are purged at 30 days on every non-Enterprise plan, the API is capped at 2 requests per second on all tiers, and suspension during traffic spikes is the complaint that recurs in its public reviews. | Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything. ## Where they actually differ ### What signing up actually gets you Amazon SES An API endpoint, an IAM policy and a region. SES gives you a send call, verified identities, configuration sets and nothing else — no dashboard worth opening, no template editor a colleague could use, no stored record of what you sent. Every operational feature you expect from an email vendor is one you are going to build, and the building is not difficult so much as endless. Resend A working integration and a dashboard in the time it takes DNS to propagate. The SDKs are small, domain verification is genuinely fast, React Email is first-party, and the log view answers did it send without you wiring anything up. That gap in time-to-first-email is the entire product and it is real value rather than marketing. ### The approval that is not in your control Amazon SES Every new SES account starts in a sandbox that only delivers to addresses you have verified, and leaving it is an application a human at AWS reads. Most clear within a day or two; some come back asking you to explain your list practices and bounce handling in more detail, and some are refused. It is the most common reason an SES launch date slips, and no amount of engineering removes it. Resend Resend has already been through that. Its sending account is out of the sandbox, warmed and operating, and you inherit the result the moment your domain verifies. This is the strongest practical argument for the layered model and it deserves to be stated plainly: you are renting a completed AWS approval along with the reputation that has accumulated behind it. ### Whose reputation is on the line Amazon SES Yours, in isolation. SES puts you on shared addresses by default, but the sending identity, the complaint rate and the account-level reputation metrics belong to your account alone. A neighbour's bad month is not your problem, and your bad month is not absorbed by anybody else. Dedicated addresses are available and you warm them on a schedule you choose. Resend Resend's, shared with every other customer on the same pools. Most of the time that helps, because their aggregate standing is better than a new sender's. The failure mode is the one that recurs in their public reviews: a sudden spike in your traffic looks like risk to a platform protecting everyone else's delivery, and the conservative response is to pause you first and talk afterwards. ### Where your delivery events end up Amazon SES Wherever you point them. SES publishes deliveries, bounces, complaints, opens and clicks to SNS, EventBridge or a Firehose stream, and from there into your own database, warehouse or object storage, retained for exactly as long as you decide. There is no vendor window because there is no vendor. The cost is that none of it exists until somebody builds it, and a half-built version is worse than none at all. Resend In Resend's log view, for thirty days, on every plan short of Enterprise. That is enough to debug a failing integration and not enough for a billing dispute, a compliance request or a year-over-year report. You can stream events into your own store from the first day and you should, but the default is a window that closes quietly and cannot be reopened. ### Throughput, and the ceiling you meet first Amazon SES SES has a per-second rate and a daily quota, both of which start conservative and both of which AWS raises on request while your bounce and complaint rates stay healthy. The ceiling moves. A team with a large batch to push plans the quota increase a week ahead and then pushes it, without changing vendor or plan. Resend Resend is capped at two requests per second on every tier including the most expensive, and that does not lift. For request-response mail it never matters. For anything batch-shaped it means a queue and a drip, which is ordinary engineering that nobody estimated, and which upgrading your plan will not save you from. ### Templates and the person who edits them Amazon SES SES has a template API with simple substitution. It is serviceable for a handful of transactional messages and nobody enjoys it. In practice teams render HTML inside their own application and hand SES the finished string, which means the templates are code you already own — portable and reviewable, and entirely your problem to build a preview for. Resend React Email, maintained by Resend and genuinely good, with components living in your repository and changes going through review like anything else. It is the stronger template story here by a distance, and it is also not a lock-in: the library renders to HTML that any provider accepts, so adopting it commits you to less than it appears to. ### What shape the bill has Amazon SES Per message, no platform fee, no plan to outgrow, billed by AWS next to everything else you run there. The change worth knowing is that new accounts now land on a metered plan rather than the old flat rate, and plans are per-account and per-region, so a second region is a second decision. Free-tier assumptions from older blog posts are no longer correct. Resend A plan ladder plus separately billed marketing contacts, so a list that grows raises the invoice in a month you sent nothing to it. Two ladders price the same volume differently depending which one you are sitting on, and overage bills automatically now that the hard caps have gone. More predictable than SES at small volume, steeper at large. ### What leaving costs, in each direction Amazon SES Moving off SES is mostly a code change, because the verified domains and the accumulated reputation are attached to an account you keep. You can run a second provider from a separate subdomain and shift traffic across gradually, which is about the least dramatic migration available anywhere in this field. Resend Moving off Resend means re-verifying domains elsewhere and starting reputation from nothing, because the warmed account was never yours. The code change is small since the SDK surface is deliberately minimal, but the infrastructure underneath does not travel with you, and the thirty-day window means you leave without your history. ## Pros and cons, side by side ### Amazon SES Strengths - The throughput limit is an opening position rather than a ceiling. AWS raises the per-second rate and the daily quota on request while bounce and complaint numbers stay healthy, so a batch job becomes a capacity request instead of a permanent drip. - Events land wherever you send them and stay for exactly as long as you decide, because there is no vendor window to close — retention becomes a line in your own infrastructure rather than a plan feature. - The account, the warmed addresses and everything the mailbox providers have learned about them belong to you, which turns replacing the layer above into a code change rather than a migration with a warm-up attached. - Standing is isolated to your own identity, so no neighbour's bad month reaches you and no shared-pool protection decision ever gets made about your traffic on someone else's behalf. Trade-offs - Every operational feature is missing and each one is a small project of its own — a dashboard, a suppression view, a template preview, an event store, something to search it with. None is hard and collectively they never finish. - The sandbox is the first thing you meet, and leaving it is an application a person reads on AWS's schedule rather than on yours. It is the most common reason a launch date on this side slips. - React Email works against it perfectly well, but the integrated preview and the maintained first-party path are not there, so the template workflow is something you assemble from parts. - Nothing warns you before an enforcement. The thresholds are published and the metrics are in your account, but only a team that built the alarm actually sees the number climbing. ### Resend Strengths - The AWS approval has already happened. You inherit a sending account that is out of the sandbox, warmed and operating, the moment your DNS verifies, which is the strongest practical argument the layered model has. - Time to a first delivered message is bounded by DNS propagation rather than by anybody's review queue, and the SDK surface is small enough that the integration really is finished the same afternoon. - React Email is first-party and actively maintained, with the preview tooling and the polish that the open-source renderer on its own does not hand you. - A dashboard, a domain verification flow and a log view exist without anybody wiring them up, which is three projects that never appear on your backlog. Trade-offs - Two API requests per second on every tier including the most expensive, with no plan that lifts it, so anything batch-shaped gets a queue that is permanent rather than a temporary workaround. - Logs are purged at thirty days on every plan short of Enterprise, which covers an integration bug and does not cover a billing dispute, a compliance request or a year-over-year comparison. - The standing you send on is theirs and shared, so a spike in your traffic can be paused by a platform making the correct decision for everybody else on the pool. - Marketing contacts are metered separately from sends, so a list that grows on its own raises the invoice in a month when nothing was mailed to it. ## Pick in thirty seconds ### Choose Amazon SES if - You are already on AWS, an engineer is willing to own the plumbing, and your volume is high enough that per-message price is worth engineering against. - Delivery events have to land in storage you control on a retention policy you set, because of an audit trail, a dispute process or a regulator. - You send in batches and need a rate limit that rises when you ask for it rather than a fixed ceiling that never moves. - You want reputation attached to an account you keep, so that changing tooling later is a code change rather than a migration. ### Choose Resend if - The deadline is this week, nobody wants to own a production-access application, and the volume is small enough that unit price is noise. - Your templates are React components and you want the maintained first-party path rather than wiring a renderer yourself. - Traffic is steady request-response mail comfortably under two calls a second, with nothing batch-shaped anywhere in the system. - You would rather buy a dashboard, a verification flow and a log viewer than build three mediocre versions of them. ## What actually moves when you switch In roughly the order you would do it. The expensive parts of an email migration are never the send call. 1. Apply for production access first and assume it is the critical path. You are asking AWS to grant what the incumbent already holds, and the answer turns on how convincingly you describe address collection, bounce handling and complaint processing. Nothing else in this move is gated by a human reading prose. 2. Export the log history while the window is still open. Thirty days is the entire archive on any plan short of Enterprise, so this cannot be scheduled for after the cutover — everything older than the window has already gone, and no support request brings it back. 3. Copy the suppression record across before the first production send rather than after it. A brand-new AWS account starts with an empty account-level suppression list, so the first campaign following a migration is the one that re-mails every person who previously filed a complaint. 4. Keep React Email and abandon the idea that it was ever the lock-in. The library renders components to an HTML string and the destination send call accepts one, so templates move unchanged. What you rebuild is the preview environment and the review workflow that surrounded them. 5. Swap the webhook consumer for an event destination. The incumbent posts a signed payload to an endpoint you nominate; the replacement publishes through SNS, EventBridge or Firehose, where the event types, the field names and the delivery guarantees all differ — so the consumer and every alert built on it are new code. 6. Request the sending-rate increase before you need it rather than during the first batch. Both the per-second rate and the daily quota start conservative, and the increase is granted against a healthy history that a one-day-old account has not accumulated yet. 7. Build the bounce-rate alarm before the first production send. AWS acts on published thresholds and does not telephone anybody, and that single alarm is the entire difference between a week of warning and a suspension you learn about from a drop in signups. 8. Ramp across subdomains rather than switching over. Run both providers from separate subdomains so DKIM keys and DMARC alignment stay independent, start with digests and other low-stakes traffic, and leave password resets on the warmed path until the new identity has weeks of clean data behind it. ## Questions to ask before you sign Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number. 1. Is any of our traffic batch-shaped — a digest, a nightly job, a launch announcement — and has anybody checked that shape against a fixed per-second ceiling that no plan lifts? 2. How far back do we need to answer a question about one specific message, and is that number written down anywhere or merely assumed? 3. Who would own production access, the quota increases and the bounce alarm, and does that person have the time this quarter rather than in principle? 4. If our sending were paused during a traffic spike tomorrow, what breaks first, and how many hours can the business tolerate it? 5. Are marketing contacts in the cost model or only sends, given that one of these two prices a list that grows while nobody is mailing it? 6. What would we lose on the day we left, and could a regulator or a customer ask us for any of it afterwards? 7. Do we actually want the AWS approval, or are we renting somebody else's completed one and describing that as a product decision? ## A third shape of answer This is the pair where the choice is most often presented as binary and most obviously is not. Resend exists because raw SES ships no product on top of itself, and SES is cheap because it is only a primitive — so the third shape is a platform layer over an SES account you own, which leaves the reputation, the quota and the event stream on your side of the line. Wraps is one way to do that. The honest cost is the same thing that pushes people to Resend to begin with: you need an AWS account and SES production access, an approval on AWS's schedule rather than ours, and our SDKs are TypeScript and Python only. Contacts, templates and workflow state live in our database — only sending and delivery events stay in your AWS — and we are not SOC 2 certified. Wraps publishes this page. We are not one of the two vendors being compared here, and this note is on it because the tension above is one owning the AWS account actually addresses — not because it is on every page. ## Common questions ### Is Resend really just Amazon SES underneath? Substantially, and Resend has never pretended otherwise. What differs is everything above the send call: SDKs, domain verification, the dashboard, React Email, webhooks with a sane shape. Because the substrate is shared, a claim that one of these two delivers to the inbox and the other does not is almost always describing a reputation difference between two accounts rather than a difference between two products. ### Will my inbox placement get worse if I move to raw SES? Temporarily, and for a reason that has nothing to do with SES. You would be a brand new sending identity with no history, which every mailbox provider treats cautiously for a while. The fix is the ordinary one — ramp volume gradually, start with your most engaged recipients, keep bounce and complaint rates low, and get DKIM, SPF and DMARC aligned before the first send rather than after the first problem. ### How long does SES production access actually take? Usually hours, sometimes a couple of days, and occasionally it comes back with questions. The application asks how you collect addresses, how you handle bounces and complaints, and what the mail is for. Vague answers get follow-up questions, which is the real cause of the multi-day cases. Write it as though a person is reading it, because one is, and have the bounce handling built before you apply rather than promised. ### Can I use React Email if I am sending through SES? Yes, and plenty of teams do. React Email is an open-source renderer that turns components into an HTML string; nothing about it is coupled to Resend's API. You render, then hand the result to the SES send call. You lose the integrated preview and the first-party polish, and you keep the part that actually matters, which is that your templates are reviewable code rather than rows in somebody's database. ### What does it really cost to rebuild what SES does not have? The naive estimate is a week and the honest one is that it never finishes. Sending is an afternoon. The rest is an event consumer, somewhere to store events, a way to search them, suppression handling, a template pipeline with previews, per-environment identities and enough alerting to notice a bounce-rate climb before AWS does. None of it is hard, all of it is real, and the maintenance does not stop. ### Can I run both at the same time? Yes, and it is a sensible way to de-risk a migration in either direction. Use a separate subdomain per provider so DKIM keys, reputation and DMARC alignment stay independent, then move traffic class by class — start with something low-stakes like digests, keep password resets on the proven path until last. The cost is two suppression lists and two sets of webhooks that nobody reconciles until something has already gone wrong. ### How do I keep more than thirty days of delivery history? By not relying on the vendor's view for it. Resend exposes webhooks, so the durable answer is to consume every delivery, bounce and complaint event into your own store from the first day and treat the dashboard purely as a convenience. That is roughly a day of work and it is the single highest-value thing a team on a hosted provider can build, because it is the only version of the history that survives both the retention window and the relationship. Doing it later does not recover what already expired. ### What happens to suppressions and unsubscribes when I switch? Nothing automatic, and this is where migrations do real damage. Each provider keeps its own record of who bounced, who complained and who opted out, and a new AWS account begins with that record empty. Export it and load it into the account-level suppression list before the first production send, not as a follow-up task. The failure is loud and public: the first mail after the cutover reaches everybody the previous provider had correctly stopped mailing, and the complaints that follow land against an identity with no history to absorb them. ### Should I request a sending quota increase before migrating? Yes, and earlier than feels necessary. Both the per-second rate and the twenty-four-hour quota start conservative on a new account, and AWS grants increases against a record of healthy bounce and complaint rates — which a freshly approved account does not yet have. The practical sequence is to get production access, send real but modest traffic for a while, then ask, with the metrics to point at. Leaving the request until the evening of a large batch is how a migration ends up throttled on the one night it had an audience.