How to Use the MTA-STS and TLS-RPT Checker
Enter one domain and the checker runs the DNS lookups and the policy fetch together, usually within a few seconds.
- Enter the domain that receives the mail, such as example.com, without https:// or an address.
- Select Check MTA-STS to look up the TXT and MX records and fetch the policy file.
- Read each row: red items stop senders from applying the policy, amber items weaken it.
- If something is missing, copy the starter records, publish them and run the check again once the DNS change is live.
What the MTA-STS Check Covers
An MTA-STS check confirms three things: the TXT record that announces the policy, the policy file itself, and the match between the policy and the domain’s MX hosts.
MTA-STS Record
The checker reads the TXT record at _mta-sts.<domain> and requires exactly one that starts with v=STSv1 and carries an id of 1 to 32 letters or digits. Senders compare that id with their cached copy and fetch the policy again when it changes. When no MTA-STS TXT record is found, senders never look for a policy at all.
MTA-STS Policy File
The policy file must be served as text/plain at https://mta-sts.<domain>/.well-known/mta-sts.txt, with a valid certificate and no redirect. The checker fetches it through a small proxy on this site, limited to 5 seconds and 1 MB, and validates version, mode, mx and max_age. A host that cannot be reached is reported as unknown, while an HTTP error, a redirect or a wrong content type counts as a real fault.
Multiple MX Hosts and Wildcards
Every MX host of the domain must match one mx line of the policy, or senders in enforce mode refuse to deliver to it. A wildcard such as *.mail.example.com covers exactly one extra label, so it matches mx1.mail.example.com but not mail.example.com itself. The result table lists each MX host with the pattern it matched.
TLS-RPT Record
The TLS-RPT record at _smtp._tls.<domain> starts with v=TLSRPTv1 and lists rua addresses that receive daily reports about failed TLS connections. Each address must use mailto: or https:. The record is optional, but its reports are the only way to see failures before you switch MTA-STS to enforce.
MTA-STS Testing vs Enforce Mode
Testing mode only reports TLS failures, while enforce mode makes senders refuse delivery over a connection that fails validation.
| Mode | What senders do | When to use it |
|---|---|---|
| testing | Deliver even when TLS fails, then report the failure through TLS-RPT | The first weeks, while reports reveal missing MX hosts or certificate errors |
| enforce | Refuse to deliver unless the MX host matches the policy and presents a valid certificate | Once the TLS-RPT reports show no failures |
| none | Stop applying MTA-STS and drop the cached policy | Before removing MTA-STS from the domain |
Frequently Asked Questions
What Is MTA-STS?
MTA-STS (RFC 8461) lets a domain tell sending mail servers that its MX hosts accept TLS with a valid certificate. Senders that support it refuse to fall back to an unencrypted connection, which blocks downgrade and interception attacks on mail in transit.
What Does TLS-RPT Do?
TLS-RPT (RFC 8460) asks sending servers to deliver a daily JSON summary of their TLS connections to your MX hosts, failures included. The reports reveal certificate problems and MX hosts missing from the MTA-STS policy before they cost you mail.
Is MTA-STS Necessary?
No standard requires it, and mail still flows without it. It is worth adding when you want encrypted delivery protected against downgrade attacks, because large mailbox providers apply it when they send to your domain.
How Do You Configure MTA-STS?
Serve the policy file over HTTPS on the mta-sts subdomain, publish the _mta-sts TXT record with a new id, and add a TLS-RPT record. Start in testing mode, then switch to enforce and change the id after a few weeks of clean reports. This checker offers starter versions of the missing records.
Related Email Tools
Continue with the guide What Is DMARC. Policies, alignment and reports explained.