Email Encryption Explained: TLS, S/MIME & More (2026)

Email encryption protects your messages from being read or altered while they travel — and, in its strongest form, ensures only the intended recipient can ever open them. Because email was designed without built-in privacy, encryption is bolted on at two levels: encryption in transit between mail servers, and end-to-end encryption of the message itself. This guide explains how email encryption works, the difference between TLS encryption and S/MIME, and how to encrypt email in practice. It is part of our email security hub.

What is email encryption?

Email encryption is the process of encoding an email so that only authorised parties can read it. There are two distinct kinds, and conflating them is the most common source of confusion. Transport encryption protects the connection between mail servers, so a message cannot be read as it crosses the network — but the servers at each end can still read it. End-to-end encryption protects the message itself, so that only the sender and the intended recipient hold the keys to read it, and not even the mail providers in between can. Most everyday email uses transport encryption; sensitive correspondence may need end-to-end. Understanding which you have is the foundation of email encryption.

TLS encryption: protecting email in transit

The workhorse of email encryption is TLS (Transport Layer Security), which encrypts the connection between sending and receiving mail servers. Modern mail almost always travels over TLS, but standard TLS for email is opportunistic: it is used if both servers support it and nothing interferes, but it can be silently stripped by an attacker, forcing a message into plain text. That weakness is what MTA-STS fixes — it lets a domain require that inbound mail use validated TLS or not be delivered at all, and TLS-RPT reports on any failures. So robust TLS encryption for email is really TLS plus MTA-STS: the first encrypts, the second makes encryption mandatory. For most organisations, getting transport encryption right covers the large majority of real-world risk.

End-to-end email encryption: S/MIME and PGP

When message contents must be confidential even from the mail providers handling them, you need end-to-end email encryption, and the two established standards are S/MIME and PGP. Both use public-key cryptography: you encrypt a message with the recipient’s public key, and only their private key can decrypt it. S/MIME (defined in RFC 8551) relies on certificates issued by a certificate authority and is built into most corporate mail clients, which makes it the common choice for businesses. PGP (and its open implementation, GPG) uses a decentralised web of trust instead of certificate authorities and is popular with individuals and technical users. Either way, end-to-end encryption also lets you digitally sign messages, proving they genuinely came from you and were not altered. For a full walkthrough of each, see our dedicated S/MIME email encryption guide and PGP email encryption guide, or our S/MIME vs PGP comparison if you are deciding between them.

How to encrypt email in practice

For most people and organisations, knowing how to encrypt email comes down to a sensible layered plan:

1. Ensure TLS is on — every reputable mail provider uses it by default for connections that support it.
2. Enforce it with MTA-STS so inbound mail to your domain cannot be downgraded to plain text, and add TLS-RPT for visibility.
3. Add end-to-end encryption where it is genuinely needed — deploy S/MIME certificates for staff who exchange sensitive data, or PGP for technical users.
4. Use a secure-message portal for one-off confidential sends to recipients who lack S/MIME or PGP.

The practical rule is to make strong transport encryption universal and reserve end-to-end encryption for the messages that truly require it, since S/MIME and PGP add key-management overhead that is overkill for routine mail. Authoritative references such as RFC 8551 define the S/MIME standard if you need the technical detail.

Email encryption best practices

• Make TLS mandatory, not optional — deploy MTA-STS so encryption cannot be silently stripped.
• Do not confuse encryption with authentication — encryption hides content, while SPF, DKIM and DMARC prove who sent it. You need both.
• Manage keys and certificates carefully — end-to-end encryption is only as safe as your private keys.
• Reserve end-to-end encryption for sensitive mail and rely on TLS for everything else.
• Sign as well as encrypt where supported, to prove authenticity alongside confidentiality.

When you actually need end-to-end encryption

One of the most useful things to get right about email encryption is knowing how much you actually need, because over-engineering it causes as many problems as ignoring it. For the overwhelming majority of mail — newsletters, notifications, routine business correspondence — strong transport encryption (TLS enforced with MTA-STS) is the appropriate and sufficient level. It protects messages from interception on the network without imposing any burden on senders or recipients. End-to-end encryption with S/MIME or PGP becomes genuinely necessary only when the contents must remain private even from the mail providers handling them: legal documents, health records, financial data, sensitive contracts, or any correspondence subject to strict regulatory confidentiality. In those cases the extra key-management effort is justified by the risk.

The mistake to avoid in both directions is treating these as interchangeable. Relying on transport encryption for data that legally requires end-to-end protection leaves you exposed; conversely, mandating S/MIME for every internal memo creates friction that pushes people back to less secure channels. Match the level of email encryption to the sensitivity of the content, and you get strong protection where it matters without grinding everyday communication to a halt. For regulated industries, a secure-message portal is often the pragmatic middle path, giving recipients without S/MIME a way to read confidential messages.

