STARTTLS Explained: How Opportunistic Encryption Protects (and Doesn't Protect) Your Email

STARTTLS is one of those protocols that quietly does its job in the background of almost every email sent today, and precisely because it works silently, most people never learn how it actually behaves — including where it falls short. If you're responsible for a domain's mail flow, understanding STARTTLS matters because its biggest weakness isn't a bug, it's a design decision made decades ago that still shapes email security today.

What STARTTLS actually does

STARTTLS is a command that upgrades a plain-text SMTP connection to an encrypted one, mid-session. A sending server connects to a receiving server on port 25 in plain text, the receiving server advertises that it supports STARTTLS, and the sending server issues the command to switch the connection over to TLS before any message content is transmitted. Done correctly, everything after that handshake — the envelope, headers, and body — travels encrypted.

This is different from connecting over an already-encrypted port like 465, where TLS is established from the first byte. STARTTLS instead starts unencrypted and negotiates encryption partway through, which is why it's called "opportunistic" — the connection takes the encryption opportunity if it's offered, but there's no guarantee it will be.

The opportunistic problem

Here's the part that catches people off guard: if a receiving server doesn't advertise STARTTLS support, or if the connection is interfered with in a way that strips out the STARTTLS announcement, the sending server will typically fall back to sending the message in plain text rather than refusing to send it at all. This is called a downgrade attack, and it's been a known weakness in SMTP for years. An attacker sitting on the network path between two mail servers can simply delete the STARTTLS line from the server greeting, and most sending servers will proceed with an unencrypted transmission without raising any alarm.

This is precisely the gap that MTA-STS and DANE were built to close. Both let a domain publish a policy saying, in effect, "connections to my mail servers must use TLS — if TLS isn't available, do not deliver the message in plain text." If you haven't looked at either of those, they're a natural next step after understanding STARTTLS, and MTA-STS enforcement is the more widely supported of the two right now.

How to check if your domain is actually using STARTTLS correctly

A quick way to test is connecting to your mail server on port 25 with a tool like openssl s_client -starttls smtp -connect mail.yourdomain.com:25 and confirming the certificate presented is valid, matches your hostname, and hasn't expired. An expired or mismatched certificate doesn't necessarily stop mail flow — many servers will still accept the connection — but it does mean you're not getting the protection you think you are, and some receiving servers with stricter TLS requirements may reject or downgrade the connection.

It's also worth checking your outbound logs periodically for connections that fell back to plain text when they shouldn't have. If you're running your own SMTP infrastructure, this kind of visibility should be part of your regular monitoring, not something you only check after a problem is reported.

Things that commonly break STARTTLS

• Expired or self-signed TLS certificates that receiving servers won't trust
• Firewalls or older network appliances that strip the STARTTLS announcement
• Misconfigured servers that advertise STARTTLS but fail the handshake, causing timeouts
• Legacy mail relays still hardcoded to use port 25 without any TLS negotiation logic

STARTTLS versus end-to-end encryption

It's worth being clear about what STARTTLS doesn't do. It encrypts the connection between two mail servers, not the message itself. Once a message arrives at the receiving mail server, it's typically stored in plain text on disk, readable by anyone with server access. If you need the message content itself protected regardless of who's operating the mail server, that's a job for S/MIME or PGP, not STARTTLS. Most businesses don't need that level of protection for routine mail, but it matters for anyone handling sensitive records that need to stay unreadable even in storage.

Where this leaves you

STARTTLS should be considered a baseline, not a finish line. Every mail server you operate should support it and present a valid certificate — that part is table stakes in 2026. But if you're serious about making sure your domain's mail can't be silently downgraded to plain text, pair it with an MTA-STS policy and monitor TLS-RPT reports so you actually know when connections fail to negotiate encryption. Checking your current setup takes a few minutes; the alternative is not knowing whether your mail has been traveling in the clear for months. If you want a closer look at how your domain's authentication and encryption records stack up together, MailDog's DNS security tools are built to surface exactly these kinds of gaps.