Does Resend Use Amazon SES? What Actually Powers It (2026)

Short answer: yes, Resend runs on Amazon SES. This isn't secret. You can verify it yourself in the DNS records Resend asks you to publish, in the Received headers of any message it delivers, and in things the Resend team has said on podcasts.

The more useful question is what that actually means for your stack. If Resend is “just” SES with a React wrapper, why pay the markup? Is deliverability worse with a provider in between? What happens when Resend has an outage? The rest of this post answers those one by one.

The evidence: how to confirm it yourself

You don't need an internal leak or a Hacker News thread to know Resend sits on top of SES. The proof is visible in three places.

1. The DNS records Resend asks you to publish

When you verify a sending domain in Resend, the dashboard hands you an SPF record and a DKIM record. Both point at AWS.

; SPF record published as TXT on send.yourdomain.com
send.yourdomain.com.  TXT  "v=spf1 include:amazonses.com ~all"

; DKIM record published as CNAME
resend._domainkey.send.yourdomain.com. CNAME resend-abcdef.dkim.amazonses.com.

Both records reference amazonses.com directly. SPF include:amazonses.comauthorizes Amazon SES's IP ranges to send on your behalf. The DKIM CNAME delegates signature verification to dkim.amazonses.com, which is the SES public key service.

2. The Received headers on delivered mail

Open any email you've sent through Resend in Gmail and click “Show original”. Among the routing hops you'll see something like this:

Received: from a8-42.smtp-out.amazonses.com (a8-42.smtp-out.amazonses.com. [54.240.8.42])
    by mx.google.com with ESMTPS id ...
    for <user@example.com>
    (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256);
    Sun, 20 Apr 2026 10:42:11 -0700 (PDT)

That smtp-out.amazonses.com hostname and the AWS-owned IP (the 54.240.0.0/16 block belongs to Amazon SES) are enough on their own. That is the last hop before Google accepted the message.

3. The Resend team says so

Co-founder Zeno Rocha has talked about the SES underlayer on podcasts and on X. The pitch has never been “we built a new email provider.” It's “SES is powerful, the DX is awful, we fixed the DX.”

What this means for your stack

Knowing Resend rides on SES changes a few practical calculations.

Deliverability: inherited, not worse

SES has a solid inbox-placement reputation, and because Resend sends from SES IPs, every email you send inherits it. It's the main reason you can start sending on day one without warming up a dedicated IP.

Your domain reputation still matters. You need clean lists, good content, and proper authentication. But the IP side is solved for you.

Pricing: you pay a markup, for real reasons

SES itself is very cheap: ~$0.10 per 1,000 emails. Resend charges more because you're also paying for:

• The API, dashboards, and webhooks
• React Email integration and preview tooling
• Account-level reputation monitoring, bounce handling, and suppression lists managed for you
• The fact that you don't have to glue together IAM policies, Configuration Sets, SNS topics, and Lambda functions to get working email

Under ~1 million emails a month, the markup usually pays for itself. Above that, the math tilts toward SES direct (if you can absorb the DX cost).

Lock-in: smaller than you think

The common worry is “if Resend goes down or raises prices, I'm stuck.” Not really. The move to raw SES is mechanical. Both sit on the same sending infrastructure, so your domain reputation, DKIM/SPF setup, and deliverability profile stay intact. What changes: the SDK call, the webhook handler, and the suppression-list plumbing.

Wrap your sends in a single lib/email/send.ts helper (most Next.js teams already do), and switching providers is a 30-minute job.

Resend vs raw SES: where the DX gap hurts

If Resend is “just” SES with a nicer wrapper, can you skip it and save the markup? Technically, yes. Here's what you rebuild if you do:

When raw Amazon SES actually wins

A small group of teams should skip Resend. The profile is roughly:

• Volume above ~1M emails/month, where the markup becomes real money
• Already deep in AWS, with an ops team that lives in CloudWatch, IAM, and SNS
• Regional compliance needs (sending from eu-west-1 for EU data residency without a separate DPA)
• Enterprise procurement that makes adding an AWS service cheaper than onboarding a new vendor

For everyone else, especially Next.js teams building their first few email flows, Resend gets you sending faster with less code.

FAQ

Does Resend use Amazon SES infrastructure?

Yes. DNS records, SMTP headers, and public statements from the Resend team all confirm SES is the sending backbone.

Which AWS region does Resend send from?

Multiple SES regions, including us-east-1 and European regions for EU customers. The region affects IP geography and latency, not the API you use. Resend hides the region from you.

Is Resend just a reseller of SES?

No. A reseller means rebranded access to the SES API. Resend has its own API, webhooks, dashboards, suppression lists, and tooling. SES is the sending layer; everything on top of it is Resend's.

Is deliverability different from using SES directly?

No meaningful difference at the IP layer. Same SES IPs, same AWS reputation. Resend also manages account-level signals (bounce rate caps, complaint thresholds), so you're less likely to get suspended for a noisy sender sharing your pool.

Can I switch from Resend to SES later?

Yes. Your domain, DKIM/SPF, and sender reputation transfer because the underlying IPs are shared. You rewrite the send call and the webhook handler. That's most of it.

Bottom line

Resend uses Amazon SES. The Resend team says so openly. What you're paying for isn't a sending engine (that's SES's job). It's the API, the React Email SDK, the webhooks, the dashboards, and the rest of the plumbing you'd otherwise rebuild on top of AWS.

If you're on Next.js + React Email, Resend is the fastest path to shipping. Skip the IAM policies, skip the CloudWatch dashboards, skip the HTML-string render step. And while you're at it, skip rebuilding every transactional template from scratch:

Prefer the 30-second version? Resend vs SendGrid vs Amazon SES for Next.js has the head-to-head decision table.