EU-Sovereign Email Infrastructure

European senders have spent the years since Schrems II discovering that “our data is in the EU” is not the reassurance it sounds like. An EU server address satisfies one layer of sovereignty and leaves two others open — and the layer that actually determines whether a foreign government can reach your data is not where the servers sit but who controls the company operating them. This page is an honest account of what EU-sovereign email infrastructure genuinely requires, why the major “sovereign cloud” offerings do not deliver it, and — with equal honesty about our own position as a Canadian provider — where Canadian, CLOUD Act-free hosting is a sound option for European senders and where only EU-resident infrastructure will do.

What does EU-sovereign email infrastructure actually require?

Sovereignty in the EU context has three layers that are routinely collapsed into one, and keeping them apart is the whole analysis. Data residency is where the data physically lives — an EU data centre satisfies this. Data sovereignty is which legal system governs the data. Jurisdictional control is who can compel access to it. A US-owned provider running an EU data centre gives you the first layer while leaving the third wide open: the data is geographically in Europe but remains legally reachable by US government demands. Genuine EU-sovereign infrastructure closes all three — the data resides in the EU, is governed solely by EU law, and is held by a provider no foreign authority can compel. Concretely, that means either an EU-incorporated, EU-operated provider with every data path in the EU — primary servers, backups, logs, metadata, and support access — or customer-controlled encryption where the EU customer holds the keys outside any foreign provider’s infrastructure. An EU address alone delivers residency and nothing more.

Why isn’t EU residency enough after Schrems II?

Because the Court of Justice, in Schrems II, made residency necessary but explicitly insufficient. GDPR contains no blanket EU-storage mandate, but its Chapter V transfer restrictions push hard toward EU storage in practice. The 2020 ruling invalidated the Privacy Shield framework and established that geographic location cannot substitute for jurisdictional control: any exporter relying on Standard Contractual Clauses to a non-EU provider must run a Transfer Impact Assessment, and that assessment must conclude — grounded in technical controls rather than contractual promises — that a foreign demand would not yield readable EU personal data. The reason contracts cannot close the gap is structural: a contract binds the two parties to each other, but it cannot override the legal obligations each party owes to its own sovereign government. So an EU-located server operated by a US-controlled company fails the standard, because a valid CLOUD Act demand reaches the data regardless of the EU address. Architecture, not paperwork, is what satisfies Schrems II — which is why European supervisory authorities have, for years, called the CLOUD Act a problem that contractual measures alone cannot fix.

The moment the debate ended

For a long time the question of whether the CLOUD Act truly reached EU-stored data was treated as arguable. That ended in June 2025. At a French Senate hearing, Microsoft’s French subsidiary confirmed under oath that it could not guarantee EU data would be protected from US government access — even for data stored in France, under a French-marketed sovereign offering, including sensitive government health records. A hyperscaler stating on the record that no technical or contractual arrangement could override the CLOUD Act removed the last comfort of the “our data is in Frankfurt, so we’re fine” position. The testimony crystallized what EU regulators — the EDPB, the CNIL, the BfDI, the Dutch DPA — had been saying for years: the CLOUD Act is a third-country law that cannot be squared with GDPR through contracts, and a US-controlled provider’s EU region does not change the provider’s jurisdiction. After that, “sovereign cloud” branding from US companies became, for the jurisdictional layer, a claim the companies themselves had publicly disavowed.

Does a US hyperscaler’s “sovereign cloud” qualify?

For residency and operational controls, partly; for jurisdiction, no. Since Schrems II, every US hyperscaler has launched an EU-boundary or sovereign offering — EU regions, EU-only operational staff, separate EU legal entities, sometimes local partnerships. These genuinely improve data residency and reduce some operational exposure, and for lower-sensitivity data they may be a reasonable choice. But the jurisdictional layer is untouched, because the EU legal entity remains a subsidiary of a US corporation, and jurisdiction follows the corporate parent, not the data centre. The parent is subject to the CLOUD Act, and so is the data it ultimately controls. This is why EU public-sector procurement increasingly specifies infrastructure “not subject to third-country law with extraterritorial reach,” and why regulated buyers under DORA and NIS2 now ask the question directly. A US hyperscaler’s sovereign cloud can satisfy a residency checkbox; it cannot satisfy a buyer whose actual requirement is that no foreign government can compel the data.

The regulatory stack you’re actually navigating

EU sovereignty is not one law but a converging stack, and the penalties are why it is now a board-level question. GDPR and Schrems II govern personal-data transfers, with fines up to 4% of global turnover. The EU Data Act adds protection for non-personal data and requires providers to challenge unlawful foreign-access demands and disclose their infrastructure locations and technical measures. NIS2 makes operators of essential services assess their cloud providers’ sovereignty posture as part of mandatory supply-chain security, and adds management liability. DORA imposes parallel obligations on financial entities. The EU AI Act and the broader European Technological Sovereignty Package, published in June 2026, push the same direction — reducing strategic dependence on non-EU infrastructure. The practical consequence is that for high-sensitivity and sector-regulated data, the acceptable threshold for foreign-access exposure has dropped close to zero, and “our provider signed a DPA” no longer answers the question. The standard now is demonstrable evidence — architecture, key custody, audit logs, and an honest Transfer Impact Assessment.

Two real paths to EU sovereignty

