MTA-STS + TLS-RPT Checker

Verify your MTA-STS policy and TLS-RPT reporting configuration to prevent email downgrade attacks.

What is MTA-STS?

MTA Strict Transport Security (MTA-STS) allows domain owners to declare that email sent to them must use TLS encryption. Without it, attackers can perform downgrade attacks to intercept email in transit.

What is TLS-RPT?

TLS Reporting (TLS-RPT) lets mail servers send you reports when they fail to establish a TLS connection to your domain, giving you visibility into delivery issues.

What this MTA-STS checker tests

MTA-STS (RFC 8461) lets a domain publish a policy saying that mail servers delivering to it must use TLS with a valid certificate. The checker runs the same discovery steps a sending server would, in this order:

Looks up the TXT record at _mta-sts.yourdomain.com and looks for v=STSv1. If it is missing, the check stops with a fail.
Looks up the TLS-RPT TXT record at _smtp._tls.yourdomain.com and looks for v=TLSRPTv1 with a mailto: or https: reporting address.
Fetches https://mta-sts.yourdomain.com/.well-known/mta-sts.txt with a five second timeout. A non-200 answer, a TLS error or a timeout is reported as unreachable.
Parses the policy file for mode, mx and max_age.
Looks up your real MX records and compares them with the mx lines in the policy.

It does not open SMTP connections to your mail servers, so it cannot tell you whether your MX hosts actually present a valid certificate.

How to read each result field

DNS record: the _mta-sts TXT value, for example v=STSv1; id=20261005120000. The id is only a change marker.
Policy reachable: whether the policy file came back with a success status over HTTPS.
Mode: enforce, testing or none, from the policy file.
MX entries and MX match: the mx lines in the policy and whether each one is covered by a real MX record for your domain.
Max age: how many seconds sending servers may cache the policy.
TLS-RPT record: the _smtp._tls value, and whether it contains a usable reporting address.

How the verdict is decided

Situation	Verdict
No _mta-sts TXT record	Fail
TXT record present but policy file unreachable	Warn
mode: none	Fail (no protection is active)
mode: testing	Warn (failures are reported but mail is still delivered)
mode: enforce with MX entries matching real MX records	Pass
mode: enforce but an mx line does not match a real MX host	Warn
Policy fine but no valid TLS-RPT record	Warn (a would-be pass is downgraded)

MTA-STS policy and record reference

A complete working example

_mta-sts.example.com.   TXT  "v=STSv1; id=20261005120000"
_smtp._tls.example.com. TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com
max_age: 604800

Item	Where	Values and rules
v	_mta-sts TXT	Must be STSv1.
id	_mta-sts TXT	Up to 32 letters and digits. Change it whenever the policy file changes so senders refetch.
version	Policy file	STSv1.
mode	Policy file	enforce: refuse delivery if TLS or certificate validation fails. testing: deliver anyway, but report failures through TLS-RPT. none: policy is withdrawn.
mx	Policy file	One line per allowed MX host. A leading wildcard such as *.mail.protection.outlook.com is allowed. Use the host names, not IP addresses.
max_age	Policy file	Cache lifetime in seconds. RFC 8461 caps it at 31557600 (about one year). Common production values are 604800 (one week) to 2592000 (30 days).
v, rua	_smtp._tls TXT (TLS-RPT, RFC 8460)	v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com or an https: endpoint.

Common errors and fixes

What you see	Likely cause	Fix
No MTA-STS record found	TXT published at mta-sts.example.com instead of _mta-sts.example.com, or v=STSv1 misspelled	Move it to the underscored name.
Policy file unreachable	No mta-sts host name in DNS, certificate does not cover mta-sts.example.com, or the file path is wrong	Create the host, make sure it has a valid certificate for exactly that name, and serve /.well-known/mta-sts.txt.
Policy unreachable although the page loads in a browser	The host redirects to another URL. RFC 8461 says senders must not follow redirects.	Serve the file directly with HTTP 200 on that exact URL.
MX entries do not match	Policy lists an old provider or a single host while DNS has more	List every MX host, using wildcards where the provider documents them.
Still shows testing	Policy was never changed to enforce, or an old copy is cached	Edit the file, then update the id in the TXT record.
TLS-RPT warning	No _smtp._tls record	Add v=TLSRPTv1; rua=mailto:tlsrpt@example.com.

