TLS for Email: What It Means and Why It Matters

Transport layer security for email (TLS) is the cryptographic protocol that encrypts the connection between mail servers as email travels across the internet. Without TLS, email is transmitted in plaintext, readable by anyone who can intercept the network traffic along the delivery path. TLS 1.2 and TLS 1.3 are the current recommended versions. TLS protects email on the wire but does not protect email stored on mail servers.

If your mail server has STARTTLS enabled and you consider email encryption handled, you may have a significant false sense of security. Most organizations using STARTTLS believe their email is encrypted. Under normal conditions it is. Under a targeted STARTTLS downgrade attack, it is not, and neither the sender nor the recipient receives any warning that the encryption failed.

What Is TLS in Email Security?

Transport layer security for email is the cryptographic protocol that encrypts the SMTP connection between mail servers during email delivery. Before TLS, email transmitted between servers crossed the internet in plaintext, readable by anyone with access to a network switch, router, or exchange point along the delivery path.

TLS also encrypts the connection between email clients and mail servers when users send, retrieve, or access email. NIST SP 800-177 identifies TLS 1.2 and TLS 1.3 as the minimum required versions for all email transmission. For broader context on how TLS fits the complete email security stack, see The Complete Guide to Email Security.

What Is the Difference Between SSL and TLS?

SSL (Secure Sockets Layer) was the original encryption protocol developed by Netscape in the 1990s. TLS is its successor, first released as TLS 1.0 in 1999. SSL is fully obsolete. SSL 3.0 was broken by the POODLE attack, documented as CVE-2014-3566, and must be disabled on any server still running it. When you encounter the term “SSL certificate” in everyday usage, it almost always refers to a TLS certificate using the same X.509 standard.

Version	Release Year	Current Status	Key Feature or Vulnerability
SSL 3.0	1996	Deprecated, must be disabled	Vulnerable to POODLE attack (CVE-2014-3566)
TLS 1.0	1999	Deprecated	BEAST and POODLE-TLS vulnerabilities
TLS 1.1	2006	Deprecated	Minor improvement over TLS 1.0, still obsolete
TLS 1.2	2008	Recommended	Strong security, current baseline for compliance
TLS 1.3	2018	Recommended (preferred)	Removes legacy cipher suites, forward secrecy by default

How Does TLS Protect Email in Transit?

TLS protects email by encrypting the SMTP connection between mail servers. When your mail server sends to a recipient’s server, a TLS handshake establishes an encrypted session before any message content is transmitted.

The TLS handshake for email follows this sequence: the sending server connects to the receiving server on SMTP port 25, the servers negotiate the TLS version and cipher suite, certificates are exchanged and verified against trusted Certificate Authorities, an encrypted session is established, and email content is transmitted through the encrypted connection.

The critical distinction that most tls email security articles skip entirely is what TLS does not protect.

TLS encrypts the connection, not the stored message. Email is a store-and-forward protocol: the message is received, stored, and then forwarded at each mail server along the delivery path. At each server where the message is stored, it is decrypted and accessible in plaintext to anyone with access to that server.

When your finance director sends an email to a supplier, TLS encrypts the SMTP session between your outgoing mail server and the supplier’s receiving server. When the message arrives at the supplier’s server, it is decrypted and stored. It is readable to the supplier’s mail server administrator, to anyone who compromises the supplier’s server, and to any hosting provider managing that infrastructure. The TLS connection protected the wire. The stored message is not protected.

For organizations that require protection of the message itself regardless of which servers it passes through, TLS in transit is not sufficient. See our guides on S/MIME and PGP: End-to-End Email Encryption Explained and How Does Email Encryption Work? A Plain-English Guide.

What Is STARTTLS and How Does It Work?

STARTTLS is an SMTP extension command that upgrades an existing plaintext SMTP connection to an encrypted TLS connection. It is the mechanism most mail servers use to encrypt server-to-server email delivery.

