ConfiguRadar

MTA-STS checker

Fetches your published policy over HTTPS exactly as a sending server would, then cross-checks it against your live MX records.

Why MTA-STS breaks quietly

MTA-STS has two halves that live in different places: a DNS record, and a policy file served over HTTPS at a fixed well-known path. The DNS record is set once and rarely touched. The policy file lives on web infrastructure that gets migrated, put behind a CDN, or reconfigured. When it stops being served correctly, nothing visibly breaks. The domain keeps advertising MTA-STS while no sender can retrieve the policy.

What this checks

  • The DNS record at _mta-sts: begins with v=STSv1 and carries an id of 1 to 32 alphanumeric characters.
  • Policy retrieval over HTTPS. RFC 8461 §3.2 requires a 200 response and states that 3xx redirects must not be followed, so a policy URL that redirects, even to a working page, is unusable.
  • Certificate validity for the policy host.
  • Policy syntax: version, mode, max_age, and at least one mx entry unless mode is none.
  • MX coverage, described below.

MX coverage and the wildcard rule

In enforce mode, senders honouring your policy will only deliver to hosts matching an mx pattern in it. If a live mail exchanger matches none of them, those senders cannot deliver to it.

The wildcard rule is stricter than most people expect. Per RFC 8461 §4.1, * matches exactly one entire leftmost label:

PatternHostMatch?
*.example.commail.example.comYes
*.example.comexample.comNo, nothing for the wildcard to consume
*.example.commail.eu.example.comNo, that is two labels

That last row is the one that causes real outages after a regional mail migration.

Rolling it out safely

Publish with mode=testing first. Senders then report TLS failures without changing delivery, which lets you confirm coverage before enforcing. Move to enforce once TLS reports are clean.

Related