PostureAudit

MTA-STS not working: why your policy is being ignored

MTA-STS is unusual among email standards: it needs a DNS record and a policy file served over HTTPS. Publish the record without a working file and receivers don't warn you or fall back to a partial mode — they ignore MTA-STS entirely. Your domain looks configured and has no protection.

What MTA-STS is actually for

SMTP encrypts opportunistically. A sending server asks for STARTTLS, and if the answer is no, it usually delivers in plaintext anyway. An attacker between the two servers can strip the STARTTLS offer and quietly downgrade the whole conversation.

MTA-STS lets you say: mail for this domain must go over TLS, to these hostnames, with a valid certificate. A sender that has seen your policy will refuse to deliver rather than be downgraded.

The two halves, and why one usually fails

HalfWherePurpose
DNS record _mta-sts.yourdomain.com TXT Announces a policy exists, with an id= that changes when the policy changes
Policy file https://mta-sts.yourdomain.com/.well-known/mta-sts.txt The actual rules: mode, MX hostnames, lifetime

The DNS half is easy and gets done. The HTTPS half needs a subdomain, a certificate, and something serving a static file — three chances to break, on infrastructure nobody revisits. That asymmetry is why the common failure is always the same: the record is there and the file is not.

The four things that break it

1. Nothing serving mta-sts.

The subdomain doesn't exist, or resolves somewhere that returns 404. Publishing the TXT record is not enough on its own.

2. A certificate that doesn't cover the subdomain

A wildcard covering *.yourdomain.com works. A certificate issued only for the apex does not. Senders validate it strictly — an invalid certificate means the policy is unusable, and unusable means ignored.

3. A redirect

The policy must be served directly at that URL with a 200. Redirecting to a CDN, to the apex, or from HTTP to a different host makes it invalid. This one bites people whose web host redirects every subdomain to www by default.

4. mode: testing, left there

testing reports failures but still delivers over plaintext. It is the correct place to start and the wrong place to stay. Plenty of domains have been in testing mode for years, getting reports nobody reads and no actual protection.

Changing the policy? Update the id= in the DNS record too. Senders cache by that value — a new policy file with an unchanged id may not be picked up until the cached copy expires, which can be a very long time.

A working setup

DNS:

_mta-sts.example.com.  TXT  "v=STSv1; id=20260819120000"

Served at https://mta-sts.example.com/.well-known/mta-sts.txt as text/plain:

version: STSv1
mode: enforce
mx: mail.example.com
mx: mail2.example.com
max_age: 604800

Every hostname that appears in your MX records must be listed, or mail to the missing host fails once you are in enforce. Check this before switching modes, not after.

Pair it with TLS-RPT

MTA-STS tells senders to enforce TLS; it doesn't tell you when enforcement fails. TLS-RPT does — a TXT record at _smtp._tls.yourdomain.com asking receivers to send you reports:

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

Publish it before moving to enforce. Reports are how you find out that a sender can't reach you, rather than learning it from the person who didn't get a reply.

Related guides