MTA-STS Checker

SMTP between mail servers uses opportunistic TLS. A sending server issues STARTTLS if the receiver offers it, and delivers in plaintext if not. It also accepts any certificate, because there was never a rule about what name the certificate should carry. An attacker on the network path can therefore strip the STARTTLS offer or present their own certificate, and the sender carries on without noticing. MTA-STS (RFC 8461, 2018) closes that gap by letting the receiving domain declare, in advance, that its MX hosts do support TLS and present certificates for their real names, so a sender that cannot get that must not deliver.

The declaration is in two parts. The TXT record at _mta-sts under the domain says a policy exists and carries an id that changes when the policy changes. The policy itself is a plain text file served over HTTPS from the host mta-sts under the domain, which is what lets it be authenticated without DNSSEC. DANE (RFC 7672) solves the same problem with TLSA records and does require DNSSEC. Google, Microsoft and most large providers honour MTA-STS when sending.

The mode line in the policy file decides what a sender does on failure. In testing mode the sender checks everything, delivers the mail regardless, and sends a TLS-RPT report describing any failure. In enforce mode the sender refuses to deliver when it cannot negotiate TLS with a certificate matching an mx pattern, and queues the message to retry. A third value, none, tells senders to drop any cached policy and is how a domain retires MTA-STS cleanly.

Start in testing with a short max_age, such as 86400, and publish TLS-RPT at the same time. After a week or two of clean reports, change mode to enforce, raise max_age to at least 1209600 (two weeks, the RFC's recommendation), and change the id in the TXT record so senders fetch the new policy. Enforce without a matching certificate on every MX host means your inbound mail from every MTA-STS-aware sender stops.

The file lives at the well-known path on the mta-sts host and is served as text/plain. It has four kinds of line, and every line uses a key, a colon and a value. Lines end in LF or CRLF, and there is no other syntax.

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
mx: *.backup-mx.example.net
max_age: 1209600

# _mta-sts.example.com TXT
"v=STSv1; id=20260917T093000"

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

Each mx line is a hostname or a single-label wildcard, and the certificate the MX host presents must be valid for that name. Microsoft 365 domains use one line, *.mail.protection.outlook.com. Google Workspace domains list smtp.google.com or the aspmx.l.google.com hosts. The value of max_age is in seconds, with a maximum of 31557600.

• The id never changes. Senders cache the policy for max_age and only refetch when the id in the TXT record differs from the cached one. Editing the file without changing the id leaves every sender on the old policy for up to a year.
• The policy host does not serve TLS properly. The certificate on mta-sts.example.com must be valid for exactly that name. A wildcard for *.example.com works, and a certificate for www.example.com does not. Senders do not follow redirects, so an HTTP to HTTPS redirect or a redirect to a CDN path also fails.
• The mx patterns do not match the real MX. A policy written when mail was self-hosted and left in place after a move to Microsoft 365 lists hosts that no longer exist. In enforce mode that blocks all inbound mail from aware senders. Our tool compares the patterns with the live MX records.
• A wildcard is expected to cover two labels. *.example.com matches mail.example.com and does not match mx1.eu.example.com.
• An MX host has the wrong certificate. The MX host must present a certificate for its own hostname, chained to a public CA. Self-signed certificates and expired certificates cause enforce-mode failures.
• max_age is too short. A short cache means a sender that briefly cannot reach the policy host has no policy at all. Two weeks is the recommended minimum once in enforce mode.
• No TLS-RPT. Without it, the only sign that enforce mode is breaking delivery is silence from a correspondent.

Query the two TXT records with dig and fetch the policy file with curl. Passing -i to curl shows the status line and the content type, and -v shows the certificate the policy host presented. The DNSX API runs all three checks and compares the policy against the MX records in one call.

$ dig TXT _mta-sts.example.com +short
"v=STSv1; id=20260917T093000"

$ curl -i https://mta-sts.example.com/.well-known/mta-sts.txt
HTTP/2 200
content-type: text/plain
...

$ dig TXT _smtp._tls.example.com +short
"v=TLSRPTv1; rua=mailto:[email protected]"

$ curl -s https://api.dnsx.dev/email/mta-sts/example.com | jq '.mode, .mx_match.summary'