Skip to content

/ Compare — Resend

A beautiful API. Two US layers underneath.

Resend's developer experience is genuinely one of the best in email — and for EU sovereignty it is the wrong shape, because a clean API does not change where your jurisdiction lives. Resend is a US company, and it sends on Amazon SES, which is US too. So your mail crosses two layers under the CLOUD Act, and an EU sending region relocates the bytes without touching the law. EDP is the EU-native answer: one stack, one EU entity, our own MTAs, no US parent.

/ Quick answer

Resend has one of the best developer experiences in email — but for EU sovereignty it is structurally the wrong choice. Resend is a US-incorporated company, and it sends on Amazon SES, which is also US — so your mail passes through two US-jurisdiction layers, each within reach of the CLOUD Act. Choosing an EU sending region keeps bytes in Europe but does not change the law, because jurisdiction follows the company, not the datacentre. Email Delivery Platform is the EU-native alternative: a single EU entity running its own PowerMTA and KumoMTA, no US parent and no resold US engine — one European layer instead of two American ones, at SES-level economics.

  • DX is real

    Resend's API and React Email are excellent. This is about jurisdiction, a different axis the DX doesn't touch.

  • Two layers

    A US API company sending on a US-owned engine. Two CLOUD Act touchpoints, neither in your control.

  • Region ≠ law

    An EU sending region moves the bytes, not the jurisdiction. Residency is not the same as full EU residency under EU law.

  • One EU stack

    EDP is one EU entity on its own MTAs — zero US layers, full EU residency, SES-level cost.

/ 01 — Credit where due

Resend earned its reputation. That is not the question here.

It is worth being clear-eyed about what Resend got right, because the case for an EU-native alternative is weaker if it pretends otherwise. Resend built one of the cleanest developer experiences in transactional email: a well-designed API, first-class SDKs, React Email for writing templates as components, and onboarding that gets a developer from signup to a working send in minutes. For a team whose first priority is shipping product, that polish is real value, and a lot of engineers reach for Resend precisely because it removes friction on day one.

The point of this page is that developer experience and legal jurisdiction are two different axes, and they are decided separately. How pleasant the API feels has no bearing on which country's courts can compel the company behind it. A sovereignty requirement — the kind that arrives with a regulated sector, a public-sector contract, or a data protection officer who has to sign off on your processors — is settled entirely on the jurisdiction axis. On that axis, the quality of the SDK is not an input, and Resend's shape becomes the problem rather than the selling point.

So this is not a teardown of Resend's product. If you are choosing on developer experience and you have no sovereignty constraint, Resend is an easy recommendation and EDP is not trying to talk you out of it. The argument begins only when sovereignty enters the requirements, because that is the moment a clean API stops answering the question being asked — and the structure underneath the API starts to matter more than the surface on top of it.

/ 02 — Count the layers

Two stacks. Count the layers that answer to US law.

Sovereignty is not about the layer you see — the API — but about every layer beneath it. Switch between the two stacks and read each layer's jurisdiction. The number that matters is at the bottom: how many companies in the path are subject to the US CLOUD Act.

Layers under the CLOUD Act

2

Stack composition reflects public descriptions of each provider as of 2026; Resend's use of Amazon SES is documented, and the CLOUD Act analysis is general, not legal advice. Confirm your own obligations with counsel.

/ 03 — The region trap

"Sent from an EU region" is a billboard, not a building.

The reflex, once the jurisdiction question lands, is to reach for an EU region — and it does not close the gap. Jurisdiction follows the company, not the datacentre: a US-headquartered provider can be compelled under the CLOUD Act to produce data held even on European servers. Picking eu-west-1 relocates the bytes and leaves the legal exposure exactly where it was, because the entity that can be served the order has not changed.

There is a second, quieter gap inside the phrase itself. "Sent from an EU region" describes where a message leaves from; it does not promise full EU residency, where the content, metadata, logs, and analytics all stay in the EU. The strong version of EU residency passes a legal review; the weak version — mail sent from Europe while logs, backups, and support tooling sit in a US region — is a marketing line that an auditor will take apart. European authorities have gone further still: the prevailing reading treats access from a third country as a transfer in the legal sense even when no data physically crosses a border.

