Stop STRIPTLS Downgrades: TLS vs STARTTLS Policies for Mail Admins

STARTTLS is a command, not encryption. TLS is the security protocol used after a successful upgrade. SMTP and IMAP use STARTTLS; POP3 calls its upgrade command STLS. For mail submission, prefer TLS 1.3 using implicit TLS on port 465 when your provider and clients support it. Strict STARTTLS on port 587 is also secure when TLS and peer verification are required before submission. For server-to-server relay, evaluate MTA-STS or DANE separately.

Table of Contents

• TLS explained: what it is, handshake basics and security guarantees
• STARTTLS explained: the upgrade command and where it is used
• Implicit TLS vs explicit TLS, and the ports you should know
• Security comparison and mitigations: downgrade attacks, STRIPTLS and DANE
• Practical configuration checklist and testing commands for admins
• Operational implications for agent-mailbox and API-first mail architectures
• Historical context and evolution of TLS and STARTTLS
• Common use cases and deployment scenarios for TLS and STARTTLS in email and other protocols
• Comparison of performance impacts between TLS and STARTTLS
• Limitations and compatibility issues with older clients or servers
• Getting TLS policy right without breaking delivery
• A managed alternative: secure defaults without the TLS admin overhead
• Sources
• FAQ

TLS explained: what it is, handshake basics and security guarantees

TLS protects a connection against passive reading and undetected modification when configured correctly. Authentication also requires checking the peer through the chosen trust model. These protections apply to that transport hop; SMTP TLS is not end-to-end message encryption.

The handshake establishes traffic keys and authenticates the peer according to the selected mode. A full TLS 1.2 handshake uses two round trips; a normal TLS 1.3 handshake uses one, with exceptions such as HelloRetryRequest and different resumption flows. RFC 8446 specifies TLS 1.3. Certificate-based TLS 1.3 uses ephemeral key agreement, so a later signing-key compromise does not reveal earlier session keys that have been erased. PSK-only key establishment lacks that forward-secrecy property. SMTP upgrades are specified separately in RFC 3207.

For ordinary certificate-based public-PKI connections, check these three areas. DANE uses its own DNSSEC-authenticated certificate association rules:

• The certificate identity matches the server hostname the client intended to reach.
• The certificate chain reaches a trust anchor accepted by the client.
• Certificate validity dates and applicable revocation checks satisfy the client policy; do not assume every client checks revocation automatically.

Pro Tip: An expired certificate can be accepted by a permissive client. In Postfix, may permits opportunistic delivery, while encrypt requires encryption but still accepts an untrusted or wrong-name server certificate. Use an authenticated policy when server identity matters; never silently weaken a strict submission policy after failure.

SSL, the predecessor to TLS, is deprecated. A mail client may still label a TLS setting “SSL”, so inspect the negotiated version instead of trusting the label. Do not enable actual SSL in 2026.

STARTTLS explained: the upgrade command and where it is used

RFC 3207 defines STARTTLS as an SMTP extension that upgrades an established connection to TLS. The client requests the upgrade, the server responds, and the TLS handshake follows. Traffic exchanged before that handshake is not retroactively encrypted.

A typical SMTP exchange runs like this:

• The client connects, receives the SMTP greeting and sends EHLO.
• Server advertises its capabilities, including STARTTLS if it supports it.
• Client sends the STARTTLS command.
• Both sides perform a standard TLS handshake on that same connection.
• After a successful handshake, discard pre-TLS capability knowledge and send EHLO again before continuing SMTP.

IMAP has a STARTTLS command, while POP3 uses STLS; RFC 2595 specifies both upgrade mechanisms. A mail-client menu label is not enough to identify its behaviour: confirm the port, TLS mode and certificate-validation settings.

Implicit TLS vs explicit TLS, and the ports you should know

With implicit TLS, the TLS handshake begins as soon as the TCP connection is established, before any SMTP greeting or application commands. This does not mean every handshake byte is encrypted: the initial ClientHello is visible. SMTP submission then travels as TLS application data.