When EU sovereignty is genuinely required, two architectures actually deliver it, and it is worth being clear about both. The first is an EU-incorporated, EU-operated provider holding all data paths in the EU under EU law — the cleanest answer for data that must stay in the EU and be governed by EU law alone, because there is no foreign parent to compel and no foreign-held copy. The second is customer-controlled encryption: the EU customer holds the keys in its own European infrastructure, the provider never possesses decryption capability, and a foreign demand therefore yields only ciphertext — satisfying both the EU’s technical-measures requirement and Schrems II’s supplementary-measure standard at once, even where part of the stack involves a foreign provider. Both share the same principle that residency alone does not: they make foreign access technically impossible rather than merely contractually prohibited. Which path fits depends on your data classification, your sector rules, and whether your requirement is “in the EU specifically” or “out of foreign reach.” That distinction is exactly where an honest provider has to draw the line on what it can and cannot offer.

Where Canadian infrastructure fits — and where it doesn’t

Here we are deliberately honest about our own position, because the whole page would be worthless otherwise. MCSNET is a Canadian provider operating in Toronto — we are not an EU-resident, EU-incorporated company, and we will not pretend Canadian hosting is EU-sovereign, because it is not. What Canadian infrastructure genuinely offers EU senders is two specific things. First, it is outside US jurisdiction, so it is not subject to the CLOUD Act — the very exposure that breaks US-hyperscaler sovereign clouds. Second, Canada holds an EU adequacy decision covering PIPEDA-regulated commercial organizations, so transfers of EU personal data to such Canadian organizations are recognized as adequate and do not require the Standard Contractual Clauses and TIAs that transfers to the US do. For an EU sender whose real driver is escaping US-style foreign-access exposure under a lawful transfer basis, that combination is a clean, CLOUD Act-free option. What it is not is EU-resident: your data lives in Canada, governed by Canadian law. So where your requirement is that data must physically remain in the EU — certain government, health, NIS2-essential categories, or a specific DPA or contractual mandate — Canadian hosting does not meet it, and the right answer is an EU-resident provider. We would rather lose that work than mislabel what we offer.

Which data can lawfully leave the EU?

The decision is best made by classifying data before choosing infrastructure. The most restrictive categories carry the strongest residency expectations and, for some, an effective requirement for EU-controlled infrastructure regardless of safeguards: GDPR Article 9 special-category data such as health, client financial and legal records, government and defence-adjacent data, critical-infrastructure operational data under NIS2, and data about identifiable minors. For this tier, EU-resident infrastructure is the safe and often mandatory answer. Less critical but still sensitive data — internal business communications, B2B CRM records, analytics on identifiable users — can frequently be handled under an adequacy decision or appropriate safeguards, which is precisely where an adequacy-covered Canadian option becomes both lawful and CLOUD Act-free. Low-risk and public data can live wherever is practical. For most EU senders, the list and subscriber data behind your email is ordinary commercial personal data, which often sits in that middle tier — but the only way to be sure is to classify it against your sector rules first. Pick the data tier, then pick the jurisdiction; doing it in that order is what keeps the choice defensible.

How we help EU senders, honestly

With MCSNET, the help starts with telling you the truth about your own requirement. If your driver is escaping US and CLOUD Act exposure for ordinary commercial personal data, our Canadian infrastructure in Toronto gives you a CLOUD Act-free home under Canadian law, on dedicated IPs, with the deliverability stack and the GDPR-aligned sending practices your European recipients require — and Canada’s adequacy decision gives you a lawful transfer basis without SCCs. If your requirement is that data must remain in the EU, we will say so directly and point you toward EU-resident infrastructure rather than dress up Canadian hosting as something it is not. Either way, you get an honest Transfer-Impact-Assessment-grade account of where your data would live, which laws would govern it, and who could compel it — the same clarity the post-Schrems II standard demands. We treat your data classification as the first step, not an afterthought, because the right infrastructure decision depends entirely on which tier your email data falls in.

# eu sender · sovereignty triage · classify first
layer 1       residency  — where does data sit?
layer 2       sovereignty — which law governs it?
layer 3       jurisdiction — who can compel access?
test          jurisdiction follows the parent, not the box
us hyperscaler EU region · still CLOUD Act reachable  fail L3
canada (us)   adequacy + outside US reach  lawful · CLOUD Act-free
must stay EU  gov / health / NIS2  → EU-resident only
rule          classify data tier → then pick jurisdiction

Why work with us?

Because we will tell you the truth about EU sovereignty, including the parts that do not sell our own service. Plenty of providers will badge an offering “sovereign” and let you assume more than it delivers; we draw the line explicitly between residency, sovereignty, and jurisdictional control, and we are candid that Canadian hosting is CLOUD Act-free and adequacy-covered but not EU-resident. For the large set of EU senders whose real need is escaping US foreign-access exposure under a lawful basis, our Canadian infrastructure in Toronto is a clean, honest fit with full deliverability and GDPR-aligned sending. For the set whose data must stay in the EU, we will tell you that plainly and not take the work. That honesty is the point: a sovereignty decision built on an accurate account of jurisdiction is the only kind that survives a regulator’s question.

Who this is for, and who it is not

It is for EU senders whose primary concern is foreign-access exposure — escaping US CLOUD Act and FISA reach for ordinary commercial personal data — and who can lawfully use an adequacy-covered third country, for whom Canadian, CLOUD Act-free infrastructure is a clean and honest option with a lawful transfer basis. It is for teams who want a clear, Transfer-Impact-Assessment-grade account of where their data lives and who can compel it, rather than a “sovereign” label that does not survive scrutiny. It is explicitly not for data that must legally remain in the EU — GDPR Article 9 health data, government and defence-adjacent records, NIS2-essential operational data, or anything a DPA, sector rule, or contract requires to stay EU-resident — for which only an EU-incorporated, EU-resident provider will do, and we will tell you so. EU-sovereign infrastructure is the European counterpart of CLOUD Act-free hosting, resting on the same data-residency and jurisdictional analysis and supporting GDPR-compliant sending. Classify the data first, judge the provider by its corporate jurisdiction rather than its server map, and the sovereignty decision becomes one you can defend.