Email was not designed to be secure. The original SMTP specification, drafted in the early 1980s, assumed a network of trusted academic and government servers exchanging plain-text messages. The protocol has been extended and patched in the decades since, but the underlying assumption — that messages travel in the open and that anyone with access to the network can read them — has never been fundamentally rewritten.
Email encryption is the collection of mechanisms layered on top of SMTP to address this gap. The category covers several distinct technologies that protect different things at different points in the message lifecycle. TLS protects messages in transit between mail servers. S/MIME and PGP protect message contents end-to-end. Each one solves a different problem, and senders who treat them as interchangeable end up with security gaps they did not know they had.
Why Email Needs Encryption (and What “Encryption” Actually Means in Email)?
When an email is sent without any encryption, the message body, the subject line, the recipient address, and every header are transmitted as readable text across the public internet. Any system handling the message — internet service providers, intermediate mail servers, network monitoring equipment — can read the contents. The same is true for the message stored on the sending and receiving mail servers, where it sits as plain text on disk.
The threats are not theoretical. Network operators routinely log email traffic for various purposes. State-level surveillance programs have intercepted email at the network layer at scale. Compromised mail servers expose stored messages. Forwarded mail accumulates copies on intermediate servers. A message that took three or four hops to reach its recipient has, by default, left a readable copy at every hop along the way.
Email encryption addresses different parts of this exposure in different ways. The word “encryption” in email contexts is overloaded — it covers transport encryption (protecting messages while they move between servers), at-rest encryption (protecting messages while they sit on disk), and end-to-end encryption (protecting message contents from everyone except the intended recipient). A complete picture requires understanding all three.
TLS — The Transport Layer
Transport Layer Security is the most widely deployed form of email encryption. It protects messages while they are moving between mail servers. When two mail servers connect over SMTP, they negotiate a TLS session that encrypts the connection for the duration of the message transfer. To any third party watching the network, the messages appear as encrypted bytes rather than readable text.
How TLS Protects Email in Transit
The mechanism is the same TLS used for HTTPS. The two servers exchange cryptographic keys, verify each other’s certificates (in some configurations), and establish an encrypted channel. The message contents — body, headers, attachments — are transmitted through that encrypted channel.
The protection covers only the hop between the two specific servers. A message that travels through four mail servers gets four separate TLS negotiations (or none on hops where TLS is not negotiated), and the message exists in plain text on each intermediate server’s disk between hops. TLS protects against passive network observers; it does not protect against any of the mail servers along the path.
STARTTLS, MTA-STS, and TLS Reporting
The most common way TLS is negotiated in SMTP is via the STARTTLS command. The connection begins in plain text, the two servers exchange capability information, and either side can issue STARTTLS to upgrade the connection to encrypted. This is “opportunistic” TLS — encryption happens when both sides support it, but falls back to plain text when they do not.
The weakness of opportunistic TLS is that an attacker between the two servers can strip the STARTTLS command from the conversation, causing both sides to believe the other does not support TLS and proceed in plain text. This is called a STARTTLS stripping attack.
MTA-STS (Mail Transfer Agent Strict Transport Security) addresses this gap. Domains publish a policy that requires TLS for inbound mail. Sending servers fetch the policy, validate it, and refuse to deliver mail in plain text. The policy is hosted via HTTPS and discovered through a DNS record. Properly deployed, MTA-STS eliminates the downgrade attack vector.
TLS Reporting (TLS-RPT) is a companion protocol that asks remote servers to report TLS connection failures back to the domain owner via email. Combined with MTA-STS, it provides both enforcement and visibility into TLS problems.
What TLS Does NOT Protect
TLS protection has clear boundaries.
It does not protect message contents on the mail servers themselves. The sending server has the plain text. The receiving server has the plain text. Any administrator with server access can read messages, and any breach of the server exposes them.
It does not protect against the recipient’s mailbox provider. Gmail can read every message it stores. Outlook can read every message it stores. This is by design — providers need to read messages to filter spam, run searches, and provide features like reply suggestions.
It does not protect against the sender. Anyone with access to the sender’s mailbox can read all sent messages.
For threats that require protection beyond the transport layer, end-to-end encryption is needed.
S/MIME — Certificate-Based End-to-End
S/MIME (Secure/Multipurpose Internet Mail Extensions) is an end-to-end encryption standard that protects message contents from the sender’s outbox to the recipient’s inbox, with no intermediate server able to read the plain text. It is built around public key infrastructure (PKI) — each user has a certificate issued by a trusted Certificate Authority that binds their email address to a public key.
To send an encrypted S/MIME message, the sender’s mail client retrieves the recipient’s public key (typically from a previously exchanged signed message, an organisational directory, or a public key server), encrypts the message contents with that key, and sends the result. Only the recipient, with the corresponding private key, can decrypt the message.
S/MIME also supports digital signatures. A signed S/MIME message proves to the recipient that the message was sent by the claimed sender and has not been altered in transit. Signatures and encryption can be used independently or combined.
S/MIME’s strength is its enterprise integration. It is supported natively by Outlook, Apple Mail, and most enterprise mail clients. It works seamlessly within an organisation that has deployed certificates to all users. Microsoft 365 and Google Workspace both support S/MIME deployment at the organisational level.
The weakness is interoperability outside the organisation. Sending an encrypted S/MIME message to a recipient who does not have a certificate is impossible. The two parties must have a way to exchange certificates beforehand. For internal corporate communication, this is manageable. For ad-hoc external communication, it falls apart.
PGP / OpenPGP — The Key-Exchange Model
PGP (Pretty Good Privacy) and its open-source equivalent OpenPGP take a different approach to the same problem. Instead of relying on a central Certificate Authority, PGP uses a web-of-trust model where users sign each other’s keys to establish identity.
The practical workflow is similar to S/MIME: the sender obtains the recipient’s public key, encrypts the message with it, and sends the result. The recipient decrypts with their private key. The mathematics is the same; the trust model is different.
PGP’s strength is its independence. There is no central authority to compromise or shut down. Keys can be exchanged peer-to-peer or via public keyservers. The protocol is open-source and widely audited.
The weakness is usability. PGP has historically required users to manage their own keys, exchange them via out-of-band channels, and use specialised mail clients or plugins. Mainstream mail clients do not support PGP natively. Several projects (Mailvelope, FlowCrypt, ProtonMail) have made PGP more accessible, but it remains a tool for technically aware users rather than a default option.
Side-by-Side Comparison: TLS vs S/MIME vs PGP
The three approaches solve different problems and combine differently.
TLS protects against network observers. It is invisible to users, requires no key management, and is the default for most modern mail. It does not protect against mail servers along the path.
S/MIME protects message contents end-to-end with certificate-based identity. It works well inside organisations with managed PKI. It is integrated into mainstream enterprise mail clients. It requires certificate exchange before secure communication can begin.
PGP protects message contents end-to-end with peer-to-peer key exchange. It avoids reliance on central authorities. It is harder to use and not natively integrated into mainstream clients.
For most business email, TLS is sufficient and is already in place. For sensitive internal communication within an organisation, S/MIME adds end-to-end protection without disrupting workflows. For sensitive external communication with technically aware counterparties, PGP is appropriate. For sensitive external communication with non-technical counterparties, secure file-sharing platforms outside of email are usually the practical answer.
HIPAA, GDPR, and Other Compliance Frameworks
Compliance frameworks treat email encryption differently, and the legal requirements often diverge from technical best practice.
HIPAA (US healthcare) does not specifically require encryption but requires “reasonable and appropriate” protection of protected health information (PHI). In practice, this means TLS-encrypted transport between mail servers is generally accepted, but PHI sent in an unencrypted email is a violation. Many healthcare organisations use S/MIME or secure messaging portals for explicit PHI exchange to remove ambiguity.
GDPR (EU) requires data controllers to use “appropriate technical and organisational measures” to protect personal data. Encryption is one of the named example measures. In practice, TLS transport encryption is treated as a baseline; sensitive personal data (financial, health, biometric) typically requires stronger protection.
PCI DSS (Payment Card Industry) explicitly prohibits transmitting unencrypted cardholder data over public networks. Email containing cardholder data must be encrypted, and most PCI-compliant programs avoid sending cardholder data via email at all.
The pattern across frameworks is consistent: TLS is a baseline expectation, and sensitive data categories require additional protection. The choice between S/MIME, PGP, or secure portals depends on the specific use case and counterparty capabilities.
Email Encryption and Email Deliverability — Interactions
Encryption choices have small but real interactions with deliverability.
TLS deployment is now near-universal between major mail servers. Mailbox providers, including Gmail,l flag messages that arrived without TLS — Gmail displays a red padlock icon next to such messages, and the reduced trust signal can affect reputation over time.
S/MIME and PGP encryption produce large, opaque message bodies that spam filters cannot inspect. Some filters treat encrypted messages with extra caution, but most mainstream filters whitelist them based on authentication results. Encrypted internal mail rarely encounters deliverability issues.
Signed but unencrypted messages (S/MIME or PGP signatures without encryption) provide authentication benefits with no deliverability downside. For organisations that want stronger sender verification but cannot deploy full end-to-end encryption, signing is a reasonable middle ground.
Key Takeaways
- Email was designed without security. Encryption is layered on top to address different parts of the exposure.
- TLS protects messages in transit between mail servers. It does not protect messages on the servers themselves.
- STARTTLS is opportunistic — MTA-STS enforces TLS and prevents downgrade attacks.
- S/MIME provides end-to-end encryption using certificates and is well integrated into enterprise mail clients.
- PGP provides end-to-end encryption with peer-to-peer key exchange and is harder to use but does not depend on central authorities.
- Compliance frameworks generally treat TLS as a baseline and require additional protection for sensitive data categories.
Frequently Asked Questions
No. Gmail uses TLS for transport encryption between mail servers, and Google encrypts stored email at rest on its servers. But Google itself can read the messages — they are not end-to-end encrypted in the sense that PGP or S/MIME provide. Google Workspace supports S/MIME for enterprise customers who deploy it.
Encryption in transit protects messages while they are moving between systems. Encryption at rest protects messages while they are stored on disk. Most major mail providers do both. End-to-end encryption is a third category that protects messages from everyone except the intended recipient, including the providers themselves.
For ordinary business communication, no. TLS plus the provider’s at-rest encryption is sufficient for most use cases. PGP or S/MIME becomes necessary when the message contents must be hidden from the provider itself, when compliance frameworks require end-to-end encryption, or when communicating with parties who require it.
S/MIME and PGP-encrypted messages produce content that spam filters cannot inspect. Most mainstream filters handle this correctly, but some configurations treat encrypted messages as higher risk. The fix is to ensure that authentication (SPF, DKIM, DMARC) passes cleanly so the filter has strong identity signals even without content visibility.
Yes, in principle. In practice, mail clients usually default to one or the other, and using both adds complexity without practical benefit. Choose one based on your environment — S/MIME for managed enterprise PKI, PGP for peer-to-peer key exchange.
Conclusion
Email encryption is not a single technology but a stack of protections applied at different layers of the delivery process. TLS secures messages while they travel between servers, while S/MIME and PGP secure the message contents themselves against everyone except the intended recipient. Understanding that distinction is what prevents false assumptions about what is actually protected.
For most organisations, transport encryption with properly configured TLS is the baseline requirement and already covers the majority of everyday business communication. The moment sensitive financial, healthcare, legal, or regulated data enters the conversation, stronger controls such as S/MIME, PGP, or secure messaging portals become necessary. The right choice depends less on ideology and more on usability, compliance obligations, and the technical sophistication of the people exchanging the messages. Protect Sensitive Email Communications
