"My email is encrypted" is almost always true — and almost never means what the sentence suggests. The difference between transport and content encryption decides who can read along.
What TLS achieves
Between your program and the mail server, and usually between mail servers as well, the connection runs over TLS — the same technology as the padlock in your browser. On the way from A to B nobody can read along.
The crucial point: that applies to each individual leg, not to the whole journey. Picture email as a postcard carried between sorting offices in a locked van. At every sorting office it is unpacked, read, re-sorted and packed again.
So who can read it:
- your email provider
- the recipient's provider
- every intermediate server, such as spam filters or forwarding services
- anyone who gains access to one of those systems
And when TLS is missing?
Between mail servers, TLS is still optional. If the far side does not support it, many configurations deliver unencrypted rather than not at all. That is a deliberate trade in favour of deliverability — with the side effect that an attacker can force the downgrade by suppressing the encryption request.
Countermeasures exist, such as MTA-STS and DANE, which tell a sender "TLS is mandatory for my domain". They are not yet widespread.
Real end-to-end encryption
This encrypts the content before it leaves the device and decrypts it only on the recipient's device. No server in between can do anything with it. Two schemes have been established for decades.
PGP
Everyone generates a key pair. The public half is distributed; the private half decrypts and signs. There is no central authority certifying keys — trust is built by people confirming each other's keys.
S/MIME
Technically similar, organisationally the opposite: keys are issued by a certificate authority, much like website certificates. That is more convenient and common in companies, but it shifts trust onto that authority.
Why neither caught on
- Both sides have to participate. Encryption at one end achieves nothing, and the recipient must have set it up in advance.
- Key management is awkward. Exchanging keys, backing them up, having them on several devices, replacing them when lost — all of that has to be understood and done.
- A lost key means lost mail. There is no recovery. That is the opposite of what people expect from a service.
- Metadata stays open. Who corresponds with whom, when, and about what — subject lines are not encrypted by default in PGP — remains visible. Often that is the more interesting information.
- Search stops working. A server that cannot read anything cannot search or filter it either.
What this means in practice
Treat email as what it is: a reliable, open and well documented medium — but not a confidential one. For anything that genuinely concerns nobody else, a messenger with end-to-end encryption is the simpler and safer choice.
For temporary mailboxes such as ours this applies doubly: they have no password, and whoever knows the address sees the content. They are meant for sign-up confirmations, not for confidential material.