This is why the region setting cannot carry the weight people put on it. It answers a question about geography while the obligation is about control, and the two come apart precisely where it counts — under audit, under procurement, under a regulator's transfer assessment. A provider whose structure puts a US company in the path has a region to offer, but not jurisdiction, and on this axis only the second one is the answer.

/ 04 — One EU stack

An EU stack, not an EU region on a US one.

Resend stack Resend, Inc. US jurisdiction Amazon SES US jurisdiction EU region US-controlled 2 layers under US law EDP stack Email Delivery Platform EU jurisdiction Own PowerMTA & KumoMTA EU jurisdiction Full EU residency EU jurisdiction 0 layers under US law

EDP collapses the two layers into one and makes it European. It is a single EU entity with no US company in the ownership chain, and it runs its own PowerMTA and KumoMTA rather than reselling Amazon SES — so there is no US API provider in front and no US-owned engine underneath. Run the CLOUD Act's test down the path and it returns no at every step, because the path has one step and that step is incorporated in Europe. Sovereignty stops being a control you configure and becomes a fact of how the company is built.

You keep a modern way to send. EDP exposes a clean API and SMTP with proper SDKs, so the integration feels familiar to anyone coming from a contemporary email service, and full EU residency means the content, metadata, and logs stay in the EU under EU law rather than being sent from it. The honest line is that EDP trades a little of Resend's developer-experience shine for owned infrastructure and real jurisdiction — and because it owns the MTAs instead of marking up someone else's, it does that at SES-level economics with pricing that does not move on a US growth-stage schedule.

/ 05 — Side by side

Resend vs an EU-native alternative.

Resend wins on developer experience and on pure shipping speed for a US-market app, and the matrix says so plainly. The EU-native case is jurisdiction as structure, owned infrastructure, and pricing that holds — the columns where two US layers and a region setting leave a sovereignty review unsatisfied.

Filter:
Dimension Resend This platform Managed infrastructure
Developer experience Their edge Best-in-class — React Email, clean API Clean API and SDKs, less polish
Time to first send Their edge Minutes — a real strength Fast, familiar modern API
Company jurisdiction US-incorporated EU entity, no US parent
Sending engine Amazon SES (US-owned) Own PowerMTA & KumoMTA (EU)
US-jurisdiction layers Two — provider and engine Zero
Data residency EU sending region, not full residency Full EU residency, EU law
Pricing trajectory Roughly doubled in Oct 2024 SES-level, stable and predictable
Infrastructure ownership Reseller layer on a hyperscaler Owns the stack end to end
Pure shipping speed, no sovereignty need Their edge Hard to beat for a US-market app A move worth it when EU jurisdiction is required

/ 06 — When Resend wins

When Resend is the right call — and it often is.

If you have no sovereignty requirement, Resend is a strong default and switching away from it would be solving a problem you do not have. A US-market product, an early-stage team optimizing for shipping speed, an app whose GDPR obligation is satisfied by a signed DPA and a standard transfer mechanism — for all of these the two-layer structure is an invisible technicality, and the developer experience is a daily, tangible benefit. Buying sovereignty you will never be asked to demonstrate is its own kind of waste.

The EU-native case begins at a specific line: when something or someone will test your jurisdiction in writing. A regulated sector under DORA or NIS2, a public-sector tender with sovereignty clauses, an enterprise client whose security review asks where your email data lives and who can be compelled to hand it over, a DPO who cannot sign off on stacked US processors. At that line, a beautiful API over two US layers stops passing, and a single EU entity on its own infrastructure stops being a luxury and becomes the requirement. Knowing which side of that line you are on is the whole decision.

/ Common questions

What developers ask about Resend and EU sovereignty.

Isn't Resend's developer experience better than most alternatives?

Yes, and pretending otherwise would waste your time. Resend built one of the cleanest sending workflows in the market — a well-designed API, first-class SDKs, React Email for composing templates in code, and documentation that lets a developer send their first message in minutes. If developer experience is the axis you are optimizing, Resend earns its reputation. This page is not arguing that EDP out-ships Resend on DX. It is pointing out that developer experience and legal jurisdiction are different axes, and a sovereignty requirement is decided on the second one, where a clean API changes nothing.

