Free MTA-STS Checker

What is MTA-STS?

Mail Transfer Agent Strict Transport Security (MTA-STS, RFC 8461) is a mechanism that enables mail service providers to declare their ability to receive TLS-secured SMTP connections. It effectively prevents TLS downgrade attacks and man-in-the-middle attacks during email delivery, ensuring that messages are always encrypted in transit.

MTA-STS works through two components: a DNS TXT record at _mta-sts.yourdomain.com that signals MTA-STS support and tracks policy versions, and an HTTPS-hosted policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that defines the enforcement mode, authorized mail servers, and policy lifetime.

Mode Reference

How to Set Up MTA-STS

1. Create a policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with your version, mode, MX patterns, and max_age.
2. Add a DNS TXT record at _mta-sts.yourdomain.com with v=STSv1; id=unique-id.
3. (Optional) Add a TLS-RPT record at _smtp._tls.yourdomain.com for failure reports, e.g. v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com.

Limitations & Risks

• Operational overhead — MTA-STS requires maintaining both a DNS record and an HTTPS-hosted policy file on a dedicated subdomain (mta-sts.yourdomain.com) with a valid TLS certificate.
• Mail delivery risk in enforce mode — If your MX servers experience TLS issues (expired certificate, misconfiguration), sending servers that have cached your policy will refuse to deliver mail until TLS is restored.
• Trust-on-first-use (TOFU) — The first time a sending server fetches your policy, the request could theoretically be intercepted. DANE/TLSA (the DNSSEC-based alternative) does not have this limitation, but requires DNSSEC deployment.
• Policy propagation delay — Sending servers cache your policy for the duration of max_age. Changes to MX servers or TLS configuration require careful coordination, as outdated cached policies can block delivery.
• Certificate dependency — If the TLS certificate on mta-sts.yourdomain.com expires, sending servers cannot fetch updated policies. Cached policies still work until max_age expires.

Best Practices

• Start with mode: testing before switching to enforce.
• Use a max_age of at least 604800 seconds (1 week) in production.
• Ensure MX patterns in the policy match your actual MX records.
• Enable TLS-RPT (_smtp._tls) for visibility into delivery failures.
• Update the id in the DNS record whenever the policy file changes.