Free MTA-STS checker
MTA-STS protects inbound email against TLS downgrade; TLS-RPT reports failures. This checker reads the DNS record, fetches the published policy and gives its mode.
MTA-STS and TLS-RPT
MTA-STS (RFC 8461) enforces TLS encryption on inbound SMTP connections — it stops an attacker from forcing a cleartext connection. It is declared with a DNS record “_mta-sts.domain” and a policy published at “mta-sts.domain/.well-known/mta-sts.txt”, whose mode is “enforce” (applied), “testing” (observed) or “none” (disabled). TLS-RPT (RFC 8460), declared at “_smtp._tls.domain”, reports the TLS failures observed by senders.
How the checker works
The checker reads the public DNS records “_mta-sts” and “_smtp._tls”, then fetches the MTA-STS policy file published over HTTPS (redirects refused, body bounded). It reads only public, standardized data — the policy file is meant to be fetched by any sending server. The result gives the MTA-STS mode and whether TLS-RPT reporting is present.
Why it matters
DMARC protects against sender spoofing; MTA-STS and TLS-RPT protect the transport. Without MTA-STS in “enforce” mode, a network attacker can force cleartext delivery and read or alter messages. Publishing an “enforce” policy and enabling TLS-RPT completes the email posture beyond authentication.
Frequently asked questions
- Does the analysis pose any risk to the domain?
- No. The checker reads only public data: two DNS records and a standardized policy file meant to be fetched by any sending server. Nothing is changed.
- What's the difference between “testing” and “enforce”?
- In “testing” mode, a connection that fails TLS is still accepted (the policy is only observed, with reporting via TLS-RPT). In “enforce” mode, a non-compliant connection is refused — that's the mode that actually protects.
- Does MTA-STS replace DMARC?
- No, they are complementary. DMARC protects against sender-domain spoofing; MTA-STS protects the encryption of inbound message transport. A healthy posture combines both.