Resend runs on Amazon SES — why does that matter for sovereignty?

Because it stacks two US-jurisdiction layers under your mail instead of one, and the CLOUD Act applies at each. Resend is a US-incorporated company, which already brings it within the Act's reach; underneath, it sends on Amazon SES, and Amazon is also a US company. So a message you send through Resend passes through a US API provider running on US-owned infrastructure. For an ordinary product that is invisible and irrelevant. For a sovereignty requirement it is the opposite of what you want: not one foreign-jurisdiction touchpoint to assess, but two, neither of which you control.

Doesn't sending from an EU region fix the jurisdiction problem?

It fixes location, which is not the same thing, and the gap is exactly where compliance reviews fail. Sending from an EU region keeps the message on European servers, but jurisdiction follows the company, not the datacentre — a US-headquartered provider can be compelled under the CLOUD Act to produce data held even on EU servers. There is also a quieter trap: 'sent from an EU region' is not the same as full EU residency, where content, metadata, logs, and analytics all stay in the EU. European authorities increasingly treat access from a third country as a transfer in the legal sense even when no data crosses a border. A region setting is a billboard; jurisdiction is the building behind it.

What makes EDP a one-layer EU stack instead of two?

EDP is a single EU entity running its own sending infrastructure, with no US company anywhere in the path. There is no US API provider in front and no US-owned engine underneath, because EDP operates its own PowerMTA and KumoMTA rather than reselling a hyperscaler's SES. The CLOUD Act's test — is a company in this chain subject to US jurisdiction — returns no at every layer, because there is one layer and it is European. That is the structural difference: not an EU region bolted onto a US stack, but an EU stack.

Will I lose the modern workflow if I move off Resend?

You give up some polish and you should price that in honestly, but you do not drop back to raw infrastructure. EDP offers a clean sending API and SMTP with proper SDKs, so the day-to-day integration is familiar to anyone who has used a modern email API. What you will not find is a feature-for-feature clone of Resend's DX, because EDP's edge is sovereign owned infrastructure rather than developer-experience polish. The honest framing is a trade: a small step back on DX shine for a large step forward on jurisdiction and infrastructure ownership. If sovereignty is on your list, that trade is the entire point; if it is not, it may not be worth making.

Can I keep React Email and my current templates if I move?

Largely yes, because React Email is an open-source library rather than a Resend-only feature. It renders your components to HTML that any provider can send, so your templates stay yours and keep working when the transport underneath them changes. What you swap is the send call: instead of Resend's SDK you point at EDP's API or SMTP, both of which take standard HTML and ship typed SDKs. The composition layer does not change; only the layer that hands the finished message to the network does. A migration stays a transport change rather than a template rewrite.

What does a sovereignty or procurement review actually check?

It checks the things a region setting cannot answer on its own. A serious review asks where message content, metadata, logs, backups, and analytics physically reside; which legal entity controls each one and under whose law; whether any company in the chain can be compelled by a foreign authority; and whether you can produce written evidence — a DPA, a sub-processor list, a transfer assessment — rather than a landing-page claim. A US API provider on a US engine fails several at once; a single EU entity on its own infrastructure answers all of them the same way: European, documented, no foreign company in the path.

How does the cost compare?

Resend is priced for its experience, and that pricing has moved — its plans roughly doubled in October 2024, which is the kind of repricing a venture-funded US SaaS can do on its own schedule. EDP runs its own PowerMTA and KumoMTA rather than marking up someone else's SES, which is what lets it offer SES-level sending economics with stable, predictable pricing instead of experience-tier markups. So the comparison is not sovereign-but-expensive against cheap-and-easy. It is a modern EU-native workflow at a cost profile built to stay close to raw sending, from a provider whose prices are not subject to a US growth-stage repricing cycle.

Keep a modern workflow. Lose both US layers.

Tell us what you send and what is driving the sovereignty question — a regulator, an enterprise security review, a DPO who won't sign off on stacked US processors. We'll map an EU-native setup honestly, say plainly if Resend already satisfies your obligation, and if it doesn't, show you a one-layer EU stack that keeps a clean API.

Book infrastructure review