MX and STARTTLS test

How a message finds your server

When someone writes to anna@example.com, their mail server looks up the MX records of example.com. Each record names a server and gives it a number. The lowest number gets tried first and the others are fallbacks. The sending server then opens a connection on port 25 and the two machines talk in SMTP, a protocol from 1982 that sends everything as readable text.

Encryption came later, as an upgrade inside the same conversation. The receiving server lists STARTTLS among its capabilities, the sender replies with the same word, and from there the session is protected by TLS, the technology behind HTTPS. If the word isn’t on the list, the message travels in the clear.

What the test does on port 25

For up to five MX servers, in priority order, it resolves the first IPv4 address and plays the opening of a delivery:

S: 220 mx1.example.com ESMTP
C: EHLO <our server>
S: 250-mx1.example.com
S: 250-SIZE 52428800
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
   (TLS handshake, certificate read)
C: QUIT

And that’s where it stops. It never gives a sender, a recipient or a message. From the handshake it notes the TLS version, the cipher, the certificate’s issuer and expiry date, whether the certificate names the MX host, and whether its chain leads to a trusted authority.

After that it looks for two DNS records and one file: the TXT record at _mta-sts, the policy at https://mta-sts.example.com/.well-known/mta-sts.txt and the TXT record at _smtp._tls.

Reading the four tiles

Servers

How many MX hosts greeted the connection. One silent backup gets a warning. If none of them answers, senders queue your mail and return it after a few days.

Encryption

“Partial” means at least one reachable server didn’t complete STARTTLS. It’s the only finding here that turns the whole result red while mail keeps arriving.

Certificates

“Review” covers an expired certificate, a self-signed one, or one issued for another name. TLS 1.0 and 1.1 are flagged separately as outdated.

MTA-STS

Shows the mode found in the policy file: enforce, testing or none. It turns red when the DNS record exists but the file can’t be fetched, has no mode line, or leaves out one of your MX hosts.

A domain with no MX, or with the “null MX” record 0 ., is reported as not receiving mail. For a domain that only serves a website, that’s a valid setup.

Why a bad certificate still gets mail, and how MTA-STS changes that

Plain STARTTLS is opportunistic. Most senders encrypt when they can and don’t verify the certificate. So someone who controls the network path can delete the STARTTLS line from the reply and read everything. MTA-STS closes that hole. You publish, over HTTPS, the list of your MX hosts and the rule that they must present a valid certificate. Gmail and Outlook.com apply it when they send to you.

The policy file is four lines long:

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

Serve it from the mta-sts subdomain with a valid HTTPS certificate, then add two TXT records:

_mta-sts.example.com.   TXT "v=STSv1; id=20260115"
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Stay in testing until the daily TLS-RPT reports come back with no failures, then switch to enforce and change the id value so senders reload the policy. On hosted mail such as Google Workspace or Microsoft 365, the MX certificates are the provider’s job. The policy is the only part you have to publish.