Resend vs Amazon SES: pricing, lock-in, and when SES wins
Resend vs Amazon SES pricing: $20–$350/mo vs $0.10 per thousand. Cost comparison, lock-in, and when to send from your own AWS.
If you are searching for “AWS email hosting pricing,” you are usually asking one of two questions: what does it cost to send email through a hosted API like Resend, or what does it cost to send from your own AWS account through Amazon SES.
The difference is not a small detail. It determines who owns your suppression list, where your bounce data lives, and what happens when the provider reprices or you decide to leave.
This is the full breakdown: what each model costs at real volumes, which parts of your email system you own and which parts you rent, and the decision points where one makes sense over the other.
Does Resend use Amazon SES?
Yes. Resend sends email through Amazon SES infrastructure. This is publicly documented in email headers and acknowledged industry practice: when you send through Resend, your emails travel through the same SES delivery backbone that powers direct SES sends.
This matters because “Resend vs Amazon SES” is not a comparison of two independent email networks. It is a comparison between paying for a managed layer built on top of SES, and operating SES directly in your own AWS account.
Resend is not just reselling raw SES access. They provide developer APIs, React Email template tooling, webhook delivery, suppression list management, a unified dashboard, and operational abstractions that do not exist in SES alone. The value proposition is the layer on top of the delivery infrastructure, not the infrastructure itself.
What stays similar: Resend sends from shared SES IP pools by default, the same way a new direct SES customer does. At higher volumes, Resend offers dedicated IPs for an additional fee — still SES infrastructure, still managed by Resend, but isolated to your sends. The underlying IP-level reputation baseline is SES shared infrastructure in both cases until you pay for dedicated capacity.
What differs: Who operates the bounce pipeline, who owns the suppression list, who watches the complaint rates, and who you call when deliverability drops. With Resend, the answer is Resend. With direct SES, the answer is you — or the infrastructure you build (SNS topics, Lambda handlers, your own database).
Migration implication: Moving from Resend to your own SES is mostly an infrastructure and integration project, not a deliverability reset. Your verified sending domain moves with you — the DKIM records that prove you authorized the send point to your domain, not to Resend’s. You will lose access to Resend’s dashboard, webhook format, and API, which means rewriting send calls and event handlers. But you are not switching email networks or warming new IPs from scratch — you are switching from a managed SES layer to operating the same SES backbone yourself.
The reputation you have built is tied to your domain, not to Resend’s infrastructure. IP reputation resets when you move (because the IPs are Resend’s or Amazon’s, never yours), but domain reputation follows your DNS. This is the same dynamic that applies when moving between any two providers that send from pooled or vendor-controlled IPs.
If you want to compare managed APIs more broadly, How to choose a transactional email API covers Resend, Postmark, SendGrid, and others. If you want to know what it costs to operate SES yourself at real volume, What email actually costs on AWS breaks down the full bill at 50k, 500k, and 2M emails per month — including Lambda, queues, database, and the operational stack beyond just the $0.10 per thousand SES send cost.
Pricing at real volumes
All prices below are as of August 2026. Resend published pricing and AWS SES list pricing for us-east-1, no discounts or commitments.
Under 100,000 emails a month
| Volume / month | Resend | Amazon SES | Difference |
|---|---|---|---|
| 3,000 | Free | ~$0.30 | Resend wins |
| 10,000 | Free | ~$1 | Resend wins |
| 50,000 | $20 (Pro) | ~$5 | Resend costs 4× more |
| 100,000 | $35 (Pro) | ~$10 | Resend costs 3.5× more |
Resend’s free tier is genuinely free for the first 3,000 emails per month, with a daily cap of 100 emails. There is no sandbox mode and no approval delay. Amazon SES costs $0.10 per 1,000 emails from the first email, but new accounts start in a sandbox and require production access approval, which typically takes 24 hours and requires you to have already built bounce and complaint handling.
SES pricing note (July 2026 change): New SES accounts and account×region combinations with no metered SES activity since June 1, 2025 now default to the Essentials plan at $0.16 per 1,000 emails on the first 10M per month, which bundles Virtual Deliverability Manager features.* The à-la-carte option at $0.10 per 1,000 still exists and is switchable at any time in the SES console under Pricing plan. The tables above use à-la-carte pricing for an apples-to-apples send-cost comparison, since Resend does not include equivalent deliverability add-ons in its base price.
For early-stage products sending under 3,000 emails a month, Resend’s free tier is the correct choice. Past that, SES is cheaper — but not enormously so, and the difference may not be worth the setup time if you have no AWS experience.
100,000 to 500,000 emails a month
| Volume / month | Resend | Amazon SES | Difference |
|---|---|---|---|
| 200,000 | $160 (Scale) | ~$20 | Resend costs 8× more |
| 500,000 | $350 (Scale) | ~$50 | Resend costs 7× more |
The gap widens. Resend’s Scale tier is designed for volume, but the pricing is still tiered per month rather than per email. Amazon SES is linear: 500,000 emails costs exactly ten times what 50,000 costs.
At this volume the per-email difference matters. Resend’s $350 for 500,000 emails works out to $0.70 per thousand. SES is $0.10 per thousand — plus about $0.02 for Lambda, queues, and event handling if you are running the full stack. What it actually costs to send 500,000 emails from your own AWS breaks down the full bill line by line at 50k, 500k and 2M.
500,000 to 2,500,000 emails a month
| Volume / month | Resend | Amazon SES | Difference |
|---|---|---|---|
| 1,000,000 | $650 (Scale) | ~$100 | Resend costs 6.5× more |
| 1,500,000 | $825 (Scale) | ~$150 | Resend costs 5.5× more |
| 2,000,000 | $1,150 (Scale)* | ~$200 | Resend costs 5.75× more |
| 2,500,000 | $1,150 (Scale) | ~$250 | Resend costs 4.6× more |
*Resend’s 2.5M tier is $1,150, so 2M falls between the 1.5M and 2.5M tiers. If you send exactly 2M, you pay the 1.5M base ($825) plus overage at $0.52 per thousand for the additional 500k, which is $260, totaling approximately $1,085 — close to the 2.5M tier price anyway.
Above 2.5 million emails per month, Resend’s published pricing ends and you are on Enterprise pricing, which is negotiated. SES continues at $0.10 per thousand with no upper cap and no conversation required.
The overage trap
Resend’s Pro tier charges $0.90 per 1,000 emails over the plan limit. The Scale tier starts at $0.90 and drops to $0.46 at the highest tier. SES does not have overages — the rate is the same whether you send 1,000 emails or 10 million.
If you are on Resend’s $35 Pro plan (100k emails) and you send 150k in a month, you pay $35 + (50 × $0.90) = $80 for that month. On SES, 150k emails is $15, plus a few dollars for Lambda and queues. Overages do not hurt once — they hurt every time you cross the line until you upgrade the tier, and upgrading the tier means paying the higher base every month whether you use it or not.
Per-email vs per-contact: why the pricing model matters
Before the cost tables, it is worth naming the structural difference.
Most marketing platforms bill per contact — you pay for the size of your list every month, whether you send to it or not. A list of 25,000 contacts costs the same in January when you send four campaigns as it does in July when you send nothing.
Resend and SES both bill per email sent. The bill tracks what you actually do, not what you could theoretically do if you emailed everyone every day.
This matters because the two models diverge completely as you grow. A list that doubles does not double your send volume — most newsletters and SaaS products do not suddenly email twice as often just because they have twice as many subscribers. Under per-contact pricing, the bill doubles anyway. Under per-email pricing, it does not move until you actually send more.
Resend is per-email with monthly tiers. SES is per-email with no tiers — genuinely linear, $0.10 per thousand no matter how much you send. The gap between them is not about the billing model; it is about whether you are renting infrastructure or owning it. Per-contact pricing and what you are actually paying for is covered in detail here.
What AWS email hosting pricing actually includes
SES itself is $0.10 per 1,000 emails. That is the send cost and it is most of the bill. But “AWS email hosting pricing” — the cost of actually operating an email platform on your own AWS account — also includes:
- Lambda — the functions that process sends, handle delivery events, and run automations. $0 at low volume (the free tier is permanent), a few dollars at 500k, roughly $20 at 2 million. Full breakdown here.
- SQS, SNS, EventBridge — queuing, delivery event notifications, and scheduled automation triggers. A few dollars a month at volume. Cheap enough to be hard to make interesting.
- The database — the one line that is not free when nothing is happening. Postgres on Neon’s free tier, a serverless Postgres for $0–$50/month, or RDS from about $15/month. Not AWS SES, but required if you are operating an email platform rather than just calling an API.
- S3 and CloudFront — media storage and delivery for images in emails. Rounds to nothing unless you are hosting video.
SES list pricing is the floor. The full bill at 500k emails a month is roughly $55–65 all in. That is still cheaper than Resend’s $350, but it is not $50 — there are other lines. The “What it actually costs” post linked above goes through each one with real numbers at three volumes.
Lock-in: what you own and what you rent
Pricing is the easy comparison. Lock-in is harder to see and more expensive to fix later.
When you use Resend, you are renting infrastructure. When you use SES, you own the account and the configuration. The difference shows up when you want to leave, or when the service changes terms, or when you want to move to a different provider without losing your sending history.
What moves with you, and what does not
| Asset | Resend | Amazon SES |
|---|---|---|
| Domain reputation | Resend’s shared pool or your dedicated IP (rented) | Your verified domain + your AWS account |
| Suppression list | Exported via API, rebuilt elsewhere | Your Postgres/DynamoDB — you own the table, not the vendor |
| Bounce & complaint history | Resend’s dashboard; no raw event export | SNS → your endpoint → your database — every event is a row you control |
| Sending domain & DKIM | DNS records point to Resend’s infra; move requires DNS change | DNS points to SES in your AWS account; moving to another provider requires DNS change |
| Email templates | Resend’s API or React Email components in your codebase | Your code, your S3 bucket, your database — provider-agnostic |
| Webhooks & event handling | Resend’s webhook format, must rewrite integrations | SNS events to your endpoint; changing event schema is code, not migration |
| API surface | Resend SDK & API; switching providers = rewriting send calls | AWS SDK or SMTP; changing providers = swap credentials + DNS |
| Infrastructure access | Read-only dashboard + API | Full IAM control, CloudWatch logs, CloudFormation, Terraform |
Domain reputation and IP ownership: shared vs dedicated, rented vs owned
When you send through Resend, your emails leave from Resend’s IP addresses. By default, you send from shared IPs — a pool Resend manages, shared across many customers. If you pay an extra $30/month and send more than 3,000 emails per day, you can add a dedicated IP.
A dedicated IP on Resend is still Resend’s IP. You are renting it. You get your own address, which means your reputation is isolated from other senders, but you do not own the IP. If you leave Resend, the IP and the reputation it has built stay with Resend. You cannot take it with you.
Shared IPs are cheaper and require no warmup — Resend handles that — but your deliverability is partly dependent on the behavior of every other sender in that pool. One bad actor can damage the pool’s reputation, and you inherit that damage. Dedicated IPs give you control, but at the cost of warmup time (typically 4-6 weeks to build trust with mailbox providers) and the $30/month fee.
When you send through SES, you send from Amazon’s IP pools by default — shared infrastructure, same as Resend’s shared IPs. Your reputation is attached to your verified sending domain and your AWS account. Your DKIM signature proves you authorized the send. The IP is Amazon’s, but the domain reputation is yours.
SES also offers dedicated IPs, starting at $24.95/month per IP. The difference: these are dedicated to your AWS account, not to a vendor’s pool. You still do not “own” the IP address in the sense that you cannot transfer it to another provider, but the reputation is isolated to your account, and you control what sends through it.
Practically: if you have been sending 500k emails a month through Resend for two years and you switch to SES or Postmark or any other provider, you take your domain. You lose the IP reputation (because the IP was never yours), but your From domain has a history with mailbox providers, and DKIM proves continuity. The IP warms from scratch; the domain does not.
If you have been sending through SES in your own AWS account, switching providers is the same story: new IPs, same domain. You own the domain reputation in both cases, but with SES you also own something more valuable than the IP reputation — you own the data.
Suppression lists: the API export vs the table in your Postgres
A suppression list is the record of every address that hard-bounced, every address that complained, and every address that unsubscribed. It is how you avoid emailing people who do not want to hear from you, and it is the most important list in your email system.
Resend maintains a suppression list on your behalf. You can export it through the API. When you leave, you take the export and load it into your new provider. That works, but it has a gap: any suppression logic that was implicit in Resend’s handling — addresses removed for reputation reasons, addresses flagged by their abuse desk, addresses suppressed globally across Resend’s customer base — does not export, because you never saw it. The data lives in Resend’s cloud, not yours.
SES has an account-level suppression list that works the same way: AWS maintains it, you can query it, but you do not own the underlying data. The difference is that when you operate on SES, you also build your own suppression list, in your own database, because you are the one handling the SNS bounce and complaint notifications.
That list is yours. It lives in your Postgres table, your DynamoDB table, or wherever you decide to put it. When you switch providers, you take the whole thing — no export step, no API rate limit, no “please contact support for bulk access.” You own the table. You wrote the Lambda that populates it. The data is in your infrastructure, not the vendor’s.
Every bounce notification from SES goes to an SNS topic you control. You write the handler — a Lambda, an HTTPS endpoint, whatever — that receives the event, parses it, and writes the address to your suppression table. Every complaint notification follows the same path. Every unsubscribe, if you are handling RFC 8058 one-click unsubscribe, writes to the same table.
The suppression list is not a feature Resend provides. It is a table in your database that you control, and the code that manages it is yours. When you leave, the table does not move — it was never anywhere else.
This is not theoretical. Suppression list migration is the step that breaks most email platform moves. You export what you can, you import it into the new system, and three months later you notice your complaint rate is higher than it should be because 3% of your suppression records were “global” suppressions that never made it into the export.
Templates, webhooks, and API surface area
Resend’s API is clean and its React Email integration is excellent. If your codebase is React or Next.js, you can build email templates as JSX components, preview them in a browser, and send them with a POST request. This is legitimately good developer experience, and it is also lock-in.
Not because the code is secret — React Email is open source and the rendered HTML is yours. But because the integration is with Resend. Every resend.emails.send() call is a line of code that will need to change when you switch providers. Every webhook handler that parses Resend’s event format is another integration to rewrite.
SES has no equivalent to React Email. Its templating is basic Handlebars and nobody uses it. What SES gives you instead is SMTP and the AWS SDK, both of which are standards. If you send via SMTP, switching providers is a credential swap. If you send via the SDK, switching providers is mostly a credential swap — the method signatures change but the logic does not.
Webhooks are the same story. Resend sends you an HMAC-signed JSON payload when an email bounces or a link is clicked. SES sends an SNS notification to an endpoint you control, and you write the handler. Resend’s format is easier to start with. SNS is easier to move, because the handler is your code in your Lambda or your server, and swapping the upstream event source is a configuration change, not a code rewrite.
The question is not “which is better.” It is “how much of your email system is in your control, and how much of it is in the provider’s API.”
What happens when the provider changes terms
Resend is a venture-backed startup. It is in the phase of its life where the goal is growth, not profit, which is why the free tier is generous and the pricing is competitive. That phase does not last.
At some point — a year, three years, whenever the investors want to see a return — the terms will change. The free tier will shrink or disappear. The Scale tier will reprice. Enterprise minimums will appear. This is not speculation; it is the standard lifecycle of venture-funded B2B SaaS, and it has played out the same way in every category for twenty years.
When that happens, your options depend on how much of your system is portable. If your suppression list is in your database, your templates are in your codebase, and your event handling is in your infrastructure, you can leave. The work is not zero — you have to rewrite the send calls and change your DNS — but it is a project you can scope, and the decision is yours.
If your suppression list is in Resend’s system, your webhook handlers are written to Resend’s event schema, and your templates use Resend-specific features, leaving is not a project. It is a migration, with downtime risk, data loss risk, and enough work that “just pay the new price” starts to look rational even when the new price is not.
SES is not immune to repricing — AWS services change price too, and in July 2026 SES introduced new tiered pricing plans (Essentials, Pro, Enterprise) that are higher than the legacy $0.10 per thousand à-la-carte rate for most volumes under 10 million. But the à-la-carte option still exists, and more importantly, you can leave SES without losing your infrastructure. Your suppression list, your templates, your event pipeline — all of it is yours, and none of it was in SES. SES was the send transport. Swapping transports is easier than re-extracting your data from a vendor’s database.
When Resend is the rational choice
This has been a lot of words about cost and lock-in, most of them in favor of SES. It would be dishonest to stop there, because Resend is the right choice for a large and specific set of circumstances. If you’re still weighing your options across multiple providers beyond just Resend and SES, How to choose a transactional email API covers the broader decision framework including deliverability, warm-up requirements, and when managed APIs make sense over running your own infrastructure.
You are pre-revenue or early, and your list is under 3,000 emails a month. Resend’s free tier is better than SES’s free tier (which does not exist — SES charges from the first email, and new accounts are in a sandbox). The daily cap of 100 emails will matter if you are doing onboarding sequences, but for a small SaaS sending password resets and weekly summaries, free and instant beats $1 and a day of setup.
You do not have AWS experience and you do not want to develop it. SES is cheaper, but cheap is not free. You pay the savings in time: reading the documentation, setting up IAM users, configuring SNS topics, wiring up bounce handlers, writing suppression logic, requesting production access. If nobody on your team has done this before, budget a day for the first working send and another day for polish. Resend is an API key and twenty minutes.
You are building in React or Next.js and you want email templates to be components. React Email is a legitimate technical advantage. Building email templates as JSX, with props and composition and hot reload, is a better developer experience than any other templating system in the email space. If your whole product is React and your team thinks in components, Resend is the path of least resistance.
Your sending volume is low and stable. If you send 50,000 emails a month and that number has been 50,000 for a year and will be 50,000 next year, the difference between $20 and $5 is $15 a month, or $180 a year. That is not enough money to justify infrastructure work unless you have nothing better to do. Pay Resend, focus on your product, and revisit the question when volume grows or when you are rewriting the email system for other reasons.
You want someone to blame. This is not a joke. If your email system breaks at 2am and it is Resend, you have a vendor to call (or a Slack channel to post in, if you are on the Scale plan). If your email system breaks at 2am and it is SES in your AWS account, the problem is your IAM policy or your Lambda function or your configuration set, and the person who fixes it is you. There is value in outsourcing the operational surface area, and that value is highest when your team is small and your oncall rotation is thin.
When SES is the rational choice
SES makes sense when cost matters, when you want to own the infrastructure, or when you are already operating on AWS and adding SES is less work than integrating a third-party API.
Your volume is above 100,000 emails a month, or you expect it to be soon. The cost gap at 100k is $90 vs $10. At 500k it is $350 vs $50. These gaps are large enough to pay for setup time and still come out ahead, and they recur every month. If you are past product-market fit and your email volume is growing, the arithmetic favors owning the infrastructure.
You want the bill on your AWS account. Some companies have budget for AWS infrastructure spend and a harder time getting approval for new SaaS subscriptions. If your finance or procurement process makes it easier to add $50 to your AWS bill than to sign a $350/month contract with a new vendor, SES is the path of least bureaucracy.
You are sending from multiple products or multiple teams, and you want a single consolidated bill. SES is per-email, across every application in your AWS account, with no per-project base fee. Resend is per account — if you have three products, you pay three times. SES scales across workloads without stepping up to new pricing tiers.
You want full control of the event pipeline and the suppression list. If deliverability matters enough that you want raw access to every bounce, every complaint, and every delivery event, SES gives you the firehose. SNS delivers the events to your endpoint in real time, and you decide what to log, what to alert on, and what to suppress. Resend gives you a webhook, which is enough for most use cases, but it is not the raw SES event — it is Resend’s interpretation of it.
You have compliance, data residency, or audit requirements that care about who operates the infrastructure. Some regulated industries or enterprise procurement processes have rules about where data is processed and who has access to it. If your AWS account is in scope for your SOC 2 or your HIPAA BAA or your enterprise security questionnaire, and adding a third-party email API is not, SES is the option that does not require a new vendor review.
You are already using AWS services and SES is the logical next integration. If your application runs on Lambda, your database is RDS, your secrets are in Secrets Manager, and your logs are in CloudWatch, adding SES is less marginal work than integrating a non-AWS API. IAM roles, VPC endpoints, and CloudFormation templates are things you already have — SES fits into the existing operational model.
You want to avoid a future migration. If you can see a future where you are sending a million emails a month and the cost gap will matter then, it is often less work to start with SES now than to build on Resend and migrate later. Migrations are expensive. The code changes, the DNS changes, the suppression list export, the template reformatting, the webhook handler rewrite — all of that is work you do not have to do if you never paint yourself into the corner.
The question the comparison is really asking
The comparison between Resend and SES is usually not “which one is better.” It is “do I want to operate infrastructure or pay someone else to do it.”
Resend is the version where you pay someone else. It costs more, it is faster to start, and your operational responsibility ends at the API boundary. When something breaks in Resend’s stack, Resend fixes it. When your deliverability tanks, you open a support ticket. You are paying to not think about SNS topics and IAM policies and bounce handlers.
SES is the version where you operate it yourself. It is cheaper, you own the whole stack, and the trade is that you also own every failure mode. When your send rate spikes and you hit a Lambda concurrency limit, you are the one watching CloudWatch and raising the quota. When your bounce rate climbs because you imported an old list, you are the one who has to go and clean the suppression table.
The lock-in question is downstream of this. If you are happy outsourcing email infrastructure forever, lock-in does not matter — you were never planning to leave. If you think you might want to bring email in-house at some point, or if you want the option to switch providers without a multi-month project, owning the infrastructure from the beginning is cheaper than migrating later.
What “run it on your own AWS” actually means in practice
If SES is starting to sound appealing but you are stuck on the phrase “wire up SNS bounce handlers” and “build your own suppression logic,” that is reasonable. The cost difference is real, but so is the work.
Here is what “send from your own AWS” requires as a minimum:
- An AWS account with billing configured and SES enabled in the region you want to send from.
- Domain verification — you publish three CNAME records for DKIM in your DNS, and SES verifies you control the domain. This is the same step every email provider requires.
- Production access approval — you apply through the SES console, describe your use case, your bounce handling plan, and where your addresses come from. Typically approved in 24 hours if you answer the questions concretely. What AWS actually wants is documented here.
- An SNS topic for bounces and another for complaints — these are AWS’s pub/sub queues. You create two topics, configure SES to publish bounce and complaint events to them, and subscribe your application endpoint to the topics.
- A Lambda function or an HTTPS endpoint that receives the SNS notifications, parses them, and writes the bounced or complained address to a suppression list.
- A suppression list — a DynamoDB table, a Postgres table, or any database you want. Before every send, check the address against this list. If it is suppressed, skip the send.
- The send call itself — the AWS SDK or SMTP. The SDK call is a few lines of code. SMTP is SMTP.
This is not trivial, but it is also not exotic. If you have deployed anything to AWS before — a Lambda, an RDS instance, an S3 bucket — you have done harder integrations. The work is front-loaded. Once the SNS topics and the suppression list are wired up, the ongoing operational burden is watching two CloudWatch metrics (bounce rate and complaint rate) and responding if they spike.
The alternative is to deploy Selva Mail, which is the whole stack above as infrastructure-as-code. You run the Terraform deploy in your AWS account, it provisions the Lambdas, the queues, the SNS topics, the suppression table, and the API, and you end up with a working email system that sends through your SES. You own the infrastructure, you get SES pricing, and you did not have to write the bounce handler.
That is what we built it for. The cost gap between Resend and SES is clear, but the effort gap is real, and “just use SES” is not useful advice if you do not have time to read the SES documentation and write a suppression system. Selva Mail is the thing that makes “send from your own AWS” a realistic option for a team that does not want to spend a week building email infrastructure.
The honest summary
Resend is more expensive and easier to start with. SES is cheaper and requires you to operate infrastructure. The cost gap is small at low volume and large at high volume. The lock-in risk is high with Resend and low with SES, because Resend owns the suppression list and the event pipeline and SES does not — you do.
If you are sending under 50,000 emails a month, the difference is not enough to optimize for. Use Resend if you want simplicity, use SES if you already have AWS experience or you expect to scale. Both are fine choices.
If you are sending over 100,000 emails a month, the math changes. Resend costs $90 and up, SES costs $10 and up, and the gap compounds every month. At that volume the question is not “which is easier” — it is “is the simplicity worth $80 a month, and will it still be worth $300 a month when I am at 500k?”
If you are sending over 500,000 emails a month and you are still on Resend, you are paying for convenience. That is a legitimate thing to pay for if you have the budget and the team is small. But you should know what the alternative costs, because the alternative is about a fifth of the price.
* SES pricing plans were introduced July 21, 2026. New accounts default to Essentials ($0.16/1k, includes VDM). À-la-carte ($0.10/1k, no monthly fee) remains available and switchable in the SES console. See AWS SES pricing and the July 2026 announcement.
Selva Mail runs on your AWS and sends through your SES. $497, once. See what’s included, or compare it directly to Resend’s pricing and model.
