What Is TLS in Email and How Does It Protect Your Messages

When you send an email, it does not teleport from your inbox to the recipient. It travels across the internet, hopping between mail servers, passing through networks you do not control. Without encryption, anyone along that path could read your message in plain text.

This is where TLS comes in. Transport Layer Security is the protocol that encrypts your email while it is moving between servers. It is the single most important protection for everyday email, and most people have never heard of it. Here is what TLS does for your email, how it works, and where its protection ends.

What Is TLS? A Simple Explanation

TLS stands for Transport Layer Security. It is a cryptographic protocol that encrypts data as it travels between two points on a network. You encounter TLS every day without realizing it: when your browser shows a padlock icon next to a website URL, that connection is secured with TLS.

TLS is the successor to SSL (Secure Sockets Layer), which was developed in the 1990s. While people still sometimes say "SSL," the protocol in use today is TLS. The current version is TLS 1.3, released in 2018, which is faster and more secure than its predecessors.

For email, TLS serves the same purpose as it does for websites: it creates an encrypted tunnel between two systems so that anyone eavesdropping on the connection sees only scrambled data instead of readable text.

How TLS Works in Email

Email uses a protocol called SMTP (Simple Mail Transfer Protocol) to send messages between servers. SMTP was designed in 1982, long before encryption was a concern. By default, SMTP transmits everything in plain text.

To add encryption to SMTP without replacing the entire protocol, a mechanism called STARTTLS was introduced. Here is how it works:

1. Your mail server connects to the recipient's mail server on the standard SMTP port (usually port 25 for server-to-server communication).
2. The connection starts unencrypted, in plain text.
3. Your server sends the command STARTTLS, which is essentially asking: "Do you support encryption?"
4. If the receiving server supports TLS, it responds affirmatively.
5. Both servers perform a TLS handshake: they agree on an encryption method, exchange cryptographic keys, and establish an encrypted connection.
6. Your email is transmitted over this encrypted connection.

The name "STARTTLS" can be confusing because it sounds like it starts TLS from scratch. In reality, it upgrades an existing plain-text connection to an encrypted one. Think of it as switching from an open phone line to a scrambled one mid-call.

Implicit TLS vs. STARTTLS

There is another approach called implicit TLS, where the connection is encrypted from the very first byte. This is common for email submission (port 465) where your email client connects to your outgoing mail server. With implicit TLS, there is no initial plain-text phase and no upgrade step. The connection is encrypted immediately.

For server-to-server email delivery (the hops between mail servers), STARTTLS on port 25 is the standard. For client-to-server connections (your email app talking to your provider), implicit TLS on port 465 or STARTTLS on port 587 are common.

Opportunistic TLS vs. Enforced TLS

This is one of the most important distinctions to understand about TLS in email.

Opportunistic TLS

Most email servers use opportunistic TLS. This means: "I will try to use encryption, but if the other server does not support it, I will send the email in plain text anyway."

The logic is practical. If a server only accepted encrypted connections, it would be unable to communicate with the many servers that still do not support TLS, and emails would bounce. Opportunistic TLS ensures delivery even when encryption is not available.

The downside is that opportunistic TLS is vulnerable to downgrade attacks. An attacker positioned between two mail servers (a man-in-the-middle) could strip out the STARTTLS command, making both servers think the other does not support encryption. The email would then be sent in plain text without either server realizing it.

Enforced TLS

Enforced TLS (sometimes called mandatory TLS) means the server refuses to send or receive email unless the connection is encrypted. If the other server does not support TLS, the email is not delivered.

This is more secure but can cause delivery failures. It is typically used between organizations that have agreed to require encryption for their communications, such as financial institutions or healthcare providers.

What TLS Protects in Email

TLS provides meaningful protection, but it is important to be precise about what it covers:

• Email content in transit: The body of your email, including attachments, is encrypted while traveling between mail servers. Anyone intercepting the network traffic sees encrypted data.
• Authentication of servers: TLS uses certificates to verify that the server you are connecting to is who it claims to be, reducing the risk of sending email to an impersonator.
• Protection against passive surveillance: Governments, ISPs, or network operators passively monitoring internet traffic cannot read TLS-encrypted email content.

What TLS Does NOT Protect

This is equally important to understand:

• Email at rest: Once your email arrives at the destination server, TLS protection ends. The email is stored on the server, and its security depends on how that server handles storage. TLS only protects data in transit, not data at rest.
• Metadata: Even with TLS, the mail servers involved in delivery can see who sent the email, who received it, the subject line, timestamps, and other header information. TLS encrypts the connection, not the metadata.
• Intermediate server access: If your email passes through multiple servers (which is common), each server decrypts the email to process it and then re-encrypts it for the next hop. Each intermediate server has momentary access to the plain-text content.
• Recipient's server: The receiving mail server can read your email. TLS does not prevent the email provider from accessing your messages.

How to Check If Your Email Was Sent Over TLS

In Gmail

