Primary use
Transport policy check
Validate both MTA-STS discovery and the HTTPS policy file from one page.
Free MTA-STS checker
Free MTA-STS checker and policy lookup
Run a free MTA-STS checker to validate the DNS discovery record and the live .well-known policy file for any domain. Use it before transport-security rollouts, after DNS or CDN changes, and during mail-security reviews when SMTP TLS posture matters.
Run a free lookup
Check the live MTA-STS record and policy file
Enter the root domain. This checker validates DNS discovery, the expected policy-file URL, and the live body returned by the .well-known endpoint.
Best fit
Use this when transport policy is part of the change
This page is strongest after DNS or web changes, before transport-policy rollout, and during security reviews when SMTP TLS posture needs a quick validation path.
- Check MTA-STS after DNS or web-hosting changes
- Validate policy hosting before a stricter rollout
- Give security and messaging owners one shared transport view
Upgrade path
Pair transport checks with sender-domain monitoring
Transport policy is only one part of production mail posture. Teams usually pair it with MX, DMARC, SPF, and DKIM review when reliability and trust need named ownership.
- Review mail routing and sender auth alongside transport policy
- Use domain-level monitoring before major launch windows
- Keep security and deliverability posture in one operational flow
Key details
Critical dependency
.well-known file
Catch missing or broken policy hosting before transport expectations rely on it.
Operational fit
Post-change review
Use it after DNS, CDN, or web-server changes that could affect MTA-STS visibility.
Output
DNS + policy
See the DNS record, file presence, and policy body together in one troubleshooting view.
When to use this tool
Validate discovery
Confirm the _mta-sts record is published where receivers expect to find it.
Check the policy file
Verify the HTTPS policy document is actually reachable and returns the expected content.
Reduce rollout risk
Catch CDN, redirect, or hosting mistakes before transport policy assumptions break mail delivery.
What this returns
A useful MTA-STS checker should answer both discovery and policy-hosting questions
The valuable output is not just whether a TXT record exists. It is whether receivers can discover the policy, retrieve the policy file, and see content that matches the intended transport rollout.
DNS
_mta-sts record
Confirm transport policy discovery is published at the expected DNS name.
HTTPS
Policy file
Check that the .well-known policy file is reachable and present.
Body
Live content
Review the current file body instead of assuming the server is returning the intended policy.
Warnings
Review notes
Catch issues that deserve follow-up before transport assumptions are relied on in production.
Operational use
Best used after DNS or hosting changes and before stricter transport expectations
Teams usually reach for an MTA-STS lookup because they are changing policy or verifying that transport security is still intact after infrastructure work.
After CDN or web changes
Re-run the checker after redirects, caching, or hosting changes so the policy file is still discoverable where receivers expect it.
Before transport rollout
Validate discovery and file content before tightening policy so rollout errors are caught before they affect mail transport.
During security review
Give security and messaging owners a shared reference point when auditing SMTP TLS posture across domains.
Related tools
MTA-STS record generator
Generate the DNS and policy-file values when the current setup needs to be rebuilt.
Open toolTLS reporting checker
Validate report visibility alongside transport-policy discovery and hosting.
Open toolMX lookup
Review inbound routing alongside transport policy when mail infrastructure is changing.
Open toolDomain monitor
Pair transport checks with sender-domain posture before production launches.
Open toolFAQ
What does an MTA-STS checker validate?
An MTA-STS checker verifies the DNS policy record and the HTTPS well-known policy file so you can confirm transport security settings are both published and reachable.
Why do I need both the DNS record and the policy file?
Receivers need the DNS record to discover MTA-STS and the policy file to understand the actual mode and expected MX hosts. Missing either piece weakens the setup.
When should teams run an MTA-STS lookup?
Run it after DNS or CDN changes, before enforcing transport expectations, and during mail-security reviews when SMTP TLS posture needs verification.
What if the policy file is missing?
That usually means the HTTPS path is not published correctly, a CDN rule is stripping the response, or the file location is different from the expected .well-known path.