/ Compare — EU alternative to Mailgun
EU region. Swedish parent. US company.
Mailgun offers an EU sending region, and its parent Sinch is Swedish — two things that sound European. But the operating entity is Mailgun Technologies, Inc., US-incorporated, running on AWS under the EU-US Data Privacy Framework. Residency is where the bits sit; jurisdiction is which law can compel them, and a US entity answers to the CLOUD Act wherever its data lives. EDP is an EU entity in Vienna with no US parent, on its own PowerMTA and KumoMTA. For residency, Mailgun's EU region works. For jurisdiction, the entity decides.
/ The honest answer
Mailgun offers an EU data region and its parent Sinch is Swedish — but the operating entity is Mailgun Technologies, Inc., US-incorporated, running on AWS under the EU-US Data Privacy Framework. Residency (where the data sits) is not jurisdiction (which law can compel it): a US-incorporated entity is reachable under the CLOUD Act wherever its servers are. EDP is an EU entity in Vienna, no US parent, on its own PowerMTA and KumoMTA. Honestly: for data residency Mailgun's EU region works, and Mailgun holds HIPAA/SOC 2 and 15 years of ISP relationships EDP does not claim; for jurisdiction, the US entity is what decides.
Region ≠ law
EU data centres set residency; the entity sets which law can compel access.
US entity
Mailgun Technologies, Inc. is US-incorporated under the EU-US DPF → CLOUD Act reach.
On AWS
Sending runs on AWS — a second US layer beneath the EU region.
EU-pure
EDP: EU entity (Vienna), own PowerMTA & KumoMTA, no US parent, no AWS.
/ 01 — Credit where it's due
Mailgun's EU posture is not a pretence. For residency, and for compliance certificates, it is genuinely strong.
Its EU region is real — data centres in Europe, including Germany, with a dashboard switch to keep customer data there. Its parent, Sinch, is a Swedish public company with a serious GDPR programme, a named Data Protection Officer, and a sister brand that was among the first in the world to earn an AFNOR certification for GDPR. Mailgun holds SOC 2 Type I and II, offers HIPAA-ready infrastructure with a Business Associate Agreement, and brings fifteen years of accumulated ISP relationships and built-in validation to the table. For a regulated buyer whose checklist is residency plus named certificates, that is a strong hand, and an honest comparison has to put it on the table first.
So this page is not the usual claim that a US provider is hiding something. Mailgun is unusually candid — it states in its own materials that it is based in the US with EU data centres. The disagreement is narrower and more interesting than a gotcha: it is about whether an EU region and a Swedish parent add up to EU jurisdiction, or only to EU residency with a US entity underneath. They are not the same thing, and which one your requirement actually needs is the question the rest of this page is built around. The candour cuts both ways: because Mailgun is open about being a US company with EU data centres, the comparison can be precise rather than accusatory — we are not exposing a secret, we are reading the structure Mailgun itself describes and asking what it means when the legal demand is real rather than hypothetical.
/ 02 — Four labels, one entity
A US court order passes through every EU-looking label and stops at the entity.
/ 03 — Which label stops the order?
Four of Mailgun's labels sound European. One decides the jurisdiction.
Tap a label
Each of Mailgun's EU-looking labels is real — but only one answers a US court order. Tap through them to see which.
And against EDP?
/ 04 — Residency vs jurisdiction
Where the data sits, and which law can take it, are two different facts.
Data residency answers a question of geography: in which country do the bytes physically rest? It is a real and sometimes contractual requirement, and Mailgun's EU region satisfies it — your data sits in European data centres. The trouble is that residency is often sold, and bought, as if it answered a second question it does not touch: which legal system can compel that data to be handed over? That is jurisdiction, and jurisdiction follows the entity rather than the server.
The principle is settled in the relevant law. A US-incorporated entity, or a subsidiary of one, is reachable under the US CLOUD Act regardless of where its servers sit; a US court can order it to produce data held in Frankfurt as readily as data held in Texas. Choosing a US provider's European region does not change the provider's legal obligations, because the obligation attaches to the company rather than the data centre. This is the same reasoning the Court of Justice of the European Union used when it struck down Safe Harbor and then Privacy Shield: the problem was never where the data sat, it was whose law could reach it. Each time, a US transfer framework was found inadequate not because the data centres were in the wrong place but because a US entity holding the data remained answerable to US surveillance law, and no contractual promise could override that. A region setting changes the first fact and leaves the second exactly as it was.
That is why an EU region with a US entity and US infrastructure underneath is residency wearing the costume of sovereignty. EDP is built the other way around. The entity is European — incorporated in Vienna, with no US parent in the structure. The infrastructure is EDP's own PowerMTA and KumoMTA, not a US hyperscaler's cloud. There is no transatlantic transfer framework in the path because no transatlantic transfer is happening. When the question is jurisdiction rather than geography, that difference is the entire answer.
/ 05 — The chain behind the region
An EU region is not one decision. It is a chain, and every link has a jurisdiction.
The dashboard switch that moves you to the EU region looks like a single choice, but behind it sits a sequence of entities, and the sovereignty question applies to each one rather than only to the first. Mapping that sequence is usually where the gap between residency and jurisdiction stops being abstract and starts being a list of names. A procurement reviewer who asks only "is the data in the EU?" gets a clean yes and stops; one who asks "and which company, in which country, can be compelled to produce it at each hop?" gets a longer and more revealing answer, because the second question is the one a region toggle was never designed to address.
For Mailgun the chain begins at Mailgun Technologies, Inc. — the US-incorporated entity that holds the contract — and runs on AWS, itself a US-incorporated provider reachable under the same CLOUD Act, before any further subprocessors are counted. Each US link is a separate data flow, and in audits of mid-market environments the unmapped subprocessor chain is one of the most common findings: the application sits on EU infrastructure, but the email goes through a US ESP, the error tracker is a US default, the CDN serving assets is US. An EU region quietly says nothing about how many of those layers underneath it are American — it answers only for where the bytes rest, not for whose law reaches each company that touches them.
EDP keeps the chain short and keeps it in the EU. The entity is European, in Vienna; the infrastructure is EDP's own PowerMTA and KumoMTA rather than a US hyperscaler's cloud; and there is no US provider in the default path to map, no transfer to legitimise, no second jurisdiction hiding one layer down. When a DPO or an auditor asks for the full subprocessor list and the country code of every link, the honest version of that list is short, and all of it reads EU. That is harder to engineer than flipping a region switch, which is rather the point of it being worth more.
/ 06 — When Mailgun's EU region is enough
For residency and certificates, Mailgun may be the right answer.
The jurisdiction argument only bites if jurisdiction is actually your requirement. For a large share of senders it is not, and in those cases Mailgun's EU region is a perfectly good answer — switching providers to chase a sovereignty guarantee you do not need would be effort spent on the wrong problem.
Stay with Mailgun's EU region when your requirement is residency or a named certificate. A contract or policy that says EU citizens' data must be stored in the EU is satisfied by the EU region on its face. A procurement gate that demands a signed HIPAA Business Associate Agreement, or a SOC 2 report an auditor will read, is one Mailgun can clear and EDP does not claim to. A team that values fifteen years of ISP relationships, built-in validation, and inbound routing above the incorporation of the entity has good reason to weigh those heavily. There are whole categories of sender — a US company with EU customers, a business whose compliance obligation is written as residency, a team whose hardest gate is a named certificate rather than a jurisdiction clause — for whom Mailgun is not a compromise at all but the better-matched tool. None of that is wrong, and a sovereignty pitch that ignored it would be dishonest.
EDP becomes the right answer when the word on the requirement is sovereignty rather than residency — when an auditor, a regulator, a public-sector procurement rule, or your own threat model asks not where the data lives but which government can compel it. At that point an EU region with a US entity and AWS underneath does not clear the bar, however good its certificates, because the bar is about the entity rather than the address on the data centre. That is the narrow, specific case this page is for, and outside it, the honest recommendation may well point back at Mailgun. The growing share of buyers for whom the case does bite — public-sector bodies, defence and healthcare suppliers, financial firms reading their obligations under newer EU rules on operational resilience and digital sovereignty — are exactly the ones whose contracts now spell out jurisdiction in words a region toggle cannot satisfy. For them the question has already moved from where the data lives to which government can compel it, and that is the line on which an EU entity and a US one genuinely diverge.
/ 07 — Side by side
Honest in both directions.
Mailgun wins certificates — HIPAA, SOC 2 — and brings fifteen years of ISP relationships and built-in validation. EDP wins jurisdiction, owned infrastructure, and a clean EU chain. On residency both reach the EU; on the entity behind it they part ways. Filter by what you actually care about.
/ 08 — Questions
On region, parent, and the entity.
Mailgun offers an EU region — isn't that EU-sovereign?
It is EU-resident, which is not the same as EU-sovereign, and the distinction is the whole point. An EU region means your data sits in European data centres — Mailgun runs facilities including one in Germany. Sovereignty asks a different question: which legal system can compel access to that data? That is decided by the jurisdiction of the entity holding it, not the location of the servers. Mailgun's operating entity is Mailgun Technologies, Inc., a US-incorporated company, and a US-incorporated entity is reachable under the CLOUD Act regardless of where its servers sit — a US court order can compel access to data stored in Frankfurt. The EU region protects residency. It does not change who the law can compel.
But Mailgun's parent, Sinch, is Swedish and EU — doesn't that resolve it?
Sinch is genuinely a Swedish, EU-based, GDPR-committed company, and that is a real point in Mailgun's favour over a provider with no EU presence at all. But the entity a court order is served on is not the parent — it is the operating subsidiary that holds the contract and the data, and that subsidiary is Mailgun Technologies, Inc., incorporated in the United States. An EU parent does not immunise a US-incorporated subsidiary from US law; the subsidiary remains subject to the jurisdiction it is incorporated in. So the Swedish parent improves the GDPR posture and the corporate story, but it does not move the entity that must answer a US legal demand out of US reach.
What is the EU-US Data Privacy Framework that Mailgun cites?
The Data Privacy Framework is a transfer mechanism — it provides a lawful basis for moving personal data from the EU to the US — and Mailgun Technologies, Inc. is certified under it. That certification is useful, but read what it implies: a company needs a transatlantic transfer framework precisely because it is a US entity receiving EU data. The DPF legitimises the transfer; it does not place the company outside US jurisdiction, and it has the same fragility every predecessor had — Safe Harbor and Privacy Shield were both struck down by the same court on the same reasoning. Operating under the DPF is confirmation that Mailgun sits on the US side of that bridge, not the EU side.
Does EDP have HIPAA or SOC 2 certifications like Mailgun?
Here the honest answer favours Mailgun, and it should be said plainly. Mailgun, through Sinch, holds SOC 2 Type I and II and offers HIPAA-ready infrastructure with a Business Associate Agreement on qualifying plans. If your procurement gate is a specific certification — a signed BAA for protected health information, a SOC 2 report your auditor will read — Mailgun may clear it where EDP does not claim to. EDP's argument is not certification parity; it is jurisdiction and infrastructure: an EU entity with no US parent, on its own PowerMTA and KumoMTA rather than shared AWS. If a named certificate is the hard requirement, weigh that honestly against the jurisdiction question rather than assuming one side wins both.
When is Mailgun's EU region actually enough?
When your requirement is genuinely data residency rather than jurisdiction. If a contract or policy says EU citizens' data must be stored in the EU, Mailgun's EU region satisfies that on its face. If you need a HIPAA BAA, Mailgun offers one and EDP does not. If fifteen years of accumulated ISP relationships and built-in validation matter more to you than the incorporation of the entity, Mailgun has them. The EU region stops being enough at the point your requirement is sovereignty — when an auditor, a regulator, or your own threat model asks not where the data lives but which government can compel it, because that is the question residency cannot answer and the US entity decides.
Why does running on AWS matter to this?
Because it adds a second US layer beneath the first. Independent profiles describe Mailgun's sending as running on AWS shared cloud, so even setting the operating entity aside, the infrastructure your mail moves through belongs to another US-incorporated provider subject to the same CLOUD Act reach. An EU region on AWS is EU data centres operated by a US hyperscaler — residency again, not jurisdiction. EDP removes both layers: it runs its own PowerMTA and KumoMTA on infrastructure it operates, not a slice of a US hyperscaler's cloud, so the chain from your send to the metal stays inside the EU rather than resting on a US provider at the bottom.
Isn't this just fear-mongering about the CLOUD Act?
It is a documented legal point, and notably Mailgun itself makes half of it. In its own writing on data privacy, Mailgun acknowledges that a company forced to comply with US intelligence or law-enforcement requests for EU citizens' data 'may not be able to deny access' — and argues that its EU data centres protect against that. The first part is correct; the second conflates residency with jurisdiction. EU data centres do not place a US-incorporated entity beyond a US court's reach. So this is not speculation about a hypothetical: it is the same reasoning the EU's highest court used to strike down two transfer frameworks, applied to the entity that actually holds your data. The disagreement is narrow — about whether residency cures it — and on that narrow point the law is clear.
How do I move from Mailgun to EDP?
The technical path is short because EDP speaks the same protocols. Your application sends over SMTP or an API, and you repoint that sending credential at EDP; for many Mailgun integrations the change is configuration rather than code. We provision and warm dedicated IPs you own, and production traffic ramps on a gradual curve so reputation builds cleanly. The part that changes underneath is the part this page is about: your mail moves from a US-incorporated entity on AWS with an EU region, to an EU entity on its own infrastructure under EU jurisdiction. Migration assistance is included, and the suppression and event data you rely on comes across rather than being left behind.
Keep the EU region if residency is the requirement. Move the entity if sovereignty is.
If you need data residency or a named certificate, Mailgun's EU region may be right. When the requirement is jurisdiction — an entity a US court cannot compel — point your sending at EDP: an EU entity in Vienna, own PowerMTA and KumoMTA, dedicated IPs you own, no US parent and no AWS underneath. Tell us your volume and we'll size it.
Book infrastructure reviewRelated capabilities