Email encryption comes in two layers. Transport encryption with TLS protects a message while it moves between servers. Message encryption, such as S/MIME, protects the content from the sender's mail client to the recipient's, so servers in between cannot read it. Most email has the first layer and few messages have the second.
What does TLS protect?
SMTP servers can upgrade a plain connection to TLS using the STARTTLS extension, defined in RFC 3207. The server announces STARTTLS, the client asks to start TLS, and both sides negotiate encryption.
Constructed example: Ana in a small firm emails a supplier. Her mail server hands the message to the supplier's server over a TLS connection, so someone watching the wire sees ciphertext. But each server along the path decrypts the message to process it. Both mail providers can read it, and so can anyone who breaks into them or compels them.
So TLS covers the network hops. It does not cover storage on the servers, or the mailbox once the message arrives.
Why can a downgrade attack beat opportunistic TLS?
RFC 3207 itself describes the weakness. A man in the middle attack can be launched by deleting the STARTTLS announcement from the server's response, so the client never tries TLS. Another is altering the client's request to start TLS and the server's reply. The RFC says clients and servers must be configurable to require successful TLS negotiation for selected hosts before delivering mail, and that using TLS when possible should also be offered.
"When possible" is the common default, and it is exactly what an attacker can break.
What does MTA-STS add?
RFC 8461 defines SMTP MTA Strict Transport Security. It lets a mail provider declare that it can receive TLS connections and specify whether sending servers should refuse to deliver to mail hosts that do not offer TLS with a trusted certificate. It also has an optional testing mode so you can detect policy failures before enforcing. The document notes that the main motivation is giving domains a way to ensure transport security when deploying DNSSEC is undesirable or impractical.
In plain words: you publish a policy that says "only deliver to me over verified TLS", and compliant senders obey it.
What does S/MIME protect?
RFC 8551 specifies S/MIME 4.0. It provides authentication, message integrity and non-repudiation of origin through digital signatures, and data confidentiality through encryption. The sender encrypts to the recipient's certificate, so the content stays unreadable to mail servers in between.
The cost is operational. Both parties need certificates, you need a way to find and trust the other side's certificate, and lost private keys can mean unreadable mail. Search, spam filtering and archiving on the server also stop working on encrypted content, which may conflict with your compliance and e-discovery duties.
Which one do you need?
- For almost everyone: TLS on all mail flow, plus MTA-STS on your domain.
- For regulated or very sensitive exchanges: message level encryption, or a secure portal that delivers a link instead of the content.
- For proof of origin: signatures, even without encryption.
HIPAA's transmission security standard asks you to guard against unauthorized access to ePHI sent over a network and lists encryption as addressable, so documented risk analysis decides which layer you use.
How to check or apply this
- Check whether your mail servers offer TLS and which versions. Disable old ones.
- Test outbound mail to your key partners and record whether TLS is used.
- Publish an MTA-STS policy in testing mode, review reports, then enforce.
- Identify the small set of mail that needs end to end protection and choose S/MIME or a portal for it.
- Plan certificate issuance, renewal and revocation before you roll out S/MIME.
- Tell staff what encrypted email does not hide: sender, recipient and subject lines are often visible to servers.
Quick check
Is email encrypted by default?
Often in transit between servers, but usually only opportunistically. Message contents are normally readable by the providers that handle them.
Does S/MIME replace TLS?
No. They work at different layers. TLS protects each hop and S/MIME protects the message. Use TLS everywhere and S/MIME where you need end to end confidentiality.
Sources
- RFC 3207, SMTP Service Extension for Secure SMTP over TLS
- RFC 8461, SMTP MTA Strict Transport Security
- RFC 8551, S/MIME Version 4.0 Message Specification
- 45 CFR 164.312, Technical safeguards
Last reviewed: 18 October 2026.
