Email data residency: region, jurisdiction, and the difference

Data residency is a commitment about where the bytes of your mail physically rest — which country holds the message bodies, the attachments and their backups when nobody is looking at them. Jurisdiction is a different property: it follows whoever controls that storage, and it can point somewhere else entirely. A bucket in Frankfurt operated by a US-incorporated company has EU residency and US jurisdiction simultaneously, and both statements are true at once.

Keeping those two apart is the whole discipline. Nearly every disappointing procurement conversation I have watched about email came from a requirement that specified one and assumed it had bought the other.

What is data residency, and how is it different from jurisdiction?

Residency is geography. Jurisdiction is corporate. Region is a property of the disk; jurisdiction is a property of the company holding the credentials to it.

The reason they diverge is that legal reach attaches to entities. A US provider that can technically produce a copy of your mailbox is treated as controlling it wherever the disk lives — that is the operating principle of 18 U.S.C. § 2713, added by the CLOUD Act in 2018. Symmetrically, a provider incorporated only in the EU is outside that statute even for data it happens to keep on hardware in Virginia.

So a serious residency statement has two parameters, not one: which region the bytes occupy, and which company, incorporated where, holds the ability to read them. Vendors quote the first because it is a dropdown. The second is a structural fact about the vendor, and it is not something they can change for you.

What do data-residency requirements actually demand?

Rarely just a region. When I read the real requirements behind an “EU data residency” line item, they usually bundle four things: storage location, a named list of sub-processors with their locations, limits on remote support access from third countries, and a documented answer to the transfer question.

They come from specific places. Public sector procurement is the big one — national and municipal bodies working under rules that predate cloud and were written assuming premises. Regulated industries add sectoral layers: German BSI C5 attestation for cloud services, French HDS certification for anything touching health data, EBA outsourcing guidelines that require banks to keep a register of where each function runs and to preserve audit rights.

The interesting outlier is France’s SecNumCloud, whose 3.2 revision moved past geography into corporate structure — headquarters in the EU, limits on non-EU capital control, immunity from extra-EU law as an explicit criterion. Whatever you think of the policy, it is the framework that names the actual variable. Location is a proxy; control is the thing being bought.

What almost never appears in these requirements is GDPR itself. The regulation permits transfers outside the EEA under Chapter V with the right safeguards. “EU only” is a policy choice made on top of it, usually because the safeguards became hard to argue after 2020.

Why do “EU region” checkboxes so often under-deliver?

Because the guarantee is scoped to a slice of the data, and email generates a great deal that falls outside the slice.

Read the fine print of any major region commitment and you find a defined category — “customer content” or “primary data at rest” — applying to an enumerated list of covered services. What sits outside is predictable: search indexes, spam and threat telemetry, delivery and authentication logs, abuse signals, directory and identity data, billing records, and every support ticket where an engineer pasted a header dump. Microsoft spent 2023 to 2025 extending its EU Data Boundary in phases precisely because pseudonymised personal data and support data were not covered by the first phase.

Three more gaps recur. The region choice is frequently a paid add-on rather than a default. Administrative and tenant metadata often has no region option at all. And support follows the sun, so a mailbox with impeccable residency is routinely troubleshot from a timezone the annex never mentioned.

None of that is deception. It is just a narrower promise than the buyer heard.

Which parts of email can have a region, and which cannot?

Storage can. Transport cannot. That line is worth drawing early, because it decides what residency is even capable of protecting.

The archive at rest — bodies, attachments, backups, and usually the search index — is genuinely placeable. Everything else about mail resists it. Inbound SMTP crosses whatever networks lie between the sending host and your MX, negotiating opportunistic TLS with no route control on your part. Spam filtering has to read the message, so the filter’s memory holds plaintext somewhere. Your correspondents keep their own copies under their own laws, and always will.

This is not a reason to give up on residency. It is a reason to be precise about it: residency is a property of your archive, not of your conversations.

How does storage-level custody turn residency into a setting?

By moving the archive into storage you own, at which point residency stops being a vendor promise and becomes a parameter you set when you create the bucket.

Object storage exposes region as a first-class choice: you pick it, you can see it, you can verify it with an API call. Jurisdiction becomes a second, independent choice — which operator you sign with and where that company is incorporated. Same region, different operator, and the legal exposure changes completely. The two knobs stop being welded together.

The audit story changes too. Instead of a contractual assurance that data resides in a region, you have a bucket in your own account whose contents, region and access logs you can inspect directly. For a public-sector reviewer that is a different kind of evidence, because it does not depend on trusting the party being reviewed.

Two honest caveats. Custody moves obligations along with control: a permissive bucket policy is now your incident, and an untested backup is your problem. And residency is not privacy — mail in a bucket you own is still read by whatever routing service filtered and wrote it. Ask where the bytes rest, then ask who holds the keys. They are different questions, and the answers can differ.