Guide
MTA-STS and TLS reporting: publishing an encrypted-mail policy
Email between servers is encrypted only if both sides ask for it, and a sender that fails to negotiate TLS normally falls back to plain text. An attacker in the path can exploit that by stripping the encryption offer. MTA-STS lets a receiving domain announce that senders must use verified TLS to specific mail servers. The page generates the policy and the DNS records for it, and checks what a domain already publishes.
The three parts
First, a policy file, plain text served over HTTPS at https://mta-sts.example.com/.well-known/mta-sts.txt, from a host with a valid certificate. Second, a TXT record at _mta-sts.example.com such as v=STSv1; id=20261102183328, whose id tells senders whether their cached policy is out of date. Third, optionally, a TLS-RPT record at _smtp._tls.example.com, for example v=TLSRPTv1; rua=mailto:[email protected], which asks senders to send daily reports of TLS failures. Both standards are published as RFCs: 8461 for MTA-STS and 8460 for TLS-RPT.
The policy file
It has four kinds of line. version: STSv1. mode: set to testing, enforce or none. One or more mx: lines naming the mail servers that are valid for the domain, where a leading wildcard such as *.example.com is permitted. And max_age: in seconds. The file must be served with lines ending in CRLF, which the page notes. In testing mode senders apply the policy for reporting but still deliver when it fails; in enforce they refuse; none switches the policy off cleanly.
Using the page
On the first tab, enter the mail domain, choose the mode, set max_age, list your MX host names one per line and optionally a reporting address. The page shows the policy URL, the exact file text with a copy and download button, and the DNS records, with an id built from the current time. Whenever you change the policy file, change the id too; senders only fetch a new copy when the id in DNS changes. The second tab, “Check a domain”, reads what a domain publishes in DNS and flags problems in the id, version and reporting record.
A worked example
For example.com with the MX host mail.example.com, mode testing and the default lifetime, the page produces the file version: STSv1, mode: testing, mx: mail.example.com, max_age: 86400. The records are _mta-sts.example.com. IN TXT "v=STSv1; id=…", an address record for mta-sts.example.com pointing to the web server that serves the file, and _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]". The id is a timestamp, so it is different each time you generate.
Limits
The page writes text; you still have to host the file over HTTPS with a valid certificate on the mta-sts host. Browsers cannot read another site’s policy file because of cross-origin rules, so the checker reads the DNS records only and cannot confirm that the file is reachable or correct. Start in testing mode, read the reports for a few weeks, and only then switch to enforce. Compare with the Email Spoofing Test, which rates the presence of these records.
Related tools
- MX Lookup shows the mail servers your policy should list.
- Email Spoofing Test includes MTA-STS and TLS-RPT in its score.
- DMARC Checker covers the sender-authentication side of email security.
- TXT Record Lookup shows the raw records you publish.
Checked against the current version of the MTA-STS Generator on .