Here's an uncomfortable truth: that 'secure' email you just sent probably traveled across the internet in a form that any sufficiently motivated attacker could read. Not because encryption doesn't exist, but because the email ecosystem has layers of encryption that protect different things—and most people don't understand which layer protects what.
When we talk about email encryption, we're actually talking about three distinct technologies that solve three distinct problems. Conflating them leads to false confidence or unnecessary paranoia. Let's untangle this.
TLS: Encrypting the journey
Transport Layer Security—TLS—is the encryption you get by default with most modern email. When your email travels from your mail server to the recipient's mail server, TLS encrypts that connection. Anyone intercepting the traffic sees gibberish.
This is the same technology that puts the padlock in your browser's address bar. It's well-understood, widely deployed, and mostly invisible. When you send an email through Gmail, Outlook, or any reputable email service, TLS is almost certainly protecting the connection.
But TLS has a critical limitation: it only encrypts data in transit. Once your email arrives at the recipient's mail server, it's decrypted and stored in plain text (or encrypted with the server's own keys, which the server operator can access). If someone compromises the mail server, or if the server operator is compelled to hand over data, TLS provides no protection.
There's another subtlety: TLS is negotiated between servers, and it's not always guaranteed. If the recipient's server doesn't support TLS, or if there's a configuration problem, the email might fall back to unencrypted transmission. Most major providers now require TLS, but it's not universal. Google's transparency report shows that about 10% of outbound Gmail still goes to servers that don't support encryption.
For most business email, TLS is sufficient. It protects against passive eavesdropping—someone tapping the wire between servers. It doesn't protect against compromised servers, legal demands for data, or sophisticated attackers who can intercept and modify traffic.
S/MIME: The enterprise standard
S/MIME—Secure/Multipurpose Internet Mail Extensions—encrypts the email message itself, not just the connection. The email is encrypted on your device before it leaves, and only the recipient's device can decrypt it. The mail servers in between see only encrypted content.
S/MIME uses the same certificate infrastructure as HTTPS. You get a certificate from a certificate authority, which contains your public key and verifies your identity. When someone wants to send you an encrypted email, they use your public key to encrypt it. Only your private key—which never leaves your device—can decrypt it.
The enterprise world loves S/MIME because it integrates with existing identity infrastructure. If your company already uses certificates for VPN access or code signing, extending that to email encryption is relatively straightforward. Outlook has built-in S/MIME support, as do most enterprise email clients.
But S/MIME has friction. Both sender and recipient need certificates. You need to exchange public keys before you can communicate securely. Certificate management is a headache—certificates expire, get revoked, and need to be backed up. If you lose your private key, any email encrypted to that key is gone forever.
There's also the question of who you're trusting. S/MIME certificates come from certificate authorities, which means you're trusting those CAs to properly verify identities and protect their infrastructure. Nation-state attackers have compromised CAs before. For most threat models this is acceptable, but it's not true end-to-end security in the paranoid sense.
PGP: The cypherpunk choice
PGP—Pretty Good Privacy—predates S/MIME and takes a different philosophical approach. Instead of relying on certificate authorities, PGP uses a 'web of trust' where users verify each other's keys directly. There's no central authority deciding who's who.
The cryptography is similar to S/MIME: public key encryption where only the recipient's private key can decrypt the message. But the key management is radically different. You generate your own keys, publish your public key to key servers or your website, and verify other people's keys through direct communication or by trusting people who've already verified them.
PGP is popular among journalists, activists, and security researchers—people who have reason to distrust centralized authorities. It's also notoriously difficult to use correctly. Key management is manual and error-prone. The tools have historically been user-hostile. Studies have shown that even technical users make mistakes that compromise their security.
The web of trust model sounds elegant but doesn't scale well. In practice, most PGP users either verify keys through side channels (meeting in person, calling to confirm fingerprints) or just trust keys they find online—which defeats much of the security benefit.
There's ongoing debate in the security community about whether PGP is still fit for purpose. The protocol is old, the implementations are complex, and the usability problems have never been solved. Some argue that modern alternatives like Signal (for messaging) provide better security with less friction. But for email specifically, PGP remains the standard for end-to-end encryption outside the enterprise.
Choosing the right encryption
So which encryption should you use? It depends on what you're protecting against.
For general business email, TLS is probably sufficient. It's automatic, universal (mostly), and protects against the most common threats. Make sure your email provider enforces TLS and consider enabling MTA-STS to prevent downgrade attacks.
For regulated industries or sensitive internal communications, S/MIME makes sense. The certificate infrastructure integrates with enterprise identity management, and the major email clients support it natively. The overhead of certificate management is justified by the compliance and security benefits.
For truly sensitive communications where you don't trust the infrastructure—whistleblowing, journalism, activism—PGP or a dedicated secure messaging platform is appropriate. But be realistic about the usability challenges and the operational security required to use it effectively.
One important note: encryption protects content, not metadata. Even with PGP or S/MIME, observers can see who's emailing whom, when, and how often. For some threat models, this metadata is as sensitive as the content. If that's your situation, email might not be the right tool regardless of encryption.
Frequently asked questions
Is Gmail encrypted?
Gmail uses TLS for transmission and encrypts stored emails with Google's keys. This protects against external attackers but not against Google itself or legal demands. For end-to-end encryption where Google can't read your email, you'd need to add S/MIME or PGP.
Can I use S/MIME and PGP together?
Technically yes, but there's rarely a reason to. They solve the same problem with different trust models. Pick one based on your environment and threat model.
Why don't more people use email encryption?
Usability. Both S/MIME and PGP require setup, key management, and coordination with recipients. For most people, the friction outweighs the perceived benefit. TLS provides 'good enough' security for typical use cases.
What about encrypted email services like ProtonMail?
Services like ProtonMail encrypt your mailbox with keys derived from your password, so even they can't read your stored email. Email between ProtonMail users is end-to-end encrypted. Email to external users can be encrypted with a password or falls back to TLS.