Transport security
MTA-STS & TLS-RPT Checker
Enter a domain. We resolve the _mta-sts and _smtp._tls TXT records, fetch the policy file at the well-known URL, look up MX records, and cross-check every MX host against the policy.
New to MTA-STS? Read What is MTA-STS in the Email Almanac.
How it works
What this tool checks
Four signals decide whether your MTA-STS deployment is doing its job. Missing any one leaves a gap that downgrade attackers can exploit.
- _mta-sts DNS record. We resolve the TXT record at _mta-sts.<domain> and confirm v=STSv1 plus the policy id. Without this record, senders never discover your policy.
- Policy file. We HTTPS GET https://mta-sts.<domain>/.well-known/mta-sts.txt and validate version, mode (testing / enforce / none), mx patterns, and max_age. The web server must serve it over valid TLS.
- _smtp._tls DNS record. We resolve the TLS-RPT TXT record. Without it you never see reports of TLS failures and policy violations.
- MX cross-check. We pull the domain's MX hosts and verify each one matches at least one mx: pattern in the policy. Uncovered hosts get rejected when the mode is enforce.
When to use it
Two moments matter most
MTA-STS prevents passive downgrade of inbound mail. The deployment is brittle and easy to misconfigure, so this tool is built for two clear moments.
- First deploy. Run the checker right after you publish the DNS record and policy file. Start in testing mode, fix every flagged item, then switch to enforce.
- After MX changes. Any time you add or change MX hosts, re-run the tool. A new MX host that no policy pattern covers will cause hard delivery failures in enforce mode.
Related reading
From the Email Almanac
Two short reads that pair with this tool.
Want a full deliverability audit?
Transport security is one signal. We read every signal that affects whether your mail lands in the inbox and hand you a plain-English report.
Try it deeper with RME