What is the difference between STARTTLS and implicit TLS?

STARTTLS begins as a plain connection and upgrades it after the server advertises support, which is how server-to-server mail on port 25 works. Implicit TLS establishes encryption immediately on connection, before any SMTP command, and is what port 465 does. RFC 8314 recommends implicit TLS for mail clients submitting messages.

Can STARTTLS be stripped by an attacker?

Yes. An attacker on the network path can remove the STARTTLS capability from the server's EHLO response, and a sender doing opportunistic TLS cannot distinguish that from a server which genuinely lacks support, so it delivers in plain text. MTA-STS closes this by giving senders an authenticated statement, fetched over HTTPS, that TLS is required.

What does MTA-STS mode enforce actually do?

It tells senders that support the standard to refuse delivery unless they can open a TLS connection to a listed MX host with a certificate that validates and matches. Failures become deferred mail rather than a silent downgrade, so enforce should only follow a period in testing mode with TLS-RPT reports confirming that senders succeed.

Which hostname should my mail server's certificate cover?

The MX hostname a sender looked up, not the domain in the recipient address. A sender performing strict validation, whether through MTA-STS or its own policy, compares the certificate against the MX target it resolved. A certificate covering only the bare domain fails that comparison even when the server is otherwise correct.

SMTP and TLS: STARTTLS, MTA-STS and TLS-RPT

The conversation, end to end

An SMTP delivery is a short scripted exchange defined by RFC 5321. The receiver greets with a 220, the sender identifies itself with EHLO and is given a list of extensions, and the two then agree on an envelope: one MAIL FROM, one or more RCPT TO, then DATA, then the message itself terminated by a full stop on a line of its own.

Every response carries a three-digit code, and the first digit is what matters. A 2xx accepted the command, a 4xx is a temporary failure that the sender should retry, and a 5xx is permanent, so the sender gives up and generates a bounce. Confusing the two is the most consequential mistake a receiver can make: a 5xx issued for a transient problem destroys mail that a 4xx would have preserved.

A delivery with STARTTLS. Note the second EHLO: everything learned before the handshake is discarded and asked again inside the encrypted session.

220 mx1.example.net ESMTP ready
EHLO mail.example.com
250-mx1.example.net Hello mail.example.com [192.0.2.25]
250-SIZE 52428800
250-STARTTLS
250 ENHANCEDSTATUSCODES
STARTTLS
220 2.0.0 Ready to start TLS
... TLS handshake ...
EHLO mail.example.com
250-mx1.example.net Hello mail.example.com [192.0.2.25]
250 SIZE 52428800
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>
250 2.0.0 Ok: queued as 6C2A41F0B3
QUIT

Ports 25, 465 and 587

Port 25 is server-to-server relay. It is where mail from other domains arrives, it does not require authentication, and a great many networks block outbound connections to it precisely because compromised machines use it directly.

Port 587 is submission, defined by RFC 6409: a mail client handing a message to its own provider. It requires authentication, and the server is entitled to fix up the message on the way through. Port 465 is submission with TLS established immediately on connection rather than negotiated afterwards, which RFC 8314 restored as the recommended default for clients.

The distinction matters when reading a rejection. A 5xx on 587 with a relay-denied message is an authentication problem in a mail client; the same message on port 25 usually means a server is being asked to relay for a domain it does not host.

STARTTLS

STARTTLS, defined by RFC 3207, is an extension rather than a port. A receiver advertises it in the EHLO response; a sender that wants encryption issues the STARTTLS command, the two perform a TLS handshake over the existing connection, and the SMTP conversation begins again from EHLO.

The restart is not a formality. Anything the sender learned before the handshake was unauthenticated and must be discarded, which is why the second EHLO response can legitimately differ from the first — an authentication mechanism the server refuses to offer in the clear typically appears only after TLS is established.

Opportunistic TLS and its limits

Between mail servers, TLS is normally opportunistic: encrypt if the other side offers it, deliver in the clear if it does not. That choice was deliberate, because the alternative in a system with no prior arrangement between the parties is undelivered mail.

It defends against passive interception and nothing else. An attacker positioned on the path can remove the STARTTLS line from the EHLO response, and a sender doing opportunistic TLS sees a server that does not support encryption and continues in plain text — a downgrade the sender has no way to distinguish from an old server. The same position allows a substituted certificate, since opportunistic senders generally accept whatever they are given.

