Domain Stabilizer
Sign in

Your MTA-STS record may be protecting nothing: how to check

Published: October 16, 2026

ESENPT

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:

  1. A TXT record at _mta-sts.yourdomain.com that announces the policy, for example v=STSv1; id=20261016000000;.
  2. 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: 86400

What 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.com

Then 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.txt

You 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 -enddate

The 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

  1. Create a site for mta-sts.yourdomain.com on your web server, or on any static host, that serves only the file /.well-known/mta-sts.txt as text/plain.
  2. 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.
  3. Make sure no redirect applies to that site.
  4. 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.

Check your domain

The free diagnosis checks SPF, DKIM, DMARC, MTA-STS, SSL, DNS and blocklists in under a minute. Read-only, no account.

Free diagnosis

If you manage your clients’ domains, Domain Stabilizer watches them continuously and tells you when something gets worse. How it works

Domain Stabilizer

Domain stabilization: DMARC, SSL, DNS, MX, blacklists and uptime — exact fixes and evidence of the work.

Secure connection (TLS)
GDPR‑aligned practices
Helpful support
Product
PricingFree domain diagnosis

© 2026 Domain Stabilizer. All rights reserved.

Made with ❤️ for teams that care about reliable delivery.