Email encryption in a way that, by default, makes it readable to anyone with access to the network in between. STARTTLS is the protocol that fixes most of this. It is the mechanism that lets two mail servers detect each other’s encryption capabilities mid-conversation and upgrade the connection from plain text to TLS-encrypted without restarting the exchange. The protocol has been in use since the late 1990s, and today it is the default for nearly all mail moving between major mailbox providers.
The “nearly all” is doing meaningful work in that sentence. STARTTLS has a quiet failure mode that can leave mail unencrypted even when both parties support encryption, and most senders never notice because the failure does not produce a visible error. MTA-STS and email authentication layered on top of STARTTLS address this gap. Understanding both is important for any sender whose mail contains data that should not be intercepted in transit.
What does STARTTLS do in one paragraph?
STARTTLS is an SMTP extension that allows an unencrypted email connection to be upgraded to an encrypted one mid-conversation. The two mail servers connect in plain text, exchange capability information, and either side can request encryption by issuing the STARTTLS command. If both sides support it, they perform a TLS handshake over the existing connection and continue the message transfer in an encrypted manner. If either side does not support STARTTLS, the conversation continues unencrypted.
Email deliverability infrastructure — encryption when possible, plain text when not. The model is pragmatic. It works without breaking older mail servers and is invisible to users. It is also exploitable in ways the original protocol designers did not fully anticipate.
The SMTP conversation with STARTTLS — a real example
A simplified example of an SMTP exchange with STARTTLS makes the mechanism concrete.
The connection opens in plain text. The receiving server announces itself:
220 mx.receiving-domain.com ESMTP Postfix
The sending server identifies itself:
EHLO sending-domain.com
The receiving server responds with its capabilities, one of which is STARTTLS:
250-mx.receiving-domain.com Hello sending-domain.com 250-PIPELINING 250-SIZE 52428800 250-STARTTLS 250 ENHANCEDSTATUSCODES
The sending server, seeing STARTTLS in the capabilities, issues the command:
STARTTLS
The receiving server responds with readiness to begin TLS:
220 2.0.0 Ready to start TLS
At this point, both sides perform a standard TLS handshake — certificate exchange, key negotiation, cipher selection — within the existing TCP connection. Once the handshake completes, the connection is encrypted. The sending server then re-issues EHLO (now inside the encrypted tunnel) and proceeds with mail transfer.
The entire pre-encryption portion of the conversation, up to and including the STARTTLS command, is in plain text. The sender’s hostname, the receiver’s hostname, and the capability negotiation are visible to any network observer. Only after the TLS handshake completes does the conversation become opaque.
Opportunistic encryption — the trade-off STARTTLS makes
The fundamental design choice in STARTTLS is that encryption is optional. If either party does not support it, the conversation continues in plain text rather than failing. This was the right choice for the era when STARTTLS was introduced — most mail servers did not support encryption, and refusing to deliver mail without it would have broken email entirely.
The trade-off is that opportunism creates a gap. A network attacker positioned between the two mail servers can interfere with the capability negotiation, remove STARTTLS from the receiving server’s capability list before it reaches the sender, and cause both parties to believe the other does not support encryption. The conversation then proceeds in plain text, with both endpoints unaware that encryption was available.
This is called a STARTTLS stripping attack. It does not break TLS itself — TLS is cryptographically sound — it exploits the unprotected portion of the conversation before TLS is established.
The attack requires the attacker to control or observe the network path between the two mail servers. State-level adversaries, compromised routers, and certain types of nation-state surveillance infrastructure can achieve this. For most threat models, the risk is small in practice. For email containing sensitive data — financial communications, healthcare PHI, legal correspondence, anything regulated under strict privacy frameworks — the risk is worth addressing.
How STARTTLS can fail silently
Beyond active stripping attacks, STARTTLS can fail to encrypt for several other reasons that produce no visible error.
A misconfigured TLS certificate on the receiving side can cause the sender’s mail server to fall back to plain text rather than refuse to deliver. Most sending mail servers do not enforce certificate validation strictly, because doing so historically broke delivery to legitimate but misconfigured receivers.
A receiving mail server that announces STARTTLS but fails the TLS handshake (e.g., a broken TLS implementation, an expired certificate, or an unsupported cipher) typically causes the sender to retry without TLS rather than queue the message for later delivery. inbox vs spam signals.
A receiving mail server that does not support STARTTLS at all is treated as a legitimate plain-text recipient by sending servers. No fallback path warns the sender.
All three of these failures are silent. The mail is delivered. The recipient receives it. Neither party notices that the transport was not encrypted unless they actively monitor TLS usage.
MTA-STS and TLS Reporting — closing the gap
MTA-STS (Mail Transfer Agent Strict Transport Security) is a newer protocol, standardised in 2018, that addresses the gaps in STARTTLS.
The mechanism is straightforward. A domain publishes a policy at a well-known location declaring that it requires TLS for all incoming mail. The policy specifies which MX hostnames are valid for the domain and a policy mode (enforce or testing).
Sending mail servers that support MTA-STS fetch the policy when first delivering to the domain, cache it for a defined period, and refuse to deliver mail in plain text if the policy is in enforce mode. The STARTTLS stripping attack becomes ineffective — the sending server already knows TLS is required, and a stripped STARTTLS response is detected as a protocol violation.
Google Postmaster Tools is the companion protocol. Domains publish a DNS record asking remote mail servers to report TLS-related failures back to a specified address. The reports detail TLS handshake failures, certificate validation problems, and policy violations. Combined with MTA-STS, the reports give the domain owner visibility into TLS problems that would otherwise be silent.
MTA-STS is supported by Gmail, Outlook, Yahoo, and most major mail providers. Adoption among smaller domains has been slower but is growing. Deploying MTA-STS for a sending domain is a one-time setup task (DNS record plus a small static file served over HTTPS) and provides meaningful transport security improvements for any mail sent to that domain.
How to check if your domain’s STARTTLS is working
Several free tools verify STARTTLS configuration.
checktls.com performs a comprehensive test of mail server TLS configuration, including certificate validity, cipher support, and STARTTLS announcement. The detailed output reveals problems that are otherwise invisible.
Hardenize.com and Internet.nl provide broader email security audits that include STARTTLS, MTA-STS, DANE, and authentication checks. Useful for periodic reviews.
For domains using cloud mail providers (Gmail, Microsoft 365), STARTTLS is configured at the provider level and operates correctly by default. The verification work is more important for domains running their own mail servers or using less common hosting providers.
For Google Postmaster Tools users, the Encryption dashboard shows the percentage of mail being received over TLS. Values consistently above 99% indicate STARTTLS is working correctly across the sending operation.
STARTTLS on port 25 vs 587 vs 465
Three TCP ports are commonly used for SMTP, and their relationship to TLS is worth understanding.
Port 25 is the original SMTP port, used for how Gmail processes emails. STARTTLS is the standard mechanism for adding encryption on port 25 — connections begin in plain text and upgrade. This is the dominant pattern for inter-server mail.
Port 587 is the submission port, intended for mail clients submitting mail to their own outbound server. STARTTLS is recommended (and increasingly required) on port 587. Modern mail clients negotiate STARTTLS by default when connecting to a submission server.
Port 465 was originally an experimental encrypted SMTP port that was deprecated, then revived as the standard port for implicit TLS — connections begin in TLS immediately, with no STARTTLS upgrade. Many mail clients now support port 465 for outbound submission, particularly for cloud providers.
The practical implication: STARTTLS is the dominant mechanism on ports 25 and 587. Port 465 uses implicit TLS, which is not vulnerable to STARTTLS stripping. For server-to-server transfers (the inter-server side of most deliverability questions), port 25 with STARTTLS is the default.
STARTTLS and deliverability — interactions
The relationship between STARTTLS and deliverability is small but real.
Gmail flags messages received over unencrypted connections by displaying a red padlock icon in the recipient’s inbox. The visual signal indicates reduced security and can reduce engagement. Sustained patterns of unencrypted reception contribute to reduced sender reputation at Gmail.
Microsoft 365 increasingly prefers encrypted reception and applies similar visual indicators in Outlook.
For senders to corporate recipients protected by mail security gateways, unencrypted mail may be quarantined or rejected entirely. Many enterprise email security configurations require TLS for accepted inbound mail.
The aggregate effect is that STARTTLS support is now effectively required for normal deliverability. Senders whose outbound mail does not negotiate STARTTLS face deliverability penalties even when their authentication is otherwise correct.
Key takeaways
STARTTLS upgrades a plain SMTP connection to TLS encryption during the same session, making email transport encrypted between servers when both support it.
It is opportunistic encryption, meaning if TLS negotiation fails or is blocked, the connection can silently fall back to unencrypted delivery.
STARTTLS stripping attacks exploit this fallback behavior by forcing or tricking servers into staying on plaintext, typically requiring network-path access.
Silent TLS failures (like misconfigurations, certificate issues, or handshake incompatibility) can also lead to unencrypted email delivery without obvious errors.
MTA-STS enforces strict TLS rules to prevent downgrade attacks, while TLS Reporting provides visibility into encryption failures and delivery issues.
When STARTTLS successfully negotiates TLS, the resulting connection has the same cryptographic security as any TLS connection. The vulnerability is in the pre-encryption portion of the conversation, which can be manipulated by network attackers to prevent the upgrade from happening.
Both work for mail submission. Port 465 uses implicit TLS and is slightly simpler. Port 587 with STARTTLS is more widely supported. Most modern mail clients support both. For server-to-server transfer (the deliverability concern), port 25 with STARTTLS is the default and not configurable.
For mail sent through a major ESP or cloud provider, STARTTLS is the default and works correctly. Check the provider’s deliverability reports for TLS percentages. For mail sent from your own infrastructure, run a test through checktls.com or similar tools.
STARTTLS provides encryption when available. MTA-STS enforces that it be available. For most senders, STARTTLS alone is sufficient. For domains handling sensitive data or operating in regulated environments, MTA-STS adds meaningful protection against transport-layer attacks.
The red padlock indicates that one or more hops in the delivery chain were unencrypted. This can be the sending server, the receiving server, or any intermediate mail relay. Investigation requires checking each hop’s TLS configuration. The most common cause is an intermediate mail server (often a corporate gateway) that does not support or has misconfigured STARTTLS.
Conclusion
STARTTLS is a foundational layer for securing email in transit, but its opportunistic nature introduces inherent risks such as downgrade attacks and silent encryption failures. Without strict enforcement, email traffic can still fall back to plaintext, leaving sensitive data exposed and undermining trust in communication systems. This makes STARTTLS alone insufficient for modern security and deliverability requirements.
Strengthening your email security with MTA-STS ensures strict TLS enforcement, while TLS Reporting provides critical visibility into encryption failures that would otherwise go undetected. Together, they close the gaps left by opportunistic encryption and significantly improve both security posture and deliverability reliability.
Secure your email today