The process works as follows: the sending mail server connects to the receiving server on port 25, the receiving server includes STARTTLS in its capability list during the SMTP greeting, the sending server issues the STARTTLS command, and the connection upgrades to TLS before any message content is transmitted.

STARTTLS is opportunistic. If the receiving server does not advertise STARTTLS support, the sending server delivers email in plaintext without any error or warning. This opportunistic fallback is both its practical advantage (near-universal adoption) and its critical weakness.

For port context: STARTTLS operates on SMTP port 25 for server-to-server delivery and port 587 for email submission from clients. Implicit TLS uses port 465, starting with TLS from the first connection byte rather than upgrading after the initial greeting.

What Is the Difference Between STARTTLS and TLS?

STARTTLS is the SMTP command that initiates the upgrade to TLS encryption. TLS is the actual encryption protocol. The two are not the same, and the difference in failure behavior is what matters for security.

When a sending mail server initiates an SMTP connection, it receives the receiving server’s greeting listing supported capabilities, including the STARTTLS advertisement. The sending server reads this list and issues the STARTTLS command to upgrade to an encrypted session.

In a downgrade attack, an attacker positioned to intercept the SMTP session modifies the receiving server’s greeting before it reaches the sending server, removing the STARTTLS entry from the capability list. The sending server reads the modified greeting, sees no TLS support listed, and delivers the email in plaintext.

No error is generated. No delivery failure occurs. The sending mail server logs show a successful delivery. The email was sent without encryption. The sender and recipient receive no indication that encryption did not happen.

This is precisely what MTA-STS closes. When a domain has published an MTA-STS enforce policy, a sending server that supports MTA-STS will refuse to deliver the email if TLS is unavailable or if the certificate is invalid. The plaintext fallback is blocked. The delivery failure is visible and logged rather than silently succeeding without encryption.

Organizations relying solely on STARTTLS believe their email is encrypted because under normal conditions it is. Under a targeted downgrade attack, STARTTLS provides no protection because it accepts the plaintext fallback without notification. For how this fits the full architecture, see Email Security Architecture: How the Full Stack Fits Together.

What Is an Email Security Certificate and Why Do You Need One?

An email security certificate is a digital X.509 certificate installed on a mail server that enables TLS encryption and authenticates the server’s identity. The certificate contains a public key, is issued by a trusted Certificate Authority, and carries a defined validity period of one to two years.

Certificate expiry is a silent email delivery failure trigger that most IT teams discover at the worst possible moment.

When a mail server TLS certificate expires, the consequences depend on the receiving server’s TLS policy. Servers enforcing strict TLS refuse the SMTP connection, generating a delivery failure. Servers using opportunistic TLS may fall back to plaintext delivery, meaning email continues to flow but is now transmitted unencrypted. In both cases the sender receives a generic delivery failure or delayed delivery warning with no clear indication that certificate expiry is the cause. The symptom looks the same as many other infrastructure problems, making diagnosis slow and the disruption long.

Let’s Encrypt provides free automated certificate renewal for mail servers that support it and is the recommended choice for organizations without a managed certificate procurement process. For servers requiring manual renewal, set calendar reminders at 60 and 30 days before expiry. Monitor certificate validity monthly using MXToolbox or Hardenize.

If TLS failure causes opportunistic fallback to plaintext, sensitive email transmits unencrypted without anyone realizing encryption has failed. This is not just an operational inconvenience. It is a security regression that appears completely invisible from the sender’s perspective.

What Are the Limitations of Opportunistic TLS for Email?

Opportunistic TLS encrypts most email in transit under normal conditions but has two critical weaknesses that make it insufficient as a sole protection mechanism.

The first is susceptibility to downgrade attacks. STARTTLS falls back to plaintext when TLS is unavailable, whether due to a genuine technical limitation or a deliberate attacker-controlled modification of the SMTP session greeting. This fallback is silent on both sides.

