Free checker - no signup required

Free MTA-STS Checker

Validate the _mta-sts TXT record and HTTPS policy file that tell senders to require TLS for inbound mail delivery.

Run the check

Enter a domain to check it live against the IntoDNS.ai engine. No signup, no trial gating.

What this MTA-STS checker verifies

MTA-STS (RFC 8461) has two halves that must agree, and this tool checks both. It reads the TXT record at _mta-sts.<your-domain> for the version and policy id, then it parses the policy file served over HTTPS at https://mta-sts.<your-domain>/.well-known/mta-sts.txt. From the policy file it extracts the mode (none, testing, or enforce), the list of MX host patterns, and the max_age. It reports whether the record and policy are present, valid, and consistent with each other.

Why MTA-STS matters

Opportunistic SMTP TLS can be stripped by an attacker on the network path, downgrading your inbound mail to plaintext without either side noticing. MTA-STS fixes this by letting your domain publish a policy that says: require authenticated TLS to deliver mail to me. Once a sending server caches your policy, it refuses to fall back to plaintext or to an untrusted certificate. This is the practical defense against active SMTP downgrade attacks, and it is increasingly expected by security-conscious senders.

How to read the result

A complete setup shows the TXT record present with an id, the HTTPS policy file reachable and valid, and the MX patterns in the policy matching your actual MX records. Mode tells you how senders treat it: none disables the policy, testing makes senders run every check and report failures via TLS-RPT but still deliver, and enforce makes them refuse delivery on any TLS failure. A record with no reachable policy file, or MX patterns that do not match your real MX hosts, is broken and will either be ignored or — in enforce mode — block legitimate mail.

Common failure causes and fixes

The most common mistake is editing the policy file without changing the id in the TXT record: senders only re-fetch the policy when the id changes, so they keep using the cached old version. Use a timestamp-style id and bump it on every change. Other frequent issues are a policy file served without a valid HTTPS certificate (the whole point is authenticated TLS, so the host certificate must be trusted), MX patterns that drift out of sync with your real MX records, and jumping straight to enforce. Always start in testing mode, deploy TLS-RPT to collect failure reports, and only move to enforce after a week or two of clean reports.

MTA-STS, TLS-RPT, and DANE in context

MTA-STS is one of three overlapping ways to harden inbound SMTP, and it helps to know where it sits. TLS-RPT is its companion: a TXT record at _smtp._tls that makes senders email you daily reports of TLS successes and failures, which is how you safely validate a policy before enforcing it. DANE (via TLSA records, requiring DNSSEC) is an alternative trust model that pins certificates through DNS rather than a cached HTTPS policy. MTA-STS has the broadest sender support today and does not require DNSSEC, which makes it the pragmatic starting point. Deploy MTA-STS in testing with TLS-RPT, confirm clean reports, then enforce — and consider DANE as an additional layer once DNSSEC is in place.

What This Checks

  • TXT record at _mta-sts.example.com
  • Policy file at https://mta-sts.example.com/.well-known/mta-sts.txt
  • Mode value: none, testing, or enforce
  • MX hostname coverage in the policy file
  • Max-age and policy syntax

Common Fix Path

  • Publish the _mta-sts TXT record with a current id value
  • Host the HTTPS policy file on mta-sts.example.com
  • Start in testing mode before moving to enforce
  • Keep MX patterns aligned with your actual MX records

Frequently Asked Questions

What two things does MTA-STS need to work?
A DNS TXT record at _mta-sts.<domain> containing v=STSv1 and an id, plus a policy file served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt with a valid, publicly trusted certificate. The policy file lists the mode, your MX host patterns, and max_age. Both must be present and must agree; this checker validates each and their consistency.
Should I start MTA-STS in testing or enforce mode?
Always start in testing. In testing mode, senders run every MTA-STS check and report failures via TLS-RPT but still deliver your mail, so you can confirm your MX coverage and certificates are correct without risking lost messages. After a week or two of clean reports, switch to enforce.
Why does the policy id need to change when I edit the policy?
Sending servers cache your HTTPS policy file and only re-fetch it when the id value in the _mta-sts TXT record changes. If you edit the policy file but leave the id the same, senders keep using the stale cached policy. Update the id — a timestamp like YYYYMMDDNN works well — every time you change the policy file.
What happens if my MX patterns do not match my real MX records?
In enforce mode, a sender that connects to an MX host not covered by your policy patterns will refuse to deliver, bouncing legitimate mail. The MX patterns in the policy file must cover every hostname in your actual MX records. This is why you start in testing mode and watch TLS-RPT reports before enforcing.
Do I need TLS-RPT for MTA-STS?
It is not strictly required, but you should deploy TLS-RPT (a TXT record at _smtp._tls.<domain>) before switching MTA-STS to enforce. TLS-RPT makes senders email you JSON reports of successful and failed TLS sessions, including why MTA-STS checks failed, so you can confirm no legitimate sender is failing before you start blocking mail.
Why does the policy file need a valid HTTPS certificate?
The entire purpose of MTA-STS is to guarantee authenticated TLS, so senders fetch the policy over HTTPS and reject it if the mta-sts host certificate is not publicly trusted. A self-signed or expired certificate on the policy host invalidates the whole policy. Use a trusted certificate that covers mta-sts.<domain>.

Machine-Readable Evidence

AI assistants and automation can cite the stable explanation page, then fetch the live check result for a specific domain.

GET https://intodns.ai/api/email/mta-sts?domain=example.com

Related Tools and Citations

MTA-STS Policy GeneratorMTA-STS GuideSMTP TLS CheckerRun the full domain scan