MTA-STS Checker

How to use this MTA-STS checker

MTA-STS helps a receiving domain publish a policy that tells supporting senders to use TLS when delivering mail to its MX hosts. The policy has two parts: a DNS TXT record at _mta-sts.example.com and a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. Both parts must be present and consistent for the policy to work correctly.

The scanner checks the DNS record, fetches the policy file through SSRF-protected HTTPS logic, validates required fields, reviews mode, max_age, MX patterns, duplicate fields, malformed lines, and whether live MX hosts match the policy patterns. It also checks TLS-RPT, which is the reporting mechanism used to receive information about mail transport security failures. TLS-RPT does not enforce TLS by itself. It helps you see failures and misconfigurations.

Start MTA-STS in testing mode. This lets you collect reports without risking mail delivery if an MX hostname, certificate, or policy pattern is wrong. After reports are clean, move to enforce mode with a reasonable max_age. The id value in the DNS TXT record must change whenever the policy file changes. If it does not change, senders may keep using the old cached policy.

MTA-STS should not be treated as a replacement for SPF, DKIM, or DMARC. It protects the transport path to your inbound mail servers. It does not prove that the sender is authorized and it does not stop From-domain spoofing. Use it as part of a layered email security posture with DMARC enforcement and careful monitoring.

Common MTA-STS mistakes this tool finds

• Missing _mta-sts TXT record.
• Policy file unreachable at the required HTTPS path.
• Mode set to none after deployment was supposed to be active.
• Malformed max_age, missing mx lines, or invalid version.
• Live MX hosts that do not match the policy file.
• Missing TLS-RPT record, which leaves failures harder to detect.

MTA-STS remediation workflow

MTA-STS protects inbound mail delivery by telling sending mail servers which MX hosts are expected and whether TLS must be enforced. It requires both a DNS TXT record at _mta-sts and a policy file hosted over HTTPS at mta-sts.domain/.well-known/mta-sts.txt. If one part is missing, senders cannot reliably apply the policy.

Start with mode testing and publish TLS-RPT so delivery problems are visible before enforcement. Review reports for certificate errors, wrong MX patterns, expired certificates, and providers that do not match the policy. Once reports are clean, move to enforce with a reasonable max_age. Do not publish a long max_age on day one because a mistake can cause delivery failures until senders refresh policy.

This tool validates policy structure, TXT count, mode, max_age, MX patterns, and safe fetching. It does not perform full SMTP STARTTLS negotiation with every MX host. That means a pass result indicates the public policy structure looks correct, not that every possible delivery path has been tested. Manual validation is still useful for critical domains.

How to interpret MTA-STS results

A successful MTA-STS result means the DNS record and HTTPS policy file appear structurally correct and the published MX patterns match the public MX records. It does not mean every mail path has been manually tested with SMTP STARTTLS, certificate chain validation, and provider-specific delivery behavior. Treat the result as a policy-health signal, not as a complete transport security audit.

Common production mistakes include forgetting to update the TXT id after changing the policy file, publishing more than one v=STSv1 TXT record, using wildcard MX patterns too broadly, setting max_age too high before testing, or moving to enforce before TLS-RPT reports are clean. These mistakes can either disable the policy or create delivery risk. The scanner highlights these cases so teams can correct them before moving to enforcement.

For critical domains, combine MTA-STS with TLS-RPT monitoring. Reports help identify senders that cannot negotiate TLS, MX certificate issues, policy mismatches, and intermittent transport failures. After reports are clean for a reasonable period, enforcement can be enabled with more confidence. VAPT Experts can manually validate mail transport configuration as part of an email security assessment.