Gmail makes this straightforward:

1. Open the email you want to check.
2. Look for a small lock icon next to the sender's name. A gray lock means standard TLS encryption. A red open lock means no encryption. A green lock means enhanced encryption (S/MIME).
3. For more detail, click the three dots menu and select Show original. Look for lines like TLS 1.3 or TLS 1.2 in the Received headers.

In Email Headers

In any email client, you can inspect the raw headers. Look for lines like:

Received: from mail.example.com (mail.example.com [192.0.2.1])
        by mx.google.com with ESMTPS id abc123
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)

The key indicators are ESMTPS (the S means the connection was secured) and the TLS version and cipher information. If you see ESMTP without the S, that hop was not encrypted.

MTA-STS - Enforcing TLS for Your Domain

One of the weaknesses of opportunistic TLS is that it can be downgraded. MTA-STS (Mail Transfer Agent Strict Transport Security) addresses this by letting a domain declare: "Always use TLS when sending email to my servers, and do not fall back to plain text."

MTA-STS works through a policy file hosted on the domain's web server and a DNS record that points to it. When a sending server wants to deliver email to a domain with MTA-STS, it checks the policy and enforces TLS accordingly.

To implement MTA-STS for your domain:

1. Create a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.
2. The file specifies your mail servers and the policy mode (enforce, testing, or none).
3. Add a DNS TXT record at _mta-sts.yourdomain.com pointing to the policy version.

MTA-STS is supported by Gmail, Outlook, and other major providers. It is one of the most effective ways to ensure that email sent to your domain is always encrypted in transit.

DANE - DNS-Based TLS Enforcement

DANE (DNS-based Authentication of Named Entities) is another mechanism for enforcing TLS, and it is arguably more robust than MTA-STS. DANE uses DNSSEC-signed DNS records (TLSA records) to publish the exact TLS certificate a mail server should present.

When a sending server supports DANE, it looks up the TLSA record for the recipient's mail server. If the record exists and the certificate matches, the connection proceeds with TLS. If the certificate does not match, the connection is refused. This prevents both downgrade attacks and certificate impersonation.

DANE requires DNSSEC, which adds complexity. Not all domains or DNS providers support DNSSEC, which has limited DANE's adoption compared to MTA-STS. However, in regions where DNSSEC is more common (such as the Netherlands and Germany), DANE is widely deployed.

TLS vs. End-to-End Encryption

TLS and end-to-end encryption are fundamentally different, and confusing them is a common mistake.

TLS encrypts the connection between two servers. Each server in the chain can read the email content. It is like sending a letter in a locked pouch that gets unlocked and re-locked at each post office along the way.

End-to-end encryption (using PGP or S/MIME) encrypts the email content itself, so that only the sender and the intended recipient can read it. The mail servers in between handle an encrypted blob they cannot decrypt. It is like sending a letter in a safe that only the recipient has the key to.

For most people, TLS provides sufficient protection. End-to-end encryption is important for highly sensitive communications but adds significant complexity: both parties need to manage encryption keys, and encrypted emails cannot be searched or filtered by the mail server. For a detailed comparison, see our article on email encryption: TLS, PGP, and S/MIME.

TLS Email Encryption in Practice

According to Google's transparency report, as of 2024, roughly 96% of inbound email to Gmail is encrypted with TLS, and about 96% of outbound email from Gmail uses TLS. This is a dramatic increase from just a few years ago, when the figures were closer to 60-70%.

The push toward universal TLS encryption in email has been driven by a combination of factors: post-Snowden awareness, Google's transparency reports shaming non-TLS domains, the Let's Encrypt project making TLS certificates free, and the growing adoption of MTA-STS and DANE.

That said, the remaining 4% of unencrypted email is still significant at Google's scale, representing millions of messages per day traveling across the internet in plain text.

How Cleanbox Handles TLS

All SMTP connections to and from Cleanbox servers use TLS encryption. Inbound email is received over encrypted connections, and outbound forwarding to your mailbox uses TLS as well. For more on how encryption fits into the broader email security landscape, read our article on the importance of TLS encryption in email.

Practical Takeaways

TLS is not a silver bullet, but it is the foundation of email security. Here is what matters:

• For most users: TLS works automatically. You do not need to do anything to benefit from it. Your email provider handles TLS negotiation on your behalf.
• For domain owners: Implement MTA-STS or DANE to enforce TLS for email sent to your domain. This prevents downgrade attacks and ensures your incoming email is always encrypted in transit.
• For sensitive communications: TLS alone is not enough. Consider end-to-end encryption (PGP or S/MIME) for emails where the content must remain confidential even from the mail servers handling delivery.
• For everyone: Check your email headers occasionally. If you see connections without TLS, it may indicate a problem with your email provider or the sender's infrastructure.

TLS has quietly become one of the most successful security deployments in internet history. Nearly all email now benefits from it. Understanding what it does and what it does not is the first step toward making informed decisions about your email security.