Who holds your email keys? The four custody combinations

Email custody is two questions, not one: who holds the keys that decrypt your mail, and who holds the bytes those messages are stored in. Almost every privacy claim in email hosting answers one of them and quietly leaves the other alone. Keys decide who can read your mail. Bytes decide who can withhold it, lose it, or be compelled to produce it.

Cross the two and you get four arrangements. Every mail product on the market sits in one of them, and each one fails in its own characteristic way.

Where do the four combinations land?

Keys	Bytes	Who works this way	What it actually protects
Provider	Provider	Gmail, Microsoft 365, most cPanel and shared hosting	A stolen or decommissioned disk
You	Provider	Zero-access providers: Proton Mail, Tuta	The provider reading your stored mail
Provider	You	A routing service that encrypts mail and writes it into storage you own, keeping the key server-side	Losing the archive to a provider’s account system or jurisdiction
You	You	Self-hosting a mail server; device-custody mailboxes where keys are generated in your browser	Both — and it hands you every failure mode

The third row is the one people do not expect, because “encrypted, in your own bucket” sounds like it must be the strongest option. It is a real and defensible design — the provider needs the key to render your mailbox in a browser and to filter incoming mail — but a service holding the key can read anything it fetches, wherever the file physically lives.

Why is “encrypted at rest” only half an answer?

Because in almost every product that phrase means encryption with keys the provider manages, which the provider therefore decrypts transparently on every read. Google, Microsoft and AWS all encrypt customer data at rest with AES-256 and provider-held keys. That is genuine engineering and it defends against a specific threat: drives leaving the building. It says nothing about who can read your mailbox from inside.

The test is one question. If someone at the provider is compelled to produce your mail tomorrow, what comes out — readable messages, or a file nobody involved can open? Everything else about a privacy page is commentary on that answer.

What actually goes wrong in each quadrant?

Different things, and knowing which one you are exposed to matters more than picking the theoretically strongest option.

Provider keys, provider bytes. A court order produces readable mail. So does a compromised admin account or an employee who abuses access; the controls are policy and audit logs, not mathematics. Content is available to the provider by construction, which is how spam filtering, search, smart replies and — historically — ad targeting all work. If the account is suspended, the archive goes with it. In practice this quadrant is fine for most mail and catastrophic for the small fraction you would not want read aloud.

Your keys, provider bytes. The read problem is solved and the availability problem is worse. A subpoena yields ciphertext plus everything outside it: billing records, login IP addresses, envelope logs, sometimes subject lines. A suspension still separates you from the archive, and now nobody can hand it back, because the provider cannot decrypt what it stores. Forgetting the password with no recovery phrase destroys the mailbox permanently. That is not a bug — it is the guarantee working — but it is the single most common way people lose a zero-access archive.

Provider keys, your bytes. Your archive outlives the provider: it is sitting in your own cloud account, on your own billing relationship, in a region you picked, and no suspension reaches it. Two caveats travel with that. The provider can still read messages it processes, and a court order for the key is a trivially easy order to comply with. And the archive is only yours in a useful sense if the on-disk format is documented; if the provider’s software is the only thing that can parse it, you own bytes rather than mail.

Your keys, your bytes. There is nothing to serve a subpoena on except transport metadata held by other people’s relays, and no account anyone can suspend. The price is that every failure is now final and yours: a lost passphrase, a deleted bucket, a permissive storage policy that publishes an archive, an unnoticed backup that stopped running in March. Self-hosting adds the operational tail as well — certificate renewal, blocklist monitoring, reverse DNS, IP warm-up — and outbound deliverability is decided by other people’s reputation systems no matter how correct your configuration is.

Which combination should you choose?

Pick the quadrant that covers the failure you would actually not survive, and then engineer around the one it leaves open.

If your worry is a provider or a government reading your correspondence, you need your keys, and you should accept that losing the credential loses the mail. If your worry is losing access — a suspended account, a vendor acquisition, a repricing, a company that shuts down, a jurisdiction you cannot use — you need the bytes, and key custody is a separate decision you can make later. If a written requirement says the data lives in an account you control, only the bottom two rows satisfy it, and no vendor promise substitutes.

Almost nobody needs the fourth quadrant’s ops burden to get its guarantees, which is why the bottom two rows have grown into a real category over the last few years.

One habit is worth more than any of this analysis. Ask a provider both questions separately, in writing: who holds the keys, and who holds the bytes. Vendors that have thought it through answer in a sentence each. Vendors that have not will answer the key question twice.