What is end-to-end encrypted email — and do you actually need it?

"Encrypted email" describes at least three different things, and providers rarely distinguish between them. Understanding the difference tells you what you're actually protected against.

Three kinds of encryption, three different guarantees

1. Encryption in transit (TLS)

When your mail server hands a message to the recipient's server, TLS encrypts that hop. Nearly all mail moves this way today, and it stops passive network interception.

What it doesn't do: protect the message once it lands. Both providers hold readable copies, and TLS is opportunistic in SMTP — if the receiving server doesn't support it, many senders fall back to plaintext rather than fail.

2. Encryption at rest

Your provider encrypts stored messages on disk. This protects against stolen drives, misplaced backups and some classes of infrastructure breach.

What it doesn't do: hide anything from the provider. They hold the keys, so they can decrypt. Tobava Mail encrypts received message bodies at rest with AES-256-GCM — real protection against a specific threat, but not secrecy from us.

3. End-to-end encryption (E2EE)

The message is encrypted on the sender's device with the recipient's public key, and can only be decrypted by the recipient's private key. Every server in between — including ours — sees ciphertext only.

This is the only version where "we cannot read your mail" is a technical fact rather than a policy promise.

How E2EE email actually works

The standard is PGP. Each person has a key pair: a public key shared freely, and a private key that never leaves their control.

1. You get the recipient's public key.
2. Your client encrypts the message with it before it leaves your device.
3. Only their private key can decrypt it.

Tobava Mail offers PGP key management, but be clear about what that does and does not give you: unless you hold the private key and it never touches the server, the provider can still decrypt. Ask any provider — including us — where the private key lives before treating PGP as a guarantee.

What E2EE does not protect

This is where most explanations stop, and it matters:

• Metadata stays visible. Who you emailed, when, subject lines in most implementations, and message size. For many investigations metadata is more revealing than content.
• Both ends must participate. Emailing an unencrypted recipient means an unencrypted message. E2EE is a property of the conversation, not your account.
• A compromised device defeats it. If malware is reading your screen, encryption in transit is irrelevant.
• Lost keys mean lost mail. No provider can recover a message encrypted to a private key you no longer have. That's the guarantee working correctly.

Do you actually need it?

Genuinely yes if: you're a lawyer, doctor, accountant, journalist or therapist handling confidential client material; you handle credentials or financial details over email; you're subject to confidentiality obligations where "the provider could read it" is itself the problem.

Probably not for everything: for newsletters, receipts and everyday correspondence, encryption at rest plus a provider whose business model doesn't involve reading mail covers the realistic risk.

The practical bar for a provider

Regardless of E2EE, a provider should offer encryption at rest with modern ciphers, enforced TLS for transport, correct SPF/DKIM/DMARC, MFA on accounts, no content scanning for advertising, and clear data handling terms. E2EE support sits on top of that foundation — it doesn't replace it.