DNS Tools
MAIL TRANSPORT SECURITY

MTA-STS Checker

Enter a domain to read its _mta-sts TXT record, fetch the policy file from the mta-sts subdomain over HTTPS and compare the policy's mx patterns with the real MX set.

Run MTA-STS check

No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.

What MTA-STS is

MTA-STS (RFC 8461) lets a domain tell sending mail servers to deliver only over TLS with a certificate valid for the MX name. It has two parts. A TXT record at _mta-sts.DOMAIN holds a version and an id. The policy itself is a plain-text file served over HTTPS at https://mta-sts.DOMAIN/.well-known/mta-sts.txt, listing the mode, the allowed mx patterns and a max_age in seconds.

Senders that support MTA-STS fetch the policy, cache it for max_age seconds, and use the id to learn when the policy changed. The tool performs the same steps from its own network position.

How to read the result

The tool reports the record state first: absent, duplicated, malformed or valid. If the record is valid it fetches the policy and checks the syntax, the Content-Type (RFC 8461 requires text/plain), the certificate of the policy host and its days remaining.

Three policy modes exist. enforce means validating senders must not deliver without validated TLS. testing means failures are reported but mail is still delivered, so it gives no protection. none withdraws the policy. The MX match finding compares each published MX host with the policy's patterns; in enforce mode, a host that no pattern covers is a risk because compliant senders will refuse to deliver to it. The max_age finding flags values under a day and suggests at least a week for enforce mode.

Common problems

  • Policy host unreachable. The mta-sts subdomain has no DNS record, no HTTPS listener or a certificate that does not validate. Senders then cannot get a fresh policy.
  • Policy not updated after change. The id in the TXT record was not changed, so senders keep the cached policy.
  • MX host missing from the policy. Typical after adding a new provider.
  • Wrong content type or redirects. The file must be served directly as text/plain. A redirect to another host does not satisfy the specification.
  • Certificate expired on the policy host. The policy becomes invisible and enforcement silently weakens or senders retry.
  • Staying in testing indefinitely. The policy then reports problems but never protects.

How to roll it out safely

Prerequisites: every MX host presents a certificate valid for its own name (use the STARTTLS checker), you can host a small HTTPS site on mta-sts.DOMAIN, and you have a way to receive TLS reports. Operational risk is high in enforce mode: if an MX certificate fails, compliant senders will hold or bounce mail, and they will remember the old policy until max_age expires. Rollback: publish a policy with mode: none and a new id; it takes effect for each sender only when it next refreshes.

  1. Fix MX certificates first and confirm them.
  2. Publish the policy in mode: testing with a short max_age such as 86400, and the TXT record with an id.
  3. Add TLS-RPT and review reports for several weeks.
  4. Switch to mode: enforce only when reports show no failures, and raise max_age in stages.
  5. Publish the new policy before changing MX records, and change the id every time the file changes.

What this tool does not verify

The policy is fetched once from this scanner. Senders may hold an older cached copy for up to max_age. The tool does not test the certificates of the MX hosts, and it cannot say which senders honour MTA-STS. Support varies between sending providers, and MTA-STS only protects mail from senders that implement it. A DNS failure is reported as unknown, not as absence of the record.

Frequently asked questions

Does testing mode protect my mail?

No. In testing mode senders report failures but still deliver. It is a rollout stage.

Why must the id change?

Senders use the id to decide whether to refetch the policy. If you edit the file but not the id, they may keep using the old one.

How is MTA-STS different from DANE?

DANE uses DNSSEC-signed TLSA records. MTA-STS relies on HTTPS and the public CA system and needs no DNSSEC.

Do I need a separate website for the policy?

You need an HTTPS host named mta-sts.yourdomain serving that one file. Many providers can host it for you.

What value of max_age should I use?

Short while testing, then raised to weeks once stable. Longer values delay MX changes.

Will MTA-STS stop all downgrade attacks?

Only from compliant senders and only after they have fetched the policy at least once. The first fetch is trust on first use.

Written by DNS Tools editorial · Last updated 2026-10-09