With explicit TLS, the application connection begins in plaintext and upgrades through its protocol-specific command. For SMTP, distinguish these ports:

• Port 587 — the standard submission port for mail clients sending outbound mail, using STARTTLS.
• 25: SMTP relay between mail servers, with STARTTLS when supported and required by the applicable policy.
• Port 465 — implicit TLS for submission, no upgrade step, no plaintext phase.

For new submission deployments, RFC 8314 prefers implicit TLS on 465 and also supports strict STARTTLS on 587. Follow the provider-supported mode and require authenticated TLS before sending credentials or messages. Port 25 serves relay, where RFC 8314 does not apply; RFC 3207 alone does not require every public MX to support or demand TLS.

Security comparison and mitigations: downgrade attacks, STRIPTLS and DANE

An on-path attacker can remove the plaintext STARTTLS capability advertisement. An opportunistic client may then send without TLS. This downgrade is commonly called STRIPTLS; RFC 3207 describes the capability-stripping threat and the need for locally required TLS policies.

Implicit TLS removes that SMTP upgrade phase. Strict STARTTLS can also prevent submission after a stripped advertisement by refusing to continue without verified TLS. RFC 8314 prefers implicit TLS for submission and access, while explicitly recognising the security parity of correctly enforced 587 and 465 configurations.

Evaluate these three complementary controls:

1. Require TLS where policy demands it. Postfix smtp_tls_security_level = encrypt prevents plaintext delivery but does not verify server identity; may is opportunistic. Choose an authenticated policy for a known relay and use destination-aware policies for Internet delivery.
2. MTA-STS discovers policy through a DNS TXT record and fetches it over authenticated HTTPS. Supporting senders enforce a valid cached enforce policy for its lifetime. Discovery can be suppressed before first policy retrieval, so MTA-STS does not eliminate the first-contact downgrade window.
3. DANE with DNSSEC authenticates SMTP service policy and certificate associations through TLSA records. This is more than ordinary certificate pinning: a validated DNSSEC chain establishes the trust used to authenticate the receiving service and resist downgrade.

Pro Tip: Roll enforcement out in stages. A peer that cannot meet a newly required TLS policy will fail delivery through that route; identify and repair those cases before rollout.

A strict policy can defer mail to an incompatible or misconfigured peer. Opportunistic delivery trades some protection for reachability. Inventory your destinations, repair known failures, and choose where authenticated TLS is required; do not treat a TLS error as permission to bypass that policy.

Practical configuration checklist and testing commands for admins

Use this configuration checklist, adapting relay policy to the destinations you actually control:

• Set the minimum TLS version to 1.2, and prefer 1.3 wherever your mail transfer agent and mail clients support it.
• Review Postfix’s smtp_tls_security_level: encrypt requires encryption but not certificate authentication, and may permits opportunistic delivery. For a known relay, select the appropriate authenticated policy; do not make blanket Internet delivery depend on every MX supporting TLS.
• Require peer verification on submission clients. A private CA or DANE association needs an explicit trust configuration; accepting every self-signed or expired certificate is not verification.
• Prefer implicit TLS (port 465) for submission endpoints where your provider and clients both support it, per RFC 8314’s guidance.

Use OpenSSL’s s_client to inspect a test endpoint. The examples below require certificate verification and hostname matching. Replace the example hostname with an endpoint you are authorised to test; these commands do not authenticate or submit a message:

openssl s_client -connect mail.example.com:465 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error

Inspect the negotiated protocol, cipher and verification result. Use the intended client trust store; different roots, missing intermediates and hostname mismatches can explain different results between your desktop and mail server. A successful handshake alone does not prove hostname verification, revocation checking or end-to-end delivery security.

TLS reporting is a separate protocol: RFC 8460 defines TLS-RPT and its _smtp._tls DNS record. MTA-STS uses testing, enforce and none policy modes; testing does not require delivery failure for a policy mismatch. Configure TLS-RPT to receive reports from participating senders, inspect local negotiation failures, and evaluate the results before changing to enforce. Reports are not a complete view of every sender.

Operational implications for agent-mailbox and API-first mail architectures

