STARTTLS vs SSL/TLS for Email: Implicit, Opportunistic, and Enforced

STARTTLS and implicit TLS ("SSL") are two ways to encrypt the same SMTP session. With implicit TLS, the TLS handshake happens the moment you connect (port 465) — nothing travels unencrypted. With STARTTLS, the client connects in plaintext (port 587 or 25), then issues the STARTTLS command to upgrade mid-conversation. For authenticated submission, RFC 8314 says both are fine and cleartext is not. For server-to-server relay on port 25, opportunistic STARTTLS is the default — and it's strip-able by attackers unless MTA-STS or DANE enforces it.

Let's demystify what "encryption in transit" actually means for email, because the details decide whether your mail is genuinely protected or just usually protected.

Two models, one goal

TLS (Transport Layer Security — the successor to SSL; people say "SSL" but mean TLS) encrypts a TCP connection so intermediaries can't read or modify the traffic. Email applies it two ways:

Implicit TLS

The TLS handshake is the first thing that happens. Before a single SMTP command is exchanged, the connection is encrypted. The server presents its certificate, the client validates it, and the entire SMTP conversation — EHLO, AUTH, message content — lives inside the encrypted tunnel. This is port 465 for SMTP submission, and port 993 for IMAP if you're thinking about retrieval.

C: <TCP connect to smtp.example.com:465>
    <TLS handshake: certificate presented, validated, cipher negotiated>
S: 220 smtp.example.com ESMTP ready
C: EHLO app.yourcompany.com
S: 250-AUTH PLAIN LOGIN
C: AUTH PLAIN <credentials — already inside TLS>

Nothing plaintext. Ever. There is no window where an observer can see anything but the TLS handshake itself.

STARTTLS (explicit upgrade)

The connection starts as ordinary plaintext SMTP. After the greeting, the client issues STARTTLS, the server agrees, and the TLS handshake happens inside the existing connection. The conversation then restarts (a fresh EHLO) inside the encrypted tunnel. This is the model on port 587 (submission) and port 25 (relay):

S: 220 smtp.example.com ESMTP ready
C: EHLO app.yourcompany.com
S: 250-smtp.example.com
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
    <TLS handshake happens here>
C: EHLO app.yourcompany.com          <- EHLO restarts after upgrade
S: 250-AUTH PLAIN LOGIN
C: AUTH PLAIN <credentials — inside TLS now>

Notice what traveled in plaintext before the upgrade: the greeting and the first EHLO exchange — including the server's capability list. That small plaintext window is the entire attack surface, and it matters enormously in one context and barely at all in another. Which brings us to the distinction that actually drives security posture.

Opportunistic vs enforced: the distinction that matters

Encryption mechanism (implicit vs upgrade) is less important than encryption policy (opportunistic vs enforced). Four combinations exist:

Opportunistic means "encrypt if we can." It protects against passive surveillance — someone quietly reading traffic off a backbone — which covers most real-world exposure most of the time. It does not protect against an active attacker who manipulates the connection, because the attacker can simply make TLS appear unavailable.

Enforced means "encrypt or fail." No fallback. If TLS can't be established and validated, the message doesn't go. This is the only mode that defeats active interference.

Why port-25 opportunistic TLS is strip-able

The STARTTLS stripping attack targets the plaintext capability exchange in the upgrade model. An attacker positioned between two MTAs (a compromised router, a malicious network hop, a BGP hijack) intercepts the connection and rewrites the server's EHLO response to remove the 250-STARTTLS line. The sending MTA, doing opportunistic TLS, shrugs: "no TLS support here — deliver in cleartext." The attacker reads everything.

Alternatively, the attacker lets STARTTLS proceed but terminates TLS themselves with a self-signed or mismatched certificate. Because relay MTAs historically did not validate certificates (hosted email means MX hostnames rarely match certificate names), most senders shrugged again and delivered anyway.

Two fixes exist, and both work by giving the sending side a pre-committed expectation:

• MTA-STS — the receiving domain publishes a policy over authenticated HTTPS: "my MX hosts are X, TLS is mandatory, certificates must validate." Senders cache it and refuse downgrade. Full walkthrough in MTA-STS and TLS-RPT explained.
• DANE — the receiving domain pins its MX certificates in DNSSEC-signed TLSA records; senders validate the TLS handshake against the pinned fingerprint.

For the submission path, stripping is a non-issue if you configure enforcement: a client that requires STARTTLS (or uses implicit TLS) simply refuses to send when the upgrade fails. The vulnerability lives in the relay path's "deliver anyway" fallback.

RFC 8314: cleartext is deprecated

RFC 8314 (2018) settled the submission debate formally:

• Cleartext submission is deprecated. Mail User Agents should not send mail over unencrypted connections, period.
• Implicit TLS on 465 is the preferred submission mechanism — re-legitimizing a port that had spent years in standards limbo — precisely because implicit TLS removes the plaintext phase and the misconfiguration risk that comes with it.
• STARTTLS on 587 remains fully valid, provided TLS is required (not attempted) before authentication.

