Your MTA-STS record may be protecting nothing: how to check
Published: October 16, 2026
This week our own monitor flagged it on our own domain. The _mta-sts TXT record was published and every DNS checker showed it as correct. But the policy it announced could not be read: the server behind mta-sts. answered with a self-signed certificate. For any server sending us mail, our MTA-STS did not exist.
It is an easy mistake to miss, because nothing breaks. Mail keeps arriving. The only thing lost is the protection you thought you had.
What MTA-STS needs to work
MTA-STS (RFC 8461) tells other mail servers: "only deliver to my domain over an encrypted connection, and only to these servers". It has two pieces, and both have to be right:
- A TXT record at
_mta-sts.yourdomain.comthat announces the policy, for examplev=STSv1; id=20261016000000;. - A text file, the policy itself, served at
https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.
The second piece has three strict requirements: it must be served over HTTPS, with a certificate valid for mta-sts.yourdomain.com from a public certificate authority, and with a direct 200 answer. Senders do not follow redirects.
A typical policy looks like this:
version: STSv1
mode: testing
mx: mx1.yourprovider.net
mx: mx2.yourprovider.net
max_age: 86400What happens when the policy can't be read
A sender that supports MTA-STS, such as Gmail or Microsoft 365, sees the TXT record and tries to download the policy. If it can't, because of a bad certificate, a redirect or a missing file, it acts as if your domain had no MTA-STS at all. It delivers the message as before, encrypted if possible and in clear text if not.
There is no bounce and no warning to you. The record in DNS says you are protected, and the senders that matter are ignoring it.
If you also publish TLS-RPT (_smtp._tls.yourdomain.com), the daily reports from senders will show it as sts-policy-fetch-error or sts-webpki-invalid. Without TLS-RPT, nobody tells you.
The usual causes
The mta-sts host does not exist on the web server
The DNS name points to your server, but no site is configured for it. The server answers with its default site, which usually has a certificate for another name or a self-signed one. This was our case.
The certificate does not cover the name
The certificate is valid, but for yourdomain.com and www.yourdomain.com only. A wildcard certificate for *.yourdomain.com does cover mta-sts.yourdomain.com; one for the bare domain does not.
A redirect in the way
Rules that send everything to https://www or to the home page also catch the policy file. For a browser that is fine; for a mail server it is a failure.
The certificate expired
It worked when it was set up. Ninety days later the renewal failed for that one name, and nobody looked at it again.
How to check it
First, the record:
dig +short TXT _mta-sts.yourdomain.comThen the policy, exactly as a sender would ask for it. If the certificate is not valid, curl will refuse the connection and say why:
curl -sS -D - https://mta-sts.yourdomain.com/.well-known/mta-sts.txtYou want a 200, Content-Type: text/plain and the policy text. To see which certificate the server is actually presenting:
openssl s_client -connect mta-sts.yourdomain.com:443 -servername mta-sts.yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -subject -ext subjectAltName -enddateThe subjectAltName must include mta-sts.yourdomain.com, and the issuer must be a public authority, not your own server.
Finally, compare the mx: lines of the policy with your real MX records (dig +short MX yourdomain.com). A server missing from the policy will be refused once you switch to enforce.
Our free diagnosis runs these checks in one go: the record, the policy, its certificate and the match with your MX records.
How to fix it
- Create a site for
mta-sts.yourdomain.comon your web server, or on any static host, that serves only the file/.well-known/mta-sts.txtastext/plain. - Get a certificate for that exact name. Let's Encrypt is free; with Apache and certbot it is one command:
certbot --apache -d mta-sts.yourdomain.com. - Make sure no redirect applies to that site.
- Check again with
curl. If the answer is the policy text with no error, senders can read it.
You do not need to change the TXT record to fix this. Senders that failed will try again and find the policy.
Afterwards: from testing to enforce
Start with mode: testing. Senders read the policy, report problems through TLS-RPT and still deliver. When the reports have been clean for a couple of weeks, switch to mode: enforce, raise max_age to at least a week (604800), and change the id in the TXT record so senders fetch the new version.
One more thing: the certificate of mta-sts. renews like any other, and if one renewal fails, the protection disappears again just as silently. That is the kind of thing worth watching continuously, not checking once.