S/MIME, PGP and TLS: what email encryption does and doesn't cover
TLS protects mail between servers, S/MIME and PGP protect the message content end to end. None of them hides who you wrote to, or stops a stolen password.
On this page(8 sections)
"Is our email encrypted?" is a question founders get from customers, auditors and their own lawyers, and the honest answer is usually "partly." Three different technologies carry the word "encryption" in email, they protect different things, and the gaps between them are where most real incidents happen. This post separates what each one covers so you can answer the question without overpromising.
What are the three kinds of email encryption?
Email encryption comes in two layers. TLS (Transport Layer Security) encrypts the connection between two mail servers, or between your mail app and your server. S/MIME and PGP encrypt the message itself, so only the holder of the recipient's private key can read it. TLS is on almost everywhere by default; S/MIME and PGP are opt-in and need setup on both ends.
| TLS | S/MIME | PGP (OpenPGP) | |
|---|---|---|---|
| What is encrypted | The connection, hop by hop | The message body and attachments | The message body and attachments |
| Who must set it up | Mail servers (usually automatic) | Sender and recipient, each with a certificate | Sender and recipient, each with a key pair |
| Where trust comes from | Server certificates | Certificate authorities | Keys you verify yourself or through people you trust |
| Readable by your mail provider | Yes, at each server | No, if the keys never leave your devices | No, if the keys never leave your devices |
| Hides subject and addresses | No | No, by default | No, by default |
Does TLS protect my email?
TLS protects email only while it travels between servers, and only if both sides agree to use it. Each server that handles your message can still read it, and the message is stored in readable form on the way. Think of TLS as sealing the envelope for each leg of the trip, then opening it at every depot.
Most mail is sent over TLS today because the common SMTP setup is opportunistic: the servers try to start TLS (the STARTTLS command), and if the other side does not offer it, many senders fall back to plain text rather than fail. That fallback is the weak point. Someone on the network path can strip the STARTTLS offer, and the message goes out unencrypted without anyone noticing.
Two standards close that gap for inbound mail to your domain: MTA-STS and DANE. Both tell sending servers "only deliver to us over verified TLS." Our guides cover MTA-STS from scratch and the trade-offs between DANE and MTA-STS. Neither one changes the fact that the message is readable at each server.
What do S/MIME and PGP add?
S/MIME and PGP add end-to-end protection of the message content. The sender encrypts with the recipient's public key, and only the recipient's private key can decrypt it. Your mail provider, a compromised relay and anyone reading backups see ciphertext instead of the body and attachments.
Both also support digital signatures, which prove who wrote the message and that the body was not altered. The difference is how you decide to trust a key:
- S/MIME uses certificates issued by certificate authorities, much like websites. It is built into most major mail clients, but each person needs a certificate tied to their address, and those expire and must be renewed. It is defined in RFC 8551.
- PGP (standardized as OpenPGP in RFC 9580) has no central authority. You verify a key yourself or rely on people you trust. It usually needs a plugin or a client with built-in support.
Either way, the practical barrier is the same: both parties must take part. You cannot send an encrypted message to a customer who has no key or certificate. This is why S/MIME and PGP are common inside regulated teams and among security-minded people, and rare in ordinary customer support.
What does email encryption not protect?
Even with S/MIME or PGP, the following stay visible or exposed:
- Metadata. The From, To and Date headers have to be readable for the message to be routed. Mail servers log who wrote to whom and when.
- The subject line. With standard S/MIME and PGP the subject is not encrypted. IETF work on cryptographic header protection can hide it, but at the time of writing that is a draft, and support differs by client.
- Message size and timing. An observer can see that a large attachment went from A to B at 3 p.m.
- The recipient's device. If the recipient's laptop or phone is compromised, decrypted mail is readable there.
- Your own account. If someone steals the password or session of an account that holds the private key, or of a mailbox that holds plain mail, encryption in transit did nothing for you.
That last point is the one that matters most for small teams. Most mailbox breaches are not someone cracking TLS. They are a phished password, a reused password or an unprotected account. Two-factor authentication and prompt detection of a compromised account protect more of your real risk than a certificate does.
Which one do you actually need?
Match the control to the threat:
| If your worry is | Then do this first |
|---|---|
| A snooper on the network between mail servers | Make sure TLS is on and add MTA-STS for your domain |
| Someone stealing a mailbox password | Turn on 2FA for every account |
| A recipient or auditor needing proof a message is genuine | Sign your mail (S/MIME or PGP signing), and publish SPF, DKIM and DMARC for the domain |
| Sending a sensitive document to one person | Use a link to an access-controlled file, or encrypt the file itself, and share the password through a different channel |
| A contract that says "encrypted email" | Ask what they mean: in transit (TLS) or end to end (S/MIME or PGP) |
SPF, DKIM and DMARC are about proving the sender's domain, not hiding content, so they are a separate topic. See how email spoofing works and which records stop it.
How should you answer a customer who asks "is your email encrypted?"
A calm, accurate answer has three parts: what is on, what is optional, and what you do about account security. For example:
Email to and from our domain is sent over TLS when the other server supports it, and we [enforce TLS for inbound mail with MTA-STS, if you have deployed it]. We can exchange S/MIME or PGP encrypted messages on request. All staff accounts use two-factor authentication.
Only state what is true for your setup. If you have not deployed MTA-STS, leave that clause out. Overclaiming ("military-grade encryption") is the fastest way to lose an auditor's trust.
Where does an AI assistant fit in?
If you give an AI assistant access to a mailbox, it reads mail after your provider has decrypted it. S/MIME or PGP content you cannot read in your own client stays unreadable to an assistant too, and anything you can read, it can read. Decide what the assistant may see in the same way you decide what a new team member may see. Koltrix has an MCP server that lets Claude or ChatGPT work with a mailbox, so the same rule applies there.
Bottom line
TLS protects the connection between servers, S/MIME and PGP protect message content end to end, and none of them hide metadata or rescue a stolen password. For most small teams the order of work is: confirm TLS and add MTA-STS, turn on 2FA everywhere, then add S/MIME or PGP only for the specific people and documents that need it. Say plainly which layer you have, and you can answer the question truthfully.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