Common email encryption mistakes

• Assuming “TLS is on” means messages are private. Opportunistic TLS can be stripped, and the receiving servers can still read the content — enforce it with MTA-STS and use end-to-end encryption for true confidentiality.
• Confusing encryption with authentication. Encryption hides content; SPF, DKIM and DMARC prove who sent the message. A message can be perfectly encrypted and still be a spoof, so you need both layers.
• Neglecting key management. End-to-end encryption is only as secure as the private keys — lose them and you lose access to your own mail; leak them and the encryption is worthless.
• Forgetting recipients. S/MIME and PGP require the recipient to be set up too, so confidential exchanges need both parties prepared or a portal as a fallback.

Avoid those and email encryption becomes straightforward: universal, enforced TLS as the baseline, end-to-end encryption reserved for sensitive content, and a clear understanding that encryption and authentication are complementary layers rather than substitutes. That combination — confidentiality in transit, confidentiality end-to-end where needed, and proof of sender identity — is what a complete email security posture looks like.

Email encryption and compliance

For many organisations, email encryption is not just good practice but a regulatory requirement, and understanding which level satisfies which rule prevents both under- and over-compliance. Data-protection regimes such as GDPR expect “appropriate technical measures” to protect personal data, which in practice means enforced transport encryption as a baseline and stronger protection for sensitive categories. Sector rules go further: healthcare data under regimes like HIPAA and financial or legal records often demand that confidential contents be protected end to end, not merely in transit, because the data must stay private even from intermediaries. The practical implication is that a single blanket policy rarely fits — you map the sensitivity and regulatory status of your mail to the encryption level it requires.

This is also where documentation matters. Auditors and regulators want evidence that encryption is enforced, not merely available, which is another reason MTA-STS and TLS-RPT are valuable: they let you both require encrypted delivery and produce reports proving it happened. For the most sensitive correspondence, S/MIME or a secure portal provides the demonstrable end-to-end protection that compliance frameworks increasingly expect. Getting this right is less about deploying the strongest possible encryption everywhere and more about deploying the right encryption for each class of data, and being able to show you did. Pair these confidentiality measures with the sender-identity protections in our authentication hub for a complete, defensible posture.

Check it yourself: use our free email tools to look up your domain’s MTA-STS and TLS-RPT records and confirm encrypted delivery is enforced and reported.

Related reading

• S/MIME email encryption guide
• PGP email encryption guide
• Email spoofing explained
• Email phishing protection
• DMARC adoption by TLD

Email encryption FAQ

Is email encrypted by default?

Most email travels over TLS-encrypted connections between servers today, but standard TLS is opportunistic and can be downgraded to plain text without warning. MTA-STS closes that gap for your domain. For true confidentiality of the message contents themselves, you need end-to-end encryption such as S/MIME or PGP.

What is the difference between TLS encryption and S/MIME?

TLS encryption protects the connection between mail servers, so the message is safe in transit but readable by the servers at each end. S/MIME encrypts the message itself end to end, so only the intended recipient can read it. TLS is the universal baseline; S/MIME is for genuinely confidential content.

How do I encrypt an email?

For transport encryption, ensure your provider uses TLS and enforce it with MTA-STS — no per-message action needed. For end-to-end encryption, set up S/MIME certificates or PGP keys in your mail client, or use a secure-message portal for one-off confidential sends to recipients without those tools.

Is S/MIME or PGP better?

Neither is universally better; they suit different contexts. S/MIME relies on certificate authorities and is built into most corporate mail clients, making it the natural fit for businesses. PGP uses a decentralised web of trust and is favoured by individuals and technical users. The right choice depends on your environment and who you exchange mail with, and in practice the deciding factor is often simply which standard the people you need to email already support.

Does email encryption stop spam or phishing?

No. Encryption protects confidentiality and integrity, not sender identity. Stopping spoofing and phishing requires authentication — SPF, DKIM and DMARC — which is a separate layer. Encryption and authentication solve different problems and should both be in place. A useful way to remember the split: encryption answers “can anyone else read this?”, while authentication answers “is this really from who it claims?” — and a complete email security posture needs a confident yes to the first and a verifiable yes to the second.

Do I need end-to-end encryption for all my email?

For most mail, no — strong transport encryption (TLS plus MTA-STS) covers the realistic risk without the key-management overhead. Reserve end-to-end encryption such as S/MIME or PGP for genuinely sensitive correspondence, where the contents must stay private even from the mail providers handling them. Mandating end-to-end encryption for every message tends to backfire, because the friction pushes people toward less secure workarounds; matching the protection level to the sensitivity of the content is both more practical and, for regulated data, exactly what compliance frameworks expect you to be able to demonstrate.