MTA-STS Check

MTA-STS lets a domain require that incoming mail be delivered over authenticated TLS, defending against downgrade and man-in-the-middle attacks. IPeek reads the _mta-sts TXT record and fetches the policy file published at mta-sts.your-domain. It closes the gap left by opportunistic STARTTLS, which an attacker can silently strip.

MTA-STS uses two parts. A TXT record at _mta-sts.your-domain holds a version and a policy ID that tells sending servers a policy exists and changes when you update it. The policy itself lives in a plain-text file served over HTTPS at https://mta-sts.your-domain/.well-known/mta-sts.txt. That file lists the version, the mode, the permitted MX hostnames, and a max_age caching lifetime. A sender that supports MTA-STS fetches and caches the policy, then refuses to deliver to any MX whose certificate fails to validate against it.

IPeek shows whether the _mta-sts TXT record exists and whether the policy file is reachable over HTTPS. The mode value is what matters most. none means no policy is in effect, testing means failures are reported but mail still flows, and enforce means a sender must abort delivery if TLS authentication fails. Check that the mx entries in the policy match your real MX records and that the HTTPS certificate on the policy host is valid. A high max_age, often 604800 seconds, improves protection because cached policies resist live tampering.

The most common mistake is a TXT record that exists while the policy file returns a 404 or a redirect, which makes the policy unusable. The policy host must serve valid HTTPS, so an expired or mismatched certificate on mta-sts.your-domain breaks enforcement entirely. MX entries that drift out of sync with your DNS cause delivery failures once you switch to enforce. Roll out in testing first, monitor TLS-RPT reports for failures, and only move to enforce after confirming every MX presents a valid, matching certificate.