Neither weakness is a flaw in TLS. They exist because the sender has no authenticated statement about what the receiver supports, which is precisely the gap the next two standards fill.

Certificate validation between servers

Certificate validation in server-to-server SMTP is largely absent by default. A sending server that rejected untrusted certificates would fail to deliver to a long tail of hosts with expired or self-signed ones, so most accept anything and log the outcome.

That has a practical consequence for how a certificate should be provisioned: the name on it should match the MX hostname the sender looked up, not the domain in the recipient's address. A sender doing strict validation compares against the MX target, and a certificate issued for the bare domain will fail that comparison even though the mail server is correct.

MTA-STS

MTA-STS, defined by RFC 8461, lets a domain publish a policy stating that senders should require TLS with a valid certificate. It is delivered over HTTPS, which is what makes it resistant to the DNS-level tampering that plain STARTTLS is exposed to.

There are two pieces. A TXT record at the _mta-sts label announces that a policy exists and carries an id that changes whenever the policy does, so senders know when to re-fetch. The policy itself is a plain text file served from a fixed path on a host named mta-sts under the domain.

The mode field is the operational decision. Testing means senders check and report but still deliver on failure; enforce means a sender that cannot establish a validated TLS connection to a listed MX host does not deliver at all. Deploy in testing, read the reports for a full max_age period, and only then enforce — with the certificate renewal process understood, because an expired certificate under enforce is a mail outage rather than a warning.

The announcing TXT record and the policy it points at. The id changes on every policy edit; max_age is how long a sender caches it.

_mta-sts.example.com. IN TXT "v=STSv1; id=20260805T120000;"

; https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

TLS-RPT

TLS-RPT, defined by RFC 8460, is the feedback channel. A domain publishes a reporting address and receives daily JSON summaries from senders describing how their TLS connections went: how many sessions succeeded, how many failed, and for what reason — certificate name mismatch, expired certificate, a STARTTLS command that was refused, a policy that could not be fetched.

It is worth publishing before MTA-STS rather than after. Without it, moving to enforce is a change whose failures are invisible to you and visible only to the people who cannot reach you; with it, the failures arrive as a report naming the sending organisation and the exact error.

One record, and daily reports from senders describing every failed TLS session to your MX hosts.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Choosing what to enforce

MTA-STS is the pragmatic route for most domains: it needs a TXT record, a static file on an HTTPS host and certificates that renew reliably. DANE, defined by RFC 7672, achieves a similar guarantee by publishing certificate constraints in DNS, but it depends on DNSSEC across your zone, which is a larger undertaking and the reason MTA-STS exists alongside it.

Whichever you choose, enforcement moves a class of problem from silent to loud. A certificate that expires under opportunistic TLS causes a quiet downgrade to plain text; under enforce it causes deferred mail and eventual bounces. That is the correct trade for a domain handling anything sensitive, and it is only safe with monitoring and TLS-RPT already in place.

Check this on your own domain. The smtp server test reads the live records and reports what a receiver would see.

Open the smtp server test

Common questions

What is the difference between STARTTLS and implicit TLS?: STARTTLS begins as a plain connection and upgrades it after the server advertises support, which is how server-to-server mail on port 25 works. Implicit TLS establishes encryption immediately on connection, before any SMTP command, and is what port 465 does. RFC 8314 recommends implicit TLS for mail clients submitting messages.
Can STARTTLS be stripped by an attacker?: Yes. An attacker on the network path can remove the STARTTLS capability from the server's EHLO response, and a sender doing opportunistic TLS cannot distinguish that from a server which genuinely lacks support, so it delivers in plain text. MTA-STS closes this by giving senders an authenticated statement, fetched over HTTPS, that TLS is required.
What does MTA-STS mode enforce actually do?: It tells senders that support the standard to refuse delivery unless they can open a TLS connection to a listed MX host with a certificate that validates and matches. Failures become deferred mail rather than a silent downgrade, so enforce should only follow a period in testing mode with TLS-RPT reports confirming that senders succeed.
Which hostname should my mail server's certificate cover?: The MX hostname a sender looked up, not the domain in the recipient address. A sender performing strict validation, whether through MTA-STS or its own policy, compares the certificate against the MX target it resolved. A certificate covering only the bare domain fails that comparison even when the server is otherwise correct.

Keep reading

Related checks, definitions and guides.

How mail servers negotiate encryption, and how to require it