MTA-STS Checker
Check both halves of MTA-STS: DNS discovery and the HTTPS policy that protects receiving mail.
Enter the receiving domain. A valid discovery record triggers a fetch from https://mta-sts.domain/.well-known/mta-sts.txt with certificate verification, no redirects and a size limit.
No registration required. Checks run on our server using Google Public DNS. Our DNS cache lasts up to five minutes; upstream DNS caches can delay changes further. No email test allowance is used.
How to use MTA-STS Checker
- Find your receiving domain in the addresses you host and your mailbox provider’s configuration. Before reviewing policy coverage, check your MX records and receiving server addresses.
- Enter only the domain. For mail addressed to
person@example.com, enterexample.com, notmta-sts.example.comand not the policy URL. - Select Check MTA-STS. There are no optional fields. Valid discovery syntax triggers retrieval of
https://mta-sts.example.com/.well-known/mta-sts.txtin this example. - Review discovery, HTTPS retrieval, policy syntax, mode and MX coverage separately. Correct the DNS record or policy file named in the finding, then rerun the check.
What this tool checks
The tool reads _mta-sts.domain TXT and the domain’s MX records through Google Public DNS. It retrieves the policy from the fixed HTTPS hostname and path after a valid discovery record is found.
- A unique
v=STSv1discovery record, duplicate or malformed tags, and a policyidcontaining 1–32 alphanumeric characters. - HTTPS retrieval with certificate verification, an HTTP 200 response, no redirects and a 64 KB response limit. Non-public destinations are blocked.
- Policy line syntax, duplicate fields,
version: STSv1, a supportedmode, and numericmax_agefrom 0 to 31557600 seconds. - Required MX patterns except in
nonemode, hostname and wildcard pattern syntax, and whether current MX hostnames match those patterns when the policy is valid and enabled.
A successful HTTPS fetch verifies the connection used to retrieve the policy. It does not validate the SMTP servers’ certificates, perform SMTP TLS handshakes or prove that senders enforce the policy. A missing optional discovery record stops the check before policy retrieval.
Understanding your results
Start in testing mode, align MX patterns with real receiving hosts and monitor TLS-RPT before enforcing. The checker does not perform a real SMTP TLS delivery.
| Finding | Meaning & likely cause | Next action |
|---|---|---|
| Info: not published | No recognized MTA-STS discovery record was found. MTA-STS is optional. | If deploying it, prepare the HTTPS policy and publish the discovery TXT record. |
| Fail: discovery syntax / multiple records | The version, tags or policy id are invalid, or discovery is ambiguous. | Keep one valid record at _mta-sts.domain; fix the indicated tag. |
| Pass: HTTPS policy / policy syntax | The policy was fetched over verified HTTPS, or its inspected fields passed syntax checks. | Read both findings and MX coverage. Fetch success alone does not make the contents valid. |
| Fail: HTTPS policy | An HTTP error, redirect or blocked destination prevented policy retrieval. | Serve the policy directly at the exact HTTPS URL with a valid certificate and within the size limit. |
| Fail: policy syntax | A required field, mode, age or MX pattern is invalid or duplicated. | Correct the policy file. Use separate mx: lines for separate allowed hostnames or patterns. |
| Info: testing / none | Testing requests observation without blocking delivery under this policy; none disables the policy. Previously cached policies may still exist. | Monitor TLS-RPT during rollout; account for policy cache expiry when changing or disabling enforcement. |
| Fail or Warning: MX coverage | No MX hosts exist, or a host is unmatched. Unmatched hosts fail in enforce mode and warn in testing mode. | Add the legitimate receiving host or a suitable pattern to the policy, or correct stale MX DNS. |
| Unknown: DNS / HTTPS request | DNS or the fetch could not complete; timeouts, TLS errors and response limits can be reported here. | Inspect the reported resource and retry after fixing availability. Unknown does not mean the policy is absent. |
What is MTA-STS and why does it matter?
Mail Transfer Agent Strict Transport Security (MTA-STS) lets a receiving domain publish a policy for encrypted SMTP delivery. A DNS record announces the policy, while an HTTPS file specifies its mode, allowed receiving hostnames and cache lifetime. Supporting senders can use it to resist transport downgrade and unexpected receiving hosts.
Use this checker when introducing MTA-STS, changing MX providers or debugging a policy download. testing supports observation; enforce requests enforcement; none disables the policy. These are published instructions, not evidence of a live encrypted delivery. TLS-RPT is configured separately to request reports about transport problems.
For a staged rollout and a troubleshooting sequence, see MTA-STS and TLS-RPT: Setup and Troubleshooting.
Frequently asked questions
Why is the HTTPS file not fetched when I know it exists?
The checker first requires one recognized discovery record with valid syntax. Fix the TXT record at _mta-sts.domain first. Enter the receiving domain in the form so the tool builds the correct discovery name and policy URL.
Can the policy URL redirect to my main website or CDN?
This checker does not follow redirects. Serve an HTTP 200 policy response directly at https://mta-sts.your-domain/.well-known/mta-sts.txt. A working redirect in an ordinary browser is not a passing result here.
What does a wildcard MX pattern match?
The implemented comparison treats *.example.com as matching one label, such as mail.example.com. It does not match example.com or a.b.example.com. Check each current MX hostname against the displayed patterns.
Why do senders still use an older policy after I change it?
MTA-STS policy caching is separate from this tool’s DNS cache. Review the previously published max_age and update the discovery id when changing the policy. Our eligible DNS answers may be cached for up to five minutes; a fresh result here does not prove every sender has refreshed its policy.
Does an HTTPS Pass mean my receiving server supports TLS?
No. That result describes retrieval of the web-hosted policy. The tool does not connect to the mail server. Review server TLS configuration and actual transport reports before relying on enforcement.