Key Insights
TLS email security is what most people are describing when they say their email is "encrypted." Every time a client logs in, every time one server hands a message to another, a TLS handshake stands between the traffic and whoever is watching the wire. Not bad for a retrofit onto a mail protocol designed when everything moved in the clear.
It is also a narrower guarantee than the word "encrypted" suggests. TLS protects a connection for as long as that connection lasts, and an email passes through several connections and several servers on its way to a mailbox. Knowing exactly where each protected segment begins and ends, and what happens in the gaps between them, separates assuming a message was secure from knowing what secured it.
Key Takeaways
TLS secures the network connections that carry email between clients and servers, but leaves the message itself readable at every server along the path.
Opportunistic STARTTLS is the default for server-to-server relay, and either side can silently fall back to plaintext when encryption fails or is stripped.
MTA-STS, DANE, TLS-RPT, and REQUIRETLS convert TLS from a preference into a published, verifiable requirement that senders can enforce and receivers can monitor.
Content encryption with S/MIME or OpenPGP is the only protection that follows a message through relays, forwards, and long-term storage after the last TLS session closes.
What Is TLS Email Security?
TLS email security is the use of Transport Layer Security (TLS) to encrypt the individual network connections that carry a message between mail clients and mail servers, so the bytes on each link can't be read or altered while moving. The protection applies to the connection, not the message: the two sides perform a handshake and encrypt everything they exchange for that session, and in practice every server in the path still handles the message in plaintext, decrypting it, routing it, and re-encrypting only the next hop.
NIST's Trustworthy Email guidance places TLS in the middle of a three-layer stack: domain authentication (SPF, DKIM, DMARC) confirms who sent a message, TLS protects it in transit, and content security (S/MIME or OpenPGP) protects what only the intended reader can open. A message can arrive over a flawless TLS connection and still be a phishing email from a spoofed domain, because TLS never checks who wrote it.
How TLS Email Security Works Across the Delivery Path
A typical message crosses at least three separately negotiated TLS connections between the sender's outbox and the recipient's inbox, and each begins and ends at a mail server that sees the message unencrypted. The IETF's Internet Mail Architecture spells out the roles: a mail client hands the message to a submission server, which passes it through one or more relay servers to the recipient's mailbox store.
Submission opens the first connection, typically on port 587 with a STARTTLS upgrade or port 465 with TLS negotiated before any command is sent; because this connection carries the user's password, the client is expected to validate the server's certificate. The submitting server then looks up the recipient domain's MX records and opens a new, unrelated connection on port 25, upgrading to TLS with STARTTLS if the receiving server offers it; a message routed through a filter, list, or forwarding rule repeats this negotiation at every extra hop, under that hop's own policy.
The final connection belongs to the recipient, who retrieves the message over IMAP or POP3, both encrypted from the first byte. This connection cannot retroactively protect anything that happened upstream, including a message already exposed on an earlier relay or sitting unencrypted at rest.
STARTTLS, Implicit TLS, and Enforced TLS
Email can negotiate TLS inside an already-open plaintext session, assume encryption from the first byte on a dedicated port, or have administrators require it as a condition of delivery. STARTTLS, standardized by the IETF in 2002, lets two servers convert a plaintext connection into an encrypted one: the receiving server advertises the capability, the sender requests it if it chooses, and nothing obliges either side to use it or to reject a bad certificate. Most MTAs that hit a failed handshake, or an expired or self-signed certificate, retry in plaintext rather than give up.
Implicit TLS takes the opposite approach: a dedicated port, such as 465, 993, or 995, where the handshake happens before any command is exchanged, leaving nothing for an attacker to strip. Researchers at USENIX Security 2021 concluded that STARTTLS adds complexity without adding security over implicit TLS, yet some popular clients still default to it. Relay on port 25 has no implicit alternative.
Administrators who want a verifiable requirement there turn to enforcement instead: a per-domain rule that mail to a destination must use TLS with a valid, matching certificate, or be held rather than delivered in plaintext, usually scoped to specific partners since a global rule would refuse delivery to every misconfigured domain.
Why TLS Email Security Matters
TLS email security matters because SMTP without it moves message bodies and login credentials in cleartext across networks neither the sender nor the recipient controls, and the protocol was built that way. Without TLS, any attacker between two mail servers can read or alter a message with neither endpoint able to tell; with TLS on that hop, a purely passive attacker sees only ciphertext, but an attacker who can modify traffic can still steer the negotiation toward plaintext, which is why TLS's value depends on whether both servers authenticate each other and refuse to proceed without it.
The TLS version a server negotiates decides which of those attacks are possible. The IETF formally deprecated TLS 1.0 and 1.1, and NIST's TLS configuration guidelines require government servers and clients to support TLS 1.2 with FIPS-approved cipher suites and required TLS 1.3 support by January 1, 2024. Because relay is opportunistic, a receiving server that still accepts an old TLS version will negotiate it with an outdated peer; some hosted platforms have dropped the old versions on both sides, while a self-managed server inherits whatever its distribution shipped with.
Where TLS Email Security Falls Short
The weaknesses of TLS email security trace to a single design choice: opportunistic STARTTLS treats encryption as negotiable, so an attacker positioned between two servers can defeat it by routing around the cryptography rather than breaking it, and the protection ends the moment a message stops moving.
STARTTLS stripping exploits the fact that the offer to encrypt travels in plaintext: an attacker who controls a router deletes the "250 STARTTLS" line from the receiving server's response, and the sender, seeing no offer, sends the message in the clear exactly as the protocol instructs, with neither side logging an error. Durumeric and colleagues found that 96.13% of mail sent from Tunisia to one major U.S. mail provider during a one-week window in April 2015 had its STARTTLS offer stripped in transit, alongside similar patterns at corporate, ISP, and hotel networks elsewhere.
Even when STARTTLS succeeds, the sender often has no idea whether it encrypted to the right server, since the specification never said what an MTA should do with an invalid certificate: Blechschmidt and colleagues' USENIX Security 2023 scan of the top 10 million domains found that 30.0% of STARTTLS certificate validations produced some error, a gap that lets an attacker who redirects DNS or MX resolution present their own certificate and read or modify mail while the sender's logs show a clean delivery.
A sender also controls TLS policy on exactly one hop: mail routed through a third-party filter or forwarding rule is re-delivered under that intermediary's own policy, which NIST notes can expose a message no matter how well the other hops were protected. Finally, protection ends the moment a connection closes, and a message spends most of its life with no connection open at all, sitting in a queue or mailbox in whatever form that storage system uses, readable by anyone with access to it without ever touching TLS.
The Upgrade Path to Authenticated TLS
Four IETF standards convert TLS for email from a negotiation either server can quietly abandon into a published, verifiable requirement: MTA-STS, SMTP TLS Reporting (TLS-RPT), DANE, and REQUIRETLS.
Control | Where the policy lives | What it authenticates | Main limitation |
|---|---|---|---|
Opportunistic STARTTLS | Nowhere; advertised inside each SMTP session | Nothing; certificates typically accepted without checks | Strippable and redirectable by an on-path attacker |
MTA-STS | A DNS TXT record plus a policy file over HTTPS | MX hostnames and Web PKI certificates | Trust on first use; discovery can be downgraded |
TLS-RPT | A DNS TXT record naming a reporting address | Nothing; a reporting channel | Depends on senders that support reporting |
DANE | DNSSEC-signed TLSA records in the domain's zone | The certificate bound to each MX host | Requires DNSSEC on the receiving domain |
REQUIRETLS | An SMTP extension and message header | Nothing directly; a per-message requirement | Every hop must support it |
MTA-STS lets a receiving domain publish, in DNS and a small HTTPS policy file, that mail to it must arrive over authenticated TLS with a certificate matching an approved MX host; a sender that supports it fetches the policy and, in enforce mode, queues rather than delivers a message that fails the check. It deliberately skips DNSSEC to stay deployable, which also means an attacker present at first contact can suppress the policy entirely. TLS-RPT closes the visibility gap: a domain publishes a reporting address, and supporting senders send daily reports on the TLS failures they hit.
DANE moves trust from certificate authorities to DNSSEC-signed records binding a certificate to each mail host, closing the trust-on-first-use gap MTA-STS leaves open, but only on domains that sign their zone with DNSSEC. REQUIRETLS works at the message level instead: a sender attaches a header asking that one message be delivered only over TLS at every hop, turning a failed negotiation into a bounce rather than a silent downgrade. A 2025 ACM census of the .com zone found MTA-STS deployment still limited even among adopting domains, with frequent misconfiguration.
TLS Compared With End-to-End Email Encryption
End-to-end encryption and TLS protect different things. End-to-end encryption protects the message body itself, so every server along the path stores ciphertext it can't read. TLS protects the connection between servers instead; neither replaces the other.
S/MIME uses X.509 certificates, the same kind that secure websites, so a sender's client encrypts the body with the recipient's public key and signs it with their own. Because the protection lives in the message, a relay server stores ciphertext and an archived message is still unreadable years later without the key, though certificate distribution between organizations with no shared directory remains an obstacle.
OpenPGP delivers the same confidentiality and integrity without a certificate authority, trusting a public key through direct verification or a "web of trust," but it usually arrives as a plug-in, and decades of usability research, starting with the original "Why Johnny Can't Encrypt" study, documented serious failures when people try to sign and encrypt a message themselves.
TLS and end-to-end encryption fail in complementary places: TLS protects every message on a hop, including login credentials, but stops at each server and can be downgraded; end-to-end encryption protects content at rest, but protects nothing about the account, since a captured password lets an attacker download the entire encrypted mailbox and wait for a key to leak. The EFAIL research showed some mail clients could even be tricked into decrypting and exfiltrating content when an attacker spliced ciphertext into a new message.
TLS Email Compliance Requirements
Compliance frameworks treat TLS in transit as an expected baseline and split on whether message content must also be encrypted. The HIPAA Security Rule lists encryption as an "addressable," not required, safeguard for health information in transit, so a covered entity must assess and document whether it's reasonable; opportunistic TLS sits awkwardly in that framework, and a proposed HHS rule would remove the addressable designation and require encryption of all health data at rest and in transit.
GDPR's Article 32 names encryption as a measure proportionate to risk, and the UK Information Commissioner's Office calls for TLS 1.3 on data in transit, but European regulators have found organizations in breach of Article 32 for relying on transport encryption alone when sending sensitive data externally.
PCI DSS version 4.0 is the framework where TLS alone most clearly falls short: Requirement 4.2.2 requires that a card number be protected with strong cryptography whenever it's sent by email specifically, a requirement opportunistic STARTTLS can't meet since it may not be negotiated on every hop. CISA's Binding Operational Directive 18-01 requires U.S. civilian agencies to offer STARTTLS on every mail server and disable outdated ciphers, separate from its SPF and DMARC requirements, and the UK's NCSC recommends MTA-STS for the same reason.
How to Evaluate TLS Email Protection
Evaluating TLS coverage means checking encryption and destination authentication at each hop, and determining whether a failure would even be visible to anyone.
Three checks together cover the hop-by-hop picture, from what each delivery actually did to what the domain's published policy requires:
Delivery-Path Headers: Read a test message's Received headers from bottom to top; a server that accepted the connection over TLS typically marks it, and a line with no TLS marker identifies a plaintext hop precisely.
Certificate and Version Checks: Connect to each MX host directly and confirm the certificate is unexpired, publicly trusted, and name-matched; confirm TLS 1.2 is the floor and TLS 1.3 is available, with TLS 1.0, TLS 1.1, and all SSL versions disabled.
Policy and Reporting: Confirm whether the domain publishes an MTA-STS policy in enforce mode with a matching MX list, whether DNSSEC and TLSA records exist for DANE, and whether anyone actually reads the TLS-RPT reports a domain or its partners generate.
Header checks describe what happened on the messages someone bothered to test, while certificate, policy, and reporting checks speak to every message the domain handles whether anyone looked or not.
Make TLS the Security Floor, Not the Ceiling
Current TLS on every hop is the minimum a mail domain should offer, and on its own it stops only attackers who watch without acting. MTA-STS or DANE make the relay hop refuse plaintext, TLS reporting shows where that refusal would bite, domain authentication stops forgery, and content encryption protects what sits in mailboxes after every connection closes. Reading a domain's own Received headers and TLS reports for a month is the quickest way to learn which of those layers it actually has.
Frequently Asked Questions
How Can a Recipient Tell Whether an Email Used TLS?
The Received headers on the message list each server that handled it, and servers that accepted the connection over TLS usually include a TLS marker in their entry. Reading those entries from the bottom up shows each hop in order; an entry without a TLS notation is a hop that ran in plaintext. A sender-side padlock indicates TLS on the outbound delivery hop, and says nothing about later hops.
Does Forwarding an Email Preserve TLS Protection?
No. Forwarding creates a new connection under the forwarding server's own policy, so a message can leave in plaintext regardless of how securely it first arrived. Only content encryption such as S/MIME or OpenPGP survives a forward.
Does Port 465 Use STARTTLS?
No. Port 465 is the implicit TLS port for SMTP submission, where the TLS handshake completes before any SMTP command is exchanged. STARTTLS belongs to port 587, where the session starts in plaintext and upgrades midstream. A client that sends the STARTTLS command on port 465 should receive an error under IETF draft guidance, because there is no plaintext phase to upgrade from. Both ports can be configured securely; the difference is whether an on-path attacker gets a window to interfere before encryption begins.
Can TLS Protect Archived Email?
No. TLS protects data only while it moves across a connection, and an archived message isn't moving. Protection for stored mail comes from encryption applied by the storage system, from content encryption such as S/MIME or OpenPGP that keeps the message body encrypted wherever it sits, or from access controls on the archive itself. A message that arrived over enforced TLS and one that arrived in plaintext are indistinguishable once they're on disk.