Skip to content
Clinic open · free diagnosis, no appointment needed2,000+ domains monitored

MTA-STS policy check

Fetches your policy the way a sending server does, HTTPS, no redirects, certificate validated, then checks it lists every mail host you actually run.

Judged against RFC 8461

Free, instant, no signup. This test reads your live DNS the way a receiving server does.

Symptoms

There is no symptom. That is the point of this one: a downgrade attack leaves no trace in your mail, no bounce, no warning. The only visible failure mode is the opposite, an enforcing policy that omits one of your own mail servers, at which point inbound mail starts being refused by senders who are following your instructions correctly.

Diagnosis

MTA-STS is two things that must agree: a short DNS record announcing that you have a policy, and the policy itself, served over HTTPS at a fixed location.

The announcement

A TXT record at _mta-sts.yourdomain.com containingv=STSv1; id=…. The id changes every time you edit the policy, that is how senders know to re-fetch rather than use what they cached.

The policy

A plain text file athttps://mta-sts.yourdomain.com/.well-known/mta-sts.txt listing a mode, your mail hosts and a lifetime. Three rules decide whether senders accept it: it must be HTTPS with a valid certificate, it must return 200, and it must not redirect. A policy behind a redirect does not exist as far as any sending server is concerned, which is the failure we find most often, usually a web host quietly forcing every path through a canonical redirect.

The modes

  • testing, failures are reported, mail is delivered anyway. Start here.
  • enforce, TLS is required, and delivery fails without it. The goal.
  • none, withdraws a policy cleanly. Not a place to stay.

Cure

  1. Publish the policy file first, in testing mode, listing every host from your MX records. Confirm it loads in a browser with no redirect.
  2. Then publish the DNS record with an id you will change on every future edit.
  3. Turn on TLS-RPT so failures are reported to you rather than discovered later.
  4. Move to enforce once a couple of weeks of reports are clean, and remember to update the policy, and the id, whenever your MX records change.

Questions people actually ask

What does MTA-STS actually protect against?

Downgrade attacks. SMTP negotiates TLS in the open, so anyone on the network path can strip the offer and the sending server will happily deliver in plain text rather than fail. MTA-STS tells senders that TLS is required for your domain, so stripping it makes delivery fail instead of succeeding insecurely.

Why does my policy have to be on a web server?

Because DNS alone cannot be trusted for this without DNSSEC. The policy is fetched over HTTPS, and the certificate is what proves it is really yours. That is also why the fetch must not follow redirects, a redirect would let somebody else answer for you.

Is testing mode worth publishing?

Yes, and it is where you should start. In testing mode senders report failures without changing delivery, so you find out whether enforcement would break anything before it does. Pair it with TLS-RPT and move to enforce once the reports are clean.

What happens if my policy misses one of my MX hosts?

Under enforce, senders refuse to deliver to a host the policy does not cover. A policy that omits a live mail server rejects your own inbound mail, which is why this test checks the policy against your real MX records rather than reading it in isolation.

Related tests

Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.