Programmatic mail needs the same explicit transport choices as a desktop client. Email white labeling concerns sending identity and branding; it does not determine the transport. An HTTPS sending API uses TLS for HTTP, not SMTP implicit TLS on 465. An automated SMTP client can use implicit TLS or strict STARTTLS according to the provider contract, and must reject failed peer verification rather than wait for a human to dismiss a warning.

Server-to-server MX delivery remains a separate hop after API or SMTP submission. MTA-STS and DANE protect supported relay destinations under their respective policies. If you operate multiple tenants, inventory which certificates and endpoints they share; one expired shared certificate can affect several tenants, but tenancy alone does not imply a separate certificate per mailbox. Sendmux’s routing across connected sending providers is a public sending capability; it does not remove the client’s obligation to verify the configured TLS endpoint.

Historical context and evolution of TLS and STARTTLS

SMTP was specified in 1982. TLS upgrades for email were standardised in the late 1990s: SMTP STARTTLS appeared in RFC 2487, and RFC 2595 specified TLS upgrades for IMAP and POP3 in 1999. Reusing an existing port allowed upgraded and legacy clients to reach the same service. An unsupported command is rejected rather than silently understood; whether a client continues without TLS depends on its configured security policy.

In 2018, roughly two decades after those email upgrade specifications, RFC 8314 recommended implicit TLS for submission and access. Its scope excludes server-to-server SMTP relay. The downgrade threat therefore calls for different policies at the submission and relay boundaries.

SSL 2.0 and 3.0 are deprecated, as are TLS 1.0 and 1.1. TLS 1.2 was specified in 2008 and TLS 1.3 in RFC 8446 in 2018. TLS 1.3 removes legacy key-exchange and cipher options and changes the handshake, but does not make configuration and authentication checks unnecessary. RFC 9325 requires support for TLS 1.2 and recommends TLS 1.3 support with preference for it when implemented; a secure TLS 1.2 deployment is not automatically obsolete.

Common use cases and deployment scenarios for TLS and STARTTLS in email and other protocols

For SMTP submission, RFC 8314 prefers implicit TLS on port 465 while supporting strict STARTTLS on 587. Server-to-server MX delivery uses SMTP on port 25 and can negotiate STARTTLS. A sending HTTP API is another interface, with its own HTTPS connection; its use does not specify the security of every later mail hop.

IMAP and POP3 retrieve messages rather than submit outbound mail. IMAP can use implicit TLS on 993 or STARTTLS on 143; POP3 can use implicit TLS on 995 or STLS on 110. RFC 8314 prefers implicit TLS for mail access.

Other protocols have their own upgrade mechanisms. FTP can negotiate TLS with AUTH TLS under RFC 4217; this is FTPS, not SFTP. XMPP specifies STARTTLS negotiation in RFC 6120. LDAP defines a StartTLS extended operation in RFC 4511; an implicit LDAPS service is a separate connection mode. Do not copy SMTP commands into these protocols.

A dedicated TLS service avoids an application-level upgrade exchange. An upgrade mechanism can share an existing port with legacy clients, but its security depends on requiring a successful authenticated upgrade. Choose the supported mode and enforce the same trust policy rather than treating a port number as a security guarantee.

Comparison of performance impacts between TLS and STARTTLS

Once established with the same TLS version and parameters, either SMTP mode protects application data with TLS. Setup differs: STARTTLS needs the SMTP greeting, capability exchange and upgrade response before the handshake, followed by a fresh EHLO. Implicit TLS begins the handshake before SMTP. The added latency is not a universal one-round-trip constant across implementations.

Measure setup latency on your actual network. A few milliseconds is an illustrative local-network scale, not a promised overhead. At millions of submission connections a day, repeated setup work can matter, but connection reuse, network round-trip time and server behaviour determine the result. Prefer the supported secure mode and use measurements before changing an architecture.

For a full handshake, TLS 1.2 normally takes two round trips and TLS 1.3 one, excluding TCP setup. HelloRetryRequest and resumption change the exchange. Both versions support session resumption; TLS 1.3 early data has replay limitations and should not be assumed safe for SMTP actions. Measure TLS version, connection reuse and STARTTLS setup together instead of assuming one change always dominates latency.

