Free tool · Mail transport
MTA-STS + TLS-RPT checker
Look up the MTA-STS DNS record, fetch the policy file from the well-known location, and check for a TLS-RPT reporting endpoint - all in one shot. No signup.
What this tool checks
We resolve _mta-sts.<domain> in DNS, parse the version + id tags, then fetch the policy file from https://mta-sts.<domain>/.well-known/mta-sts.txt. We validate the policy syntax (mode, mx, max_age) and the TLS posture of the policy host - the policy file MUST be served over HTTPS or the entire MTA-STS posture is invalid.
We also resolve _smtp._tls.<domain> for the TLS-RPT record (RFC 8460), which tells receivers where to send daily JSON reports about TLS negotiation failures and policy enforcement issues. Without a TLS-RPT endpoint you have no visibility into whether MTA-STS is actually working.
Mode interpretation matters: testing = log only, enforce = receivers reject mail that fails policy. Most domains start at testing for 30-90 days then graduate to enforce once TLS-RPT confirms zero failures.
How to read the results
Mode = testing: receivers will report failures via TLS-RPT but won't block. Safe place to soak.
Mode = enforce: receivers reject mail when MTA-STS policy can't be honored (no TLS, expired cert, MX mismatch). High value for spoofing prevention; non-zero risk if your MTA fleet has any cert-rotation / MX-update misses.
max_age in seconds. Common values: 86400 (1 day, aggressive), 604800 (1 week, normal), 31557600 (1 year, stable infra). Receivers cache the policy for this duration.
TLS-RPT missing: you're flying blind on transport encryption posture. Add at minimum: v=TLSRPTv1; rua=mailto:[email protected] and skim the daily reports for failures.