Is email encrypted?

Email is usually encrypted while it travels between servers, but it isn't end-to-end encrypted. The connection from your device to your provider, and the one between providers, normally uses TLS, which stops someone on the network from reading it. Your provider and the recipient's provider still store the message in a form they can read, though, and anyone who gets into either account sees everything. Only S/MIME or PGP encrypt the message itself, and almost nobody uses them. Ordinary email is a postcard carried in a sealed truck. It's safe from people on the road and readable by everyone who handles it at each end.

Four things "encrypted" can mean

People use the word for four different protections, and each one stops a different person:

The first three are what "your email is encrypted" normally refers to. They're real and worth having. But a provider that scans your mail for spam or search, or has to hand it over under a court order, can read it, because at that layer it holds the keys.

Server-to-server encryption, and its gap

When your provider sends mail to another, it connects to the recipient's mail server and, if that server offers it, upgrades the connection to TLS with the STARTTLS command (RFC 3207, 2002). The word that matters is opportunistic. If the other server doesn't offer it, or an attacker strips the offer out of the conversation, most servers fall back to clear text rather than lose the mail. In the basic scheme the sending server also doesn't check that the certificate belongs to the right domain. Two repairs cover that gap:

• MTA-STS (RFC 8461, 2018) lets a domain publish a policy, served over HTTPS, saying "mail to me must use TLS with a valid certificate". Sending servers that support it refuse to fall back. A companion, TLS-RPT (RFC 8460), reports failures.
• DANE for SMTP (RFC 7672) publishes the certificate details in DNS, protected by DNSSEC.

Both help only if the recipient's domain publishes the policy and the sender checks it, and adoption is uneven. Both also stop at the server. They protect the hop, not the message. For the link between your mail program and your provider, RFC 8314 (2018) says to use TLS from the first byte ("implicit TLS", on ports 993, 465 and so on) rather than starting in plain text.

End-to-end: S/MIME and PGP

Two standards encrypt the message itself, so the providers see only scrambled data:

• S/MIME uses certificates issued by certificate authorities and tied to your email address. Many corporate mail systems and the main mail programs have it built in. Its weak point is the certificate, since each person has to get, install and renew one.
• OpenPGP (the standard behind PGP and GnuPG) uses keys you create and exchange yourself. Trust comes from people vouching for keys or from checking fingerprints in person. It's flexible and well respected, and well known for being hard to use correctly. In 2018 researchers showed ("Efail") that some mail programs could be tricked into sending decrypted text to an attacker through HTML tricks. That shows the surrounding program matters as much as the cryptography.

Both need the recipient to take part, which is why they're rare. You can't send an encrypted email to someone who hasn't set up a key. Even when they work, they leave the subject line, the addresses and the time visible, as ordinary email headers have to be.

What your provider can see

With ordinary email, the provider can read the contents of messages stored with it, as a normal part of providing search and spam filtering and, in some services, other features that work by reading the mail. Providers also keep metadata, meaning who wrote to whom and when. Some services offer end-to-end encryption between their own users, often with limits, such as no search, or only between accounts at the same provider. Look at what a service actually says it protects, and from whom, before you rely on it. "Encrypted" alone isn't an answer.

What to do instead

• Keep secrets out of the body of an ordinary email. That means passwords, recovery codes, ID scans and bank details.
• Send the secret by another route, and put only a link in the email. A message sealed in your browser, with the passphrase given separately, fits here. The email carries a link that's useless without the second part (how to send a password securely, how to send sensitive documents).
• Use end-to-end email only with people who also use it, and agree on the setup first.
• Protect the mailbox. It holds everything, so a strong unique password and two-factor authentication matter more than any transit encryption (how 2FA codes work).
• Delete what you no longer need, and remember the other side keeps their copy.

Where cipher.ink fits

cipher.ink isn't email and doesn't replace it. It handles the one thing email does worst, a secret that shouldn't sit in two mailboxes for years. You write the secret in your browser, which encrypts it (how client-side encryption works). The server stores only ciphertext and deletes it after it's opened, and the email carries a link. The only email the site itself sends is the contact form, which goes to its owner, isn't encrypted, and says so (what the server can and cannot see).

Common questions