“Secure email” is not one architecture. Where the encryption key is stored decides who can read the mailbox: only the endpoints, or also the provider and anyone who can compel the provider.
For a wider vendor comparison (Drive, chat, vaults), see who is holding encryption keys for the software you use.
Where is the encryption key stored in a secure email system?
In a true end-to-end design:
- The public key (or certificate) is published so senders can encrypt to you.
- The private key stays under the user’s control: in the mail client’s certificate store, a PGP keyring, a hardware token, or a file encrypted with a passphrase the provider cannot use.
If the host can decrypt messages for search, spam filtering, or “forgot password” webmail, the effective keys are on the server (or in a KMS the provider operates). That can still be TLS-protected in transit. It is not end-to-end.
Common models
S/MIME
Your organisation issues a certificate. The private key is installed in the OS or mail client (and optionally on a smart card). The public certificate is attached to outbound mail or published in the directory. Lose the private key or the token, and you cannot read old S/MIME mail unless a copy was escrowed by IT.
PGP / GPG / OpenPGP
Keys live in a local keyring (or a hardware device). The private key is usually protected with a passphrase. Servers that only store ciphertext never see that passphrase. Webmail gateways that decrypt in the browser still need a place to keep a wrapped private key—treat that like a vault secret.
Standard Gmail / Microsoft 365 mail
Mail is encrypted in transit (TLS) and at rest with provider-managed keys. Google or Microsoft can process message content. That is normal business email, not a personal E2EE messenger.
Gmail client-side encryption (CSE) and Microsoft customer key / Purview options move root key control to a customer KMS. Keys then sit in your key vault or HSM, not in the default Google/Microsoft pool. Setup is an IT project, not a consumer toggle.
Proton Mail and similar E2EE webmail
The private key is generated for the user and stored on the provider’s servers in encrypted form, wrapped with a key derived from the account password (or a separate mailbox password). The provider’s design goal is that they cannot unwrap it. The key is not “only on the laptop”; it is password-wrapped at rest on the host, and unwrapped in the client.
What this means in practice
- Device store / token: strongest user control; recovery is your problem (or IT escrow).
- Password-wrapped key on the server: convenient multi-device webmail; the password (and recovery) become the real root of trust.
- Provider-managed keys: searchable mail, easy reset, weaker confidentiality against the host.
A digital vault does not replace secure email, but it is the right place to store PGP private keys, S/MIME backups, and CSE recovery material—with access control, not a shared drive. Hypervault is built so we cannot read those items (zero-knowledge).
Do not send those key files over ordinary email. Use a secure exchange path.