Safe rollout: testing, then enforce

Publish the policy with mode: testing and a short max_age such as 86400, plus the TLS-RPT record.
Wait one to two weeks and read the TLS reports that arrive. They are JSON files, usually gzipped, sent by large providers.
Fix any reported certificate, STARTTLS or MX name problems on your mail servers.
Switch the policy file to mode: enforce, raise max_age to a week or more, and change the id in DNS.
Re-run this checker and confirm it passes. To retire MTA-STS later, publish mode: none for at least the old max_age before removing the records.

What this checker does not do

It does not connect to your MX servers to confirm STARTTLS or a valid certificate. Enforce mode will cause real mail to be refused if that is broken.
It does not follow the RFC rules for redirects or content type, so a policy served with the wrong Content-Type may pass here but be rejected by some senders. Serve it as text/plain.
MX matching is lenient. A wildcard is matched against any depth of host name, where RFC 8461 expects a single label in the wildcard position.
An unrecognised mode value is not flagged. Check the mode line yourself.
It does not read the id or evaluate max_age beyond showing it, and it only sees what public resolvers return right now.
MTA-STS protects inbound mail only, and only from senders that implement it.

Related tools and guides

MTA-STS policy generator

Create the policy file and TXT record.

Email security score

See MTA-STS alongside SPF, DKIM and DMARC.

SPF, DKIM and DMARC explained

The authentication basics that sit beside MTA-STS.

Email deliverability checklist

Wider checks for mail flow and reputation.

Frequently Asked Questions

What is MTA-STS?

MTA-STS (Mail Transfer Agent Strict Transport Security) is a security standard that requires sending mail servers to use encrypted TLS connections when delivering email to your domain. Without MTA-STS, email in transit between servers can be intercepted or downgraded to an unencrypted connection through a man-in-the-middle attack. MTA-STS works alongside DMARC, SPF, and DKIM to protect both sending and receiving of email.

What does this MTA-STS checker verify?

This tool checks: the presence and correct syntax of the _mta-sts DNS TXT record; whether your policy file at https://mta-sts.[yourdomain]/.well-known/mta-sts.txt is reachable and correctly formatted; whether the MX hosts listed in your policy match your actual MX records; and whether TLS-RPT reporting is configured at _smtp._tls.[yourdomain] so you receive alerts about TLS delivery failures.

What is TLS-RPT and do I need it?

TLS-RPT (TLS Reporting) is a complementary standard that sends you daily reports about TLS encryption failures when other mail servers try to deliver to your domain. It helps you detect misconfigurations and potential attacks. While not strictly required, it is best practice to configure TLS-RPT alongside MTA-STS — the reporting URI is added as a simple DNS TXT record at _smtp._tls.[yourdomain].

What are the MTA-STS policy modes?

MTA-STS has two policy modes: testing mode sends TLS-RPT failure reports but does not enforce TLS — mail still delivers even if TLS negotiation fails. Enforce mode requires TLS for all inbound delivery — mail is rejected if a TLS connection cannot be established. Move to enforce mode once you have confirmed your MX hosts support TLS and reviewed TLS-RPT reports for any issues.

Is MTA-STS required for DMARC compliance?

MTA-STS is separate from DMARC compliance. DMARC, SPF, and DKIM protect against domain spoofing in the From: header of outgoing email. MTA-STS protects the transit layer — preventing interception during delivery to your inbox. Both are recommended as part of a complete email security posture. Our Email Security Score includes MTA-STS as one of its five weighted checks.