STARTTLS is the SMTP extension that upgrades a plaintext connection to TLS mid-conversation. It is the foundation of modern email transport encryption — and its opportunistic nature is the historical weakness that MTA-STS and DANE exist to fix. This article explains how STARTTLS works, what its limitations are, how to verify and harden its behaviour on your mail infrastructure, and how it fits with the rest of the transport security stack for UK businesses.
STARTTLS (RFC 3207 for SMTP) is a protocol command that lets two SMTP servers upgrade their plaintext conversation to a TLS-encrypted one. The client connects on port 25 (or port 587 for submission), the server advertises STARTTLS capability, the client issues the STARTTLS command, and from that point onward the conversation is encrypted.
The same basic pattern — opportunistic upgrade of a plaintext protocol to TLS — exists for other services: IMAP's STARTTLS, POP3's STLS, XMPP's STARTTLS. The email world inherited and formalised the pattern; most UK business mail today is encrypted in transit thanks to STARTTLS.
A typical STARTTLS SMTP handshake:
220 mail.example.com ESMTP Postfix
EHLO sender.firm.co.uk
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
STARTTLS
220 2.0.0 Ready to start TLS
[TLS handshake begins]
[EHLO resent inside TLS]
EHLO sender.firm.co.uk
250-mail.example.com
250-PIPELINING
250-SIZE 52428800
250-ENHANCEDSTATUSCODES
...
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
...Key steps:
STARTTLS if it supports encryption.The handshake takes two or three round-trips plus the TLS negotiation. Total overhead: typically under 100 ms on a fast network.
The fundamental design choice in STARTTLS is that it is opportunistic. If anything goes wrong — the TLS handshake fails, the certificate is invalid, or STARTTLS is not advertised in EHLO — the sending server falls back to plaintext. The message is delivered anyway, unencrypted, with no alert to either end.
This design was pragmatic in 2002 (RFC 3207): mandating TLS would have broken compatibility with servers that did not yet support it. In 2026 it is the persistent weakness. A determined network attacker with the ability to intercept and modify traffic between two mail servers can:
250-STARTTLS line from the receiver's capability list. The sender never knows TLS was available and delivers plaintext.MTA-STS and DANE are the modern solutions to this — they declare that TLS is mandatory and give senders a way to verify the receiving certificate. STARTTLS alone is fragile.
The three attacks above are collectively called TLS downgrade attacks. They have been observed in the wild at state-actor scale — multiple published studies show TLS being stripped on international mail traffic in specific network paths. The practical implication for UK businesses:
The mitigation is not to abandon STARTTLS but to harden it: MTA-STS tells senders that TLS is mandatory; DANE tells senders exactly which certificate to expect; DNSSEC prevents attackers from spoofing the DNS records that carry these policies.
Two fundamentally different approaches to SMTP encryption exist:
| Approach | Port | How it starts |
|---|---|---|
| Plaintext SMTP | 25 | No encryption by default |
| SMTP with STARTTLS | 25 or 587 | Begins plaintext, upgrades to TLS via STARTTLS |
| Implicit TLS (SMTPS) | 465 | TLS negotiated immediately on connection |
Port 587 (submission) and port 25 (MX-to-MX) both use STARTTLS. Port 465 (historically deprecated, now restored by RFC 8314) uses implicit TLS — no plaintext phase at all. For user submission from mail clients, port 465 with implicit TLS is now preferred where supported because it leaves no plaintext window for downgrade. For server-to-server mail, port 25 with STARTTLS remains universal — implicit TLS on port 25 was never standardised.
In practice, UK business mail uses:
The current TLS versions in the wild:
| Version | Status | Recommendation |
|---|---|---|
| TLS 1.3 | Current (RFC 8446) | Preferred — use where both ends support |
| TLS 1.2 | Widely supported (RFC 5246) | Acceptable fallback |
| TLS 1.1 | Deprecated (RFC 8996) | Disable |
| TLS 1.0 | Deprecated (RFC 8996) | Disable |
| SSL 3.0 and earlier | Broken | Disable; never enable |
UK NCSC guidance and PCI DSS 4.0 both require TLS 1.2 minimum for any handling of regulated data. Most modern UK mail servers — Postfix 3.x, Exim 4.9x, Axigen, Exchange 2019 — support TLS 1.3 and disable older versions by default.
For cipher suites, prefer forward-secret (Perfect Forward Secrecy) suites using ECDHE or DHE key exchange, AES-GCM or ChaCha20-Poly1305 for encryption, and SHA-256 or better for MAC. Avoid RC4, 3DES and anything with MD5 or SHA-1.
The TLS certificate presented by a mail server should match the hostname that sending servers expect — typically the MX target. For firm.co.uk with MX 10 mail.firm.co.uk, the certificate should cover mail.firm.co.uk.
Certificate sources:
Opportunistic TLS typically does not validate the certificate (name matching, CA trust) strictly. MTA-STS and DANE add strict validation — which is where the certificate provenance actually matters.
STARTTLS alone is the baseline. The hardening layers built on it:
A modern UK email deployment publishes all four. Each layer protects against a specific failure mode that the layer below does not address.
Check the receiver's EHLO response. If 250-STARTTLS is missing, the receiver is either misconfigured or genuinely plaintext-only. Most modern servers support it; the configuration usually needs the smtpd_tls_security_level (Postfix) or equivalent to be set to may or encrypt.
Usually a certificate issue: expired, wrong hostname, missing intermediates. Run openssl s_client -connect mail.firm.co.uk:25 -starttls smtp to see the exact error.
This is the opportunistic behaviour. Publish MTA-STS or DANE to forbid it on inbound mail to your own domain; for outbound mail where the remote domain does not publish MTA-STS/DANE, this fallback cannot be prevented cleanly.
Two servers that support only disjoint sets of TLS versions cannot negotiate. A legacy server with only TLS 1.0/1.1 cannot talk to a modern server with only TLS 1.2+. Upgrade the legacy side.
The MX target is mail.firm.co.uk but the certificate covers only firm.co.uk. Opportunistic TLS may ignore this; MTA-STS and DANE both enforce hostname matching. Request a certificate that covers the MX hostname.
Q: Does STARTTLS encrypt the message itself?
A: It encrypts the entire SMTP conversation, including the message content as it flows between two servers. It does not encrypt the message body end-to-end — once the message is delivered to the recipient's mailbox, it may be stored decrypted. For end-to-end encryption use S/MIME or PGP on top of STARTTLS.
Q: Why is STARTTLS not mandatory in SMTP?
A: Historical compatibility. When STARTTLS was introduced in 2002, mandating it would have broken every server that did not yet support it. The opportunistic model ensured backward compatibility at the cost of weakness against active attackers.
Q: Does publishing MTA-STS make STARTTLS mandatory for my inbound mail?
A: Yes — senders that respect MTA-STS will refuse to deliver to your mail server if STARTTLS fails or the certificate does not validate. Senders that ignore MTA-STS (older servers, some niche providers) still fall back to plaintext.
Q: Can STARTTLS protect against a compromised mail server?
A: No. STARTTLS protects the conversation between servers. Once the message arrives at a server, it is decrypted and accessible to anyone with access to that server. End-to-end encryption is the only defence against a compromised intermediate host.
Q: Is implicit TLS (port 465) more secure than STARTTLS?
A: Marginally, in the narrow sense that it has no plaintext phase during connection setup. But the main transport security improvement comes from MTA-STS and DANE, not from the choice between STARTTLS and implicit TLS. Use STARTTLS on port 25 for MX-to-MX mail; use either 465 or 587 for user submission, with modern client preferences now favouring 465.
Q: What TLS version does my mail server support?
A: Run openssl s_client -connect mail.firm.co.uk:25 -starttls smtp -tls1_3 to test TLS 1.3, or replace with -tls1_2 for TLS 1.2. The server responds showing whether the version was negotiated.
Q: Do I need a paid certificate for SMTP or will Let's Encrypt do?
A: Let's Encrypt is fine for most UK deployments. Paid certificates are required only for specific regulatory contexts (some financial sector requirements) or where EV/OV validation is desired for other reasons. Let's Encrypt 90-day certificates work perfectly for MX TLS.
Q: Is there a performance cost to STARTTLS?
A: Minimal. The TLS handshake adds a few milliseconds; TLS 1.3 can often complete with zero extra round-trips for resumed sessions. For the volumes most UK businesses send, the cost is unmeasurable.
Q: Can I see in my mail logs whether STARTTLS was used?
A: Yes. Postfix, Exim, Axigen and similar log the TLS version and cipher for each connection. Grep the logs for TLS to see every STARTTLS session.
Q: Does the recipient see that my mail was encrypted in transit?
A: Not directly. Gmail and a few others show a padlock icon if the whole delivery chain used TLS. Most mail clients do not indicate this. The encryption is a transport-layer property, not visible at the application layer.
Q: What happens if my mail server's certificate expires during active STARTTLS sessions?
A: New connections fail if the receiver strictly validates certificates (under MTA-STS or DANE). Opportunistic receivers may accept an expired certificate. Regardless, renew before expiry — Let's Encrypt automation is the standard solution.
Q: Can I force opportunistic TLS to actually validate certificates?
A: Configuration-dependent. Postfix, for example, offers smtp_tls_security_level = verify for outbound or dane for DNSSEC-based validation. These make your outbound mail stricter about the receiver's certificate — at the cost of delivery failures against receivers with misconfigured certs.
Q: Does STARTTLS work through NAT and load balancers?
A: Yes. TLS operates above TCP; any connection that delivers TCP correctly can carry STARTTLS. Load balancers that terminate TLS (unusual for SMTP) do change the certificate presented, which matters for DANE validation.
Q: How do I verify my outbound mail uses STARTTLS consistently?
A: Check mail server logs for outbound connections; they log TLS version and cipher per delivery. Additionally, TLS-RPT reports from receivers who do not see you using TLS flag the problem. Most UK mail servers use STARTTLS successfully on 95%+ of outbound attempts.
Q: Is STARTTLS still relevant given QUIC and HTTP/3?
A: Yes — SMTP transport protocols evolve slowly. There is no "SMTP over QUIC" standard; SMTP with STARTTLS over TCP remains the universal email transport. The modernisation work is happening at the policy layer (MTA-STS, DANE) not at the protocol layer.
Q: What percentage of UK mail traffic is encrypted with STARTTLS?
A: Over 95% of inter-server mail traffic to and from major UK receivers uses STARTTLS successfully. The remaining few percent is either legacy hosts that never supported it or connections where the negotiation fails for other reasons.
Q: Can STARTTLS interact badly with mail filtering appliances?
A: Some inbound filtering products terminate TLS at the filter, re-encrypt outbound to the internal server. This gives the filter visibility over content — important for its function. Ensure any such appliance supports TLS 1.2+ throughout and presents valid certificates on both interfaces.
Q: Does STARTTLS change how SPF, DKIM and DMARC work?
A: No. SPF, DKIM and DMARC operate on the message content and metadata, independent of whether the transport was encrypted. A plaintext-delivered message with valid SPF/DKIM still authenticates correctly; an encrypted-delivered message with invalid SPF/DKIM still fails.
Q: How do MTA-STS and DANE complement each other on top of STARTTLS?
A: STARTTLS gives you encryption. MTA-STS declares encryption mandatory and checks the certificate against a policy served over HTTPS. DANE declares encryption mandatory and checks the certificate against a DNSSEC-signed fingerprint. MTA-STS works without DNSSEC; DANE requires it. Deploy both for redundancy.
Q: Is there a way for a sender to refuse unencrypted mail delivery?
A: Yes — configure outbound TLS policy to encrypt or verify (Postfix) or equivalent. Mail to receivers that cannot negotiate TLS is queued or deferred rather than delivered plaintext. Used by organisations where confidentiality is paramount, at the cost of occasional delivery failures.
Q: What is the difference between opportunistic STARTTLS and "best-effort" TLS?
A: They are essentially the same thing — both mean "try TLS, fall back to plaintext if it fails". The terminology varies by vendor. The important distinction is opportunistic (with fallback) vs enforced (no fallback, enforced by MTA-STS or DANE).
Q: Can I combine STARTTLS with S/MIME or PGP?
A: Yes, and in fact this is the layered security model for high-assurance mail. STARTTLS protects transport; S/MIME or PGP protects content end-to-end. A message encrypted with S/MIME and delivered over STARTTLS has two independent layers of cryptographic protection.
Q: Does mail through a content-security gateway (Mimecast, Proofpoint) use STARTTLS on both hops?
A: Normally yes. Gateway-to-MX and internal-to-gateway hops both support STARTTLS. Check with the gateway operator if unsure — enterprise gateways have well-documented TLS behaviour.
Q: How do STARTTLS and TLS-RPT work together?
A: STARTTLS encrypts. TLS-RPT reports whether STARTTLS negotiation succeeded or failed when mail was delivered to your domain. Together they give you both the encryption itself and visibility into its operational health.