The practical reading: for any authenticated client connection — your app to your ESP, Outlook to Microsoft 365, a phone to Gmail — use 465 with implicit TLS or 587 with mandatory STARTTLS. If a config option says "allow plaintext" or "TLS: optional," it's wrong. The port-by-scenario breakdown is in SMTP ports 25 vs 465 vs 587.

Certificate validation: the awkward reality between MTAs

Here's the part that surprises people. On the submission path, certificate validation works exactly like HTTPS: your client validates the server's certificate against the hostname, checks the chain to a trusted CA, and hard-fails on mismatch. Clean.

On the relay path, it historically didn't work at all. A sending MTA delivering to example.com looks up MX records and gets example-com.mail.protection.outlook.com — Microsoft's host, presenting Microsoft's certificate. Validating that cert against the recipient's domain name fails by design. Multiply by every hosted provider, and strict cert validation on relay would have broken a large share of internet email. So the ecosystem settled on: encrypt opportunistically, ignore certificate identity, deliver regardless.

MTA-STS fixed the incentive problem: the receiving domain declares its MX hostnames, so the sender can validate the certificate against the MX hostname (which the domain vouched for) rather than against the recipient domain. That's the subtle trick — validation becomes possible because the policy tells you what names are legitimate.

For your own infrastructure, the operational consequences:

• Self-hosted MX: use publicly trusted certificates (Let's Encrypt is fine) matching the MX hostname, automate renewal, and never self-sign.
• Hosted email (Google/Microsoft): your provider handles MX certificates. Your job is publishing correct MTA-STS mx: patterns that match their hostnames.
• Submission clients: pin nothing, validate normally, require TLS. Library defaults are usually correct — the danger is configs that disable verification to "fix" a cert error.

How to check what your server actually negotiates

Don't assume. Test both directions.

Check a submission endpoint (587)

openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com

You're looking for Verify return code: 0 (ok), the negotiated protocol (TLSv1.2 or TLSv1.3 — anything older is a finding), and a certificate chain that validates. If the STARTTLS upgrade fails, s_client exits before any handshake output — that's your answer.

Check implicit TLS (465)

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com

The handshake happens immediately; same verification output. No -starttls flag here.

Check an MX host as a sender would (25)

openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com

This simulates what a delivering MTA sees: does the MX offer STARTTLS at all, what certificate does it present, and does it validate publicly? To see whether the MX even advertises TLS without openssl, a plain telnet EHLO works — 250-STARTTLS in the response means opportunistic TLS is offered:

telnet mx1.example.com 25
EHLO test.example.org

Watch real traffic outcomes: TLS reporting

Configuration tests tell you what should happen. TLS-RPT tells you what did happen — daily aggregate JSON reports from sending MTAs listing TLS failures delivering to your domain: expired certificates, hostname mismatches, policy fetch errors. Publish the _smtp._tls record and read what comes back; the record format and sample report are in the MTA-STS and TLS-RPT guide. Validate your setup with WillItInbox's free MTA-STS checker, which inspects the DNS records, the policy file, and certificate health in one pass.

You can also see encryption per-message after the fact: the Received headers of a delivered email record each hop's protocol, and modern receivers annotate TLS use (with ESMTPS, TLS version, cipher). The email header analysis guide shows how to read that chain.

One caution: TLS policy drifts. Certificates expire, MTA-STS policy files get clobbered in migrations, and TLS-RPT failures start accumulating quietly. WillItInbox's DMARC and domain monitoring watches that drift alongside your authentication records, so a broken TLS-RPT or MTA-STS config surfaces as an alert rather than a week of failed deliveries.

What about end-to-end encryption?

Everything above is hop-by-hop transport encryption: each server-to-server leg is encrypted, but every MTA along the path — your ESP, the recipient's provider — sees the message in cleartext and typically stores it that way. TLS in transit does not hide content from mailbox providers, and it doesn't protect against account compromise at either end.

True end-to-end encryption (S/MIME, OpenPGP) encrypts content so only sender and recipient can read it. It solves a different problem, breaks server-side filtering and search, and sees near-zero use in marketing and transactional email. For the overwhelming majority of senders, enforced TLS in transit plus provider-side at-rest encryption is the realistic target. Know the difference so you don't oversell "encrypted email" in a security review.

Verify your own sending path

If you send email for a product or a brand, the questions that matter are: does your submission path enforce TLS, do your MX hosts present valid certificates, and does your domain publish the records that let senders enforce delivery encryption to you? Then: does the mail itself authenticate and land where it should?

Send a real test through your production path to WillItInbox's deliverability tester — the report covers TLS negotiation alongside SPF, DKIM, DMARC, and 70+ other checks, so a weak link anywhere in the chain surfaces in one score. And if your sending stack is still SMTP where an API would be stronger, the trade-offs are mapped in SMTP vs API email sending — API submission is HTTPS, which is implicit TLS by construction.