Limitations and compatibility issues with older clients or servers

A legacy device that supports only TLS 1.0 or 1.1 cannot connect to a service requiring at least TLS 1.2. Requiring TLS 1.3 also excludes TLS 1.2-only peers. Current guidance deprecates the older versions but does not universally require a TLS 1.3-only deployment; identify affected clients before tightening your minimum.

Check STARTTLS state handling as well as version support. SMTP peers must discard pre-TLS knowledge after negotiation, and the client should send EHLO again. A client that retains stale capabilities or continues despite failure of required TLS is misconfigured or noncompliant with its intended policy. Test those failure paths rather than assuming age alone predicts behaviour.

An outdated trust store, missing intermediate certificate or hostname mismatch can cause validation failure. If verification is disabled, a connection may still resist passive eavesdropping while remaining vulnerable to an active impersonator. An encrypted log entry alone does not prove authenticated transport.

Inventory negotiated versions and failed upgrades, then give affected peers a defined migration window. Do not re-enable deprecated SSL or TLS versions as an automatic fallback. A proposed “require TLS 1.3 in 2026” policy needs compatibility testing; TLS 1.2-only integrations would otherwise be excluded.

Getting TLS policy right without breaking delivery

Before enforcing a stricter policy, identify which peers would fail it. Prefer implicit TLS for supported submission endpoints under your control, and require peer verification with either mode. For MTA-STS, start with testing, configure TLS-RPT separately, repair reported failures, and then move to enforce when ready. Document scoped exceptions and a delivery-continuity plan for critical recipients; never silently bypass an enforced policy by retrying in plaintext.

A managed alternative: secure defaults without the TLS admin overhead

Certificate renewal, relay policy and negotiation monitoring remain operational responsibilities for the services you run. Sendmux offers managed mailboxes on @myagent.mx or supported custom domains, SMTP submission on 587 or 2525 with STARTTLS, and a separate HTTPS sending API. Receiving mail and retrieving it are distinct from submission. Configured inbound webhooks use HMAC signatures; verify those signatures as well as HTTPS peer identity, because application authenticity and transport security are different checks.

For an agent that needs a mailbox, Myagent directs agents to Sendmux registration without a credit card or prior human signup. Wait for provisioning before using the inbox. Registration grants read and receive access; sending remains locked until the invited human owner accepts and explicitly approves it.

Sources

• RFC 3207: SMTP Service Extension for Secure SMTP over TLS
• OpenSSL: openssl-s_client manual

FAQ

Is port 587 STARTTLS or TLS?

Port 587 is the message-submission port and commonly uses STARTTLS: SMTP begins in plaintext, then upgrades to TLS. Require successful TLS and peer verification before authentication or submission. On port 465, the TLS handshake begins before SMTP.

Is STARTTLS deprecated?

STARTTLS is not deprecated as a mechanism. RFC 8314 prefers implicit TLS for mail submission and access, and also supports strict STARTTLS on 587. SMTP relay on port 25 can use STARTTLS under a separate relay policy.

Is TLS replacing SSL?

TLS superseded SSL. SSL 2.0 and 3.0 are deprecated; a setting labelled “SSL” may actually negotiate TLS. Check the negotiated version rather than assuming what the label means.

Should I use TLS or SSL for SMTP?

Use TLS, not actual SSL. Set at least TLS 1.2 and prefer TLS 1.3 where supported, with appropriate cipher and peer-validation settings. In 2026, a legacy “SSL” menu label is a reason to verify the negotiated protocol, not to enable obsolete SSL.

How does STARTTLS actually differ from TLS in day-to-day operation?

STARTTLS requests a TLS handshake on an existing application connection; TLS protects the subsequent traffic after successful negotiation. Implicit TLS, such as SMTP submission on port 465, starts the handshake without that upgrade command. A STARTTLS request can fail, so require success rather than assuming that sending the command enabled encryption.