The second is the absence of certificate verification. Opportunistic TLS does not confirm that the certificate presented by the receiving server is actually valid for that domain. An attacker positioned between two mail servers can present a fraudulent certificate and intercept the encrypted session without triggering any verification failure. These two weaknesses combine to leave targeted communications vulnerable even when TLS appears to be in use.

What Is MTA-STS and How Does It Enforce TLS?

MTA-STS, defined in RFC 8461, solves both weaknesses of opportunistic TLS by publishing a policy that instructs sending servers to require TLS and verify the certificate before delivering email to the domain.

The implementation requires two components: a DNS TXT record pointing to the policy file and an HTTPS-hosted policy file at mta-sts.yourdomain.com. The policy specifies the mode: testing (report failures but still deliver) or enforce (refuse delivery if TLS is unavailable or the certificate is invalid).

Deploy MTA-STS in testing mode first. TLS-RPT, the companion reporting standard, generates daily summaries of TLS connection results for your domain, making MTA-STS observable rather than operating blindly. Review TLS-RPT failure reports for two to four weeks, identify any sending servers encountering TLS failures, and progress to enforce mode once delivery is confirmed clean.

For server-level implementation context, see Email Server Security: How to Protect Your Mail Server and SPF, DKIM and DMARC Explained.

What Is DANE Email Security?

DANE (DNS-based Authentication of Named Entities), defined in RFC 7672 for email, ties TLS certificate verification to DNSSEC-protected DNS records rather than relying on the public Certificate Authority trust hierarchy.

When a sending server connects to a DANE-enabled receiving server, it looks up the TLSA record in DNS. This record specifies which certificate is valid for that mail server. If the certificate presented during the TLS handshake does not match the TLSA record, the connection is rejected. This prevents man-in-the-middle attacks using fraudulent certificates even when an attacker obtains a fraudulent certificate from a compromised CA, because the TLSA record in DNSSEC-signed DNS specifies the correct certificate independently.

DANE requires DNSSEC deployment on the domain. MTA-STS does not require DNSSEC, making it simpler to implement for most enterprise organizations.

Standard	What It Does	Protects Against	Requires DNSSEC	Adoption Level
STARTTLS (opportunistic)	Upgrades SMTP to TLS when available	Basic eavesdropping in normal conditions	No	Near universal
Implicit TLS	Starts all connections with TLS	Eavesdropping, no plaintext fallback	No	High for submission
MTA-STS	Enforces TLS and cert validation	Downgrade attacks, cert substitution	No	Growing, enterprise focus
DANE	Binds cert verification to DNSSEC records	Fraudulent certs, CA compromise, MITM	Yes (required)	Growing, ISP and European government

How Do You Check and Enforce TLS for Your Email?

Use MXToolbox TLS checker, Hardenize, or Qualys SSL Server Test to assess your current mail server TLS configuration. Verify TLS 1.2 and 1.3 are enabled and TLS 1.0, TLS 1.1, and SSL 3.0 are all disabled. Confirm your email security certificate is valid and not within 60 days of expiry.

Implement MTA-STS in testing mode, configure TLS-RPT reporting, review failure reports for two to four weeks, and progress to enforce mode once delivery is confirmed clean. Ensure email submission on port 587 requires TLS and does not permit plaintext connections.

UK NCSC TLS guidance and NIST SP 800-177 both define the recommended baseline configurations for mail server TLS enforcement. Cyber Security Solutions Ltd can review your current TLS configuration as part of a free email security assessment, confirming your email is actually encrypted in transit and protected against downgrade attacks.

Conclusion

Transport layer security for email is the baseline protection that encrypts email in transit, but STARTTLS alone provides weaker protection than most IT teams realize. MTA-STS enforces the encryption guarantee that STARTTLS cannot provide. Certificate monitoring prevents silent failures that look like other problems. To verify your current TLS configuration is correctly enforced, visit cybersecuritysolutionsltd.com for a free email security assessment.