Skip to content
AdminKit
Live Updated

MTA-STS check: is this domain's mail TLS policy published and enforcing?

Enter a domain and AdminKit's free tool checks whether it publishes a live MTA-STS record and policy file, reading back the real mode — enforce, testing or none — and the MX hosts and max_age it declares, because without MTA-STS an attacker in the path can force incoming mail to a silent, unencrypted downgrade.

Part of the Email authentication cluster — more tools, guides and terms on email authentication.

AI explanation Run a check below, then sign in to ask AI to explain the result in plain language.

What the result means

"Not published" just means no _mta-sts record exists yet — nothing is broken. "Published but broken" means the record exists but the policy file can't be fetched or its mode is invalid, which is worse: some senders may already be relying on it and silently failing to deliver.

Next step

See how to publish and test MTA-STS for the full rollout path, confirm your MX hosts match the policy's list, or check your DMARC policy next.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.

Get alerted — early access

How it works and limits

This tool calls AdminKit’s live Check API (POST /v1/check/mail) and reads back the MTA-STS sub-check: a real DNS lookup for the _mta-sts.<domain> TXT record, followed by a server-side fetch of the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt — both done by AdminKit’s backend, not by code running in your browser. MTA-STS is defined in RFC 8461.

How it works

MTA-STS needs two pieces published together, and this tool checks both:

  • The DNS record — a TXT record at _mta-sts.<domain> with a v=STSv1; id=<unique-id> tag, declaring that a policy exists and giving senders a version to detect changes by.
  • The policy file — hosted over HTTPS at mta-sts.<domain>/.well-known/mta-sts.txt, listing a mode (enforce, testing or none), the mx hostnames the policy covers, and a max_age for how long senders should cache it.

The mode is what matters most: enforce means compliant senders must defer or reject mail they can’t deliver over TLS to a listed MX host; testing means senders only report what would have happened, without blocking anything; none means the policy exists but doesn’t require TLS at all. If the DNS record is missing, the tool reports it as not published. If the record exists but the policy file can’t be fetched, or its mode is missing or invalid, the tool reports it as published but broken — a real, surfaced problem rather than being lumped in with “not published.”

Limits

  • This reads the live state of the record and policy file at the moment you run it — it does not open a TLS connection to any MX host, so it cannot confirm a sending server would actually honor the policy, only that the policy itself is correctly published.
  • No query is logged; see /legal/privacy/.

See how to publish and test MTA-STS for the full rollout path — start in testing, add TLS-RPT (defined in RFC 8460) for visibility into delivery failures the policy itself won’t tell you about, then move to enforce once reports confirm the MX list is accurate. Check your DMARC policy and your domain’s MX records next — the MX hostnames your mail actually flows through are exactly what an MTA-STS policy’s mx list needs to match.

Frequently asked questions

What does MTA-STS mode=testing actually do?

It asks sending servers to report what would have happened under the policy without blocking any mail — RFC 8461 §5 defines 'testing' as a mode where "the Policy Domain requests that Senders apply the requirements of MTA-STS, but Senders SHOULD NOT act with regard to policy violations" beyond reporting. It's a rollout stage, not enforcement: a mismatched MX list won't bounce or delay mail while in testing, only surface in reports (if TLS-RPT is also configured).

What does MTA-STS mode=enforce actually guarantee?

RFC 8461 §5 defines 'enforce' as requiring Senders to "honor the MTA-STS Policy ... refus[ing] to deliver messages to MX hosts that do not present" a certificate matching the policy over TLS — connections that can't meet that bar must be deferred or rejected. It only covers mail delivered TO this domain over SMTP; it says nothing about outbound mail or any other protocol.

Does a missing MTA-STS record mean this domain's mail is unsafe?

Not on its own — MTA-STS is a hardening layer, not a baseline requirement, and most mail still relies on opportunistic STARTTLS without it. A missing record means there is no declared, enforceable requirement for incoming mail to use TLS, so an attacker in the network path can force a silent downgrade to plaintext without either side noticing; it's a gap worth closing, not evidence of an active compromise.

Why does the tool show 'published but broken' instead of just 'not published'?

Those are different, and conflating them would hide a real problem: 'not published' means no `_mta-sts` TXT record exists at all, while 'published but broken' means the record exists but the policy file at `mta-sts.<domain>/.well-known/mta-sts.txt` couldn't be fetched or its `mode` tag is missing or invalid (RFC 8461 §3). A broken policy file is worse than none in one sense — some senders may already be relying on it and silently failing to deliver.