Free MTA-STS checker
Inbound email transport that’s truly encrypted.
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.
- Free
- No account
- Instant result
- Public data only
Analyze a domain
How it works
- 1
Enter a domain
Enter the domain to analyze. No account, no proof of ownership: everything read is public.
- 2
Public data is read
The checker reads the “_mta-sts” and “_smtp._tls” records, then fetches the policy file published over HTTPS.
- 3
Instant verdict
The MTA-STS mode (enforce, testing or none) and whether TLS-RPT is present appear on screen. A free account then enables monitoring.
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.
Downgrade to cleartext
Without “enforce” mode, a network attacker can force an unencrypted SMTP delivery.
Interceptable transport
A cleartext connection exposes the content of inbound messages to reading or tampering.
Invisible TLS failures
Without TLS-RPT, no signal is reported when transport encryption fails.
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.
Worth remembering — Only “enforce” mode truly protects; “testing” merely observes. MTA-STS complements DMARC, it does not replace it.
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.
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.