Does your mail server actually enforce STARTTLS?

Opportunistic encryption, by design

RFC 3207 defines STARTTLS as an SMTP extension: a receiving mail server advertises support for it, and a sending server that also supports it can issue the STARTTLS command to upgrade the connection to TLS before any message data is transmitted. This solved a real deployment problem when it was introduced — mail servers across the internet could start encrypting connections to each other incrementally, without every server needing to support encryption on day one, because an unencrypted fallback kept mail flowing between servers that hadn’t upgraded yet.

That same incremental-adoption design is exactly what makes STARTTLS weaker than it looks today. Because the fallback to plaintext is the expected, standards-compliant behavior when TLS can’t be negotiated, a sending server has no built-in way to distinguish “the recipient genuinely doesn’t support TLS” from “an attacker on the network path just stripped out the STARTTLS offer to force plaintext.” Both look identical from the sending server’s point of view, and in both cases, the default behavior is to send the message anyway.

The STARTTLS stripping attack

This downgrade technique doesn’t require breaking TLS’s cryptography at all — it targets the negotiation that happens before encryption starts. An attacker with a position on the network path (a compromised router, a rogue access point, or access to transit infrastructure) can intercept the plaintext portion of the SMTP conversation and simply delete or corrupt the server’s STARTTLS announcement before it reaches the sending server. The sending server, seeing no STARTTLS support advertised, proceeds with a normal plaintext delivery — and because nothing about the resulting connection looks like an error, neither mail server necessarily logs anything unusual.

Mandatory TLS: the alternative that doesn’t fall back

The practical fix is a receiving domain publishing a policy that tells senders, in advance and out-of-band, “don’t fall back to plaintext for us, ever.” MTA-STS, defined in RFC 8461, does exactly that: a domain publishes a policy file over HTTPS (discovered via a DNS TXT record) declaring that mail to it must be delivered over TLS with a certificate the sender can validate. Because a sending server fetches this policy ahead of time rather than relying on what the live connection claims to support, an attacker stripping the STARTTLS offer in real time can no longer force a silent downgrade — the sending server already knows, independently, that plaintext delivery to this domain isn’t acceptable, and will refuse to deliver rather than fall back. DANE/TLSA solves a related problem a different way, using a DNSSEC-signed DNS record to pin exactly which certificate a mail server should present, instead of a web-hosted policy file.

How to tell which one you actually have

Most mail administrators assume STARTTLS is “handled” once it’s enabled, without checking whether it’s enforced or merely offered. The practical difference only shows up when something strips it — which is exactly the scenario a routine check won’t normally trigger on its own. The useful question to ask isn’t just “does my server support STARTTLS” (almost all modern mail servers do), but “does my domain also publish an MTA-STS policy that prevents a downgrade if STARTTLS is ever stripped in transit.”

1. Confirm your mail server’s certificate and TLS configuration with AdminKit’s SSL/TLS check tool — a valid, current certificate is a prerequisite for mandatory TLS to work at all, since a sending server enforcing MTA-STS will refuse to deliver to a certificate it can’t validate.
2. Check your domain’s DNS for an MTA-STS policy record using AdminKit’s DNS lookup tool, looking for the _mta-sts TXT record MTA-STS defines, alongside your existing MX records.
3. If no MTA-STS policy exists yet, that’s the gap to close — publishing one moves your domain from “we hope senders keep using the encrypted path” to “senders who support MTA-STS are required to.”

Why this still matters even with good authentication records

A domain can have SPF, DKIM, and DMARC fully configured and still have no protection against a STARTTLS downgrade, because authentication and transport encryption solve different problems — one verifies who sent a message and that it wasn’t altered after transit, the other protects the message while it’s in transit. Treat MTA-STS as the transport-layer complement to an already-solid authentication setup, not a replacement for it.