MTA-STS Checker

Check whether a domain enforces TLS on inbound email with MTA-STS. Enter a domain and this tool reads the _mta-sts TXT record, fetches the policy file from the mta-sts subdomain, and parses its mode (enforce, testing or none), mx list and max_age. Crucially it then cross-checks the policy against the domain's real MX hosts and flags the dangerous case where a policy is enforcing but does not cover every mail server.

Reads the TXT record and MX hosts from public DNS and fetches the policy file over HTTPS from the server. Nothing is stored.

How to use the MTA-STS Checker

Enter a domain and press Check MTA-STS. The tool reports:

  • The signalling TXT record at _mta-sts.domain — whether it exists, its syntax, and its policy id.
  • The policy file at mta-sts.domain/.well-known/mta-sts.txt — the mode, the mx patterns and the max_age.
  • An MX coverage table: each of the domain's real mail servers and whether the policy's mx list actually covers it.
  • A single verdict: enforcing, testing, disabled, broken or not configured.

The coverage check is the part most tools skip. A policy in enforce mode that omits one of your MX hosts will cause mail to that host to be rejected, so the gap matters more than the record merely existing.

What MTA-STS is and why it matters

Email between mail servers travels over SMTP, and SMTP encryption (STARTTLS) is opportunistic: if the TLS handshake fails, or an attacker strips it, servers historically fall back to sending the message in plain text rather than not sending it at all. That fallback is the weakness. An on-path attacker can downgrade the connection or present a bogus certificate and read or alter the mail.

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) closes that gap. It lets a domain publish a policy that says: "my mail servers support TLS with a valid certificate, so refuse to deliver to me over an unencrypted or untrusted connection." A sending server that supports MTA-STS will then decline to downgrade, defeating the strip-and-read attack.

A working setup has two parts, and this checker inspects both:

  • The signalling TXT record at _mta-sts.example.com, e.g. v=STSv1; id=20240105T120000;. Its only job is to tell senders a policy exists and, via the id, when it last changed so they know to refetch it.
  • The policy file, served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt. It lists the mode, the allowed mx hostnames (exact or one wildcard label like *.example.com), and max_age (how long senders cache the policy).

The mode decides what actually happens. none means the policy is published but inactive. testing means senders evaluate the policy and send TLS-RPT failure reports, but still deliver even on failure — the safe way to roll out. enforce means senders will refuse to deliver if TLS or the certificate or the MX match fails. That last point is why the mx list must include every real MX host: under enforce, mail to a server missing from the list is bounced. The combination of a valid TXT record, a reachable policy over good HTTPS, enforce mode, and complete MX coverage is what this tool confirms.

Common use cases

  • Confirming enforcement — verify a domain is actually in enforce mode, not stuck in testing or none.
  • Catching the coverage gap — make sure every MX host is in the policy before flipping to enforce, so legitimate mail is not bounced.
  • Finishing a rollout — check that both the TXT record and the policy file are live and consistent after setup.
  • Debugging delivery failures — diagnose mail being rejected after an MX change that the MTA-STS policy was not updated to match.
  • Auditing a domain — see at a glance whether a domain protects inbound mail against TLS downgrade.

Fixing common MTA-STS problems

The states worth acting on, and what each needs:

  • TXT present but policy unreachable (broken). The signalling record points senders at a policy file that does not load — usually the mta-sts subdomain is missing, has no valid certificate, or the file is not at /.well-known/mta-sts.txt. The policy must be served over HTTPS with a valid certificate; fix the host or the certificate.
  • Enforcing but a MX host is not covered. The most dangerous state: mail to the uncovered server is rejected. Add the missing hostname (or a correct *. wildcard) to the policy's mx list, then let caches expire.
  • Still in testing. Testing mode reports failures but never blocks, so it gives no protection. Once reports are clean, change mode to enforce and bump the policy id in the TXT record so senders refetch.
  • Pair it with TLS-RPT. Add a _smtp._tls TLS-RPT record so you receive reports when a sender fails to deliver under your policy — essential feedback during rollout.

To build the records and policy file in the first place, use the MTA-STS Generator and the TLS-RPT Generator. To confirm the underlying mail records, the MX Lookup shows your real mail servers and the DMARC Checker covers the wider email-auth picture.

Frequently asked questions

How do I check a domain's MTA-STS policy?
Enter the domain above and press Check MTA-STS. The tool reads the _mta-sts TXT record, fetches the policy file from the mta-sts subdomain, parses the mode, mx list and max_age, and cross-checks the policy against the domain's real MX hosts.

What does MTA-STS actually protect against?
It stops TLS downgrade and interception of inbound email. Normal SMTP encryption is opportunistic and can be stripped, falling back to plain text. MTA-STS tells sending servers to refuse delivery unless TLS with a valid certificate succeeds, defeating that attack.

What is the difference between testing and enforce mode?
In testing mode senders evaluate the policy and send failure reports but still deliver mail even if TLS fails, so it gives no protection. In enforce mode senders refuse to deliver when TLS, the certificate, or the MX match fails. Roll out in testing, then switch to enforce.

Why does the MX coverage check matter?
Under enforce mode, mail to any MX host not listed in the policy is rejected. If you add or change a mail server but forget to update the policy mx list, legitimate mail bounces. This tool flags that gap so you can fix it before enforcing.

Why is my policy file unreachable?
The policy must be served over HTTPS with a valid certificate at https://mta-sts.yourdomain/.well-known/mta-sts.txt. Common causes are a missing mta-sts subdomain, an invalid or expired certificate on it, or the file being in the wrong path.

Does this store the domains I check?
No. The DNS records and policy file are fetched live to answer your request and not retained, beyond a short per-IP rate-limit counter to prevent abuse.