MTA-STS Record Checker

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) lets a domain tell other mail servers that they must use encrypted, authenticated TLS to deliver email to it. Without it, SMTP encryption is opportunistic: an attacker who can intercept the connection can strip TLS and read or alter messages (a downgrade attack). MTA-STS closes that gap by publishing a policy sending servers are required to honour.

Two parts that must both be present. First, a DNS TXT record at _mta-sts.yourdomain.com containing v=STSv1 and an id. Second, a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that lists the mode (testing or enforce), the allowed mail servers (mx), and a max_age. The DNS record tells senders a policy exists and when it last changed; the HTTPS file is the policy itself. If either is missing or the certificate on the mta-sts host is invalid, MTA-STS does not take effect.

Enter a domain and the tool looks up the _mta-sts TXT record, fetches the policy file from the mta-sts host over HTTPS, and reads your _smtp._tls TXT record for TLS-RPT. It then shows the enforcement mode, the mail servers your policy allows, the max_age, and whether reporting is configured — so you can confirm the whole setup resolves the way a sending server would see it.

In testing mode, a sending server that can't establish valid TLS still delivers the message, but (if TLS-RPT is set up) reports the failure to you. In enforce mode, that same server refuses to deliver until it can make an authenticated TLS connection to a listed MX. Always start in testing, watch your TLS-RPT reports until failures are explained, then switch to enforce. Going straight to enforce with a misconfigured MX list can bounce legitimate mail.

TLS-RPT (RFC 8460) is a companion TXT record at _smtp._tls.yourdomain.com that asks receivers to send you daily reports about TLS connection results — successes and failures. It's strongly recommended: those reports are how you find out whether your MTA-STS policy is causing problems before you move to enforce, and how you spot ongoing delivery issues afterward.

Both force TLS for inbound mail, but they anchor trust differently. DANE publishes certificate fingerprints in DNS and depends on DNSSEC being deployed on your domain. MTA-STS relies on the web PKI (a valid certificate on the mta-sts host) and does not require DNSSEC, which makes it much easier to adopt — that's why Google, Microsoft, and Yahoo support MTA-STS. Domains that already run DNSSEC often publish both.

The standard fixes the location: senders fetch https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. The mta-sts subdomain needs its own A/AAAA (or CNAME) record and a valid TLS certificate covering that hostname. A common failure is publishing the DNS TXT record but never standing up the mta-sts host, or letting its certificate expire — the checker above flags that case.

Yes. Palisade publishes the _mta-sts DNS record, hosts the policy file for you with a 100% uptime guarantee, keeps the id in sync when the policy changes, and helps you move from testing to enforce once your TLS-RPT reports are clean — across every domain you manage, alongside SPF, DKIM, DMARC, and BIMI.