Read the mail servers of your domain from MX, get the MTA-STS policy file, the _mta-sts record and the TLS reporting record in one pass, and see what your domain publishes today. Free, no sign-up.
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) tells sending mail servers that your domain only accepts mail over an encrypted connection with a valid certificate, and to which mail servers. Without it, encryption between mail servers is optional: an attacker on the path can remove the offer of TLS and read the mail in plain text, and the sender would not notice.
MTA-STS consists of a policy file on a web server and a TXT record that announces it. TLS-RPT (RFC 8460) adds a report address where senders tell you when they could not deliver securely. The generator writes all three.
1. Load your mail servers. Enter the domain and press “Load published record”. The generator reads the MX records and enters them as mx lines of the policy. Hosts of the same provider can be combined with a wildcard such as *.mail.protection.outlook.com.
2. Publish the policy file. It goes to https://mta-sts.example.com/.well-known/mta-sts.txt, served as plain text over HTTPS with a certificate valid for mta-sts.example.com. The subdomain needs an A or CNAME record to any web server that can host the file.
3. Publish the two TXT records. _mta-sts with v=STSv1; id=... announces the policy; _smtp._tls with v=TLSRPTv1; rua=mailto:... names the address for daily TLS reports.
4. Start in testing, then enforce. In testing mode senders report problems but still deliver. After two weeks of clean TLS reports, switch the file to mode: enforce and change the id in the TXT record so senders fetch the new version.
| Line | Meaning |
|---|---|
version: STSv1 |
Always this value. |
mode: testing |
testing reports only, enforce refuses insecure delivery, none withdraws a policy. |
mx: mx1.example.com |
One line per mail server that may receive mail. A wildcard covers exactly one label. |
max_age: 604800 |
Seconds a sender may cache the policy. At most 31557600, one year. |
Lines are separated by CRLF, which is how the downloaded file is written. The id in the TXT record is a free string up to 32 characters; the generator uses the current timestamp, so every new policy gets a new id automatically. Senders only fetch the file again when the id changes or max_age has expired.
*.example.com matches mx1.example.com but not mx1.eu.example.com.Of the 1,000 highest-ranked .de domains in the Tranco list (list 467YX, read on 19 October 2026), 924 receive mail. Only 63 publish an MTA-STS record and 62 a TLS-RPT record. More than nine out of ten German domains with a mail server therefore still accept a downgrade to unencrypted delivery without anyone noticing. MTA-STS is one of the few mail protections that costs one small file and two DNS records.
The mx lines have to match the host names in your MX records. For hosted mail the provider’s names are stable, so a wildcard keeps the policy valid when a host is added.
| Mail hosted at | mx lines in the policy |
|---|---|
| Microsoft 365 | mx: *.mail.protection.outlook.com |
| Google Workspace | mx: smtp.google.com for the current setup, or mx: aspmx.l.google.com plus mx: *.aspmx.l.google.com for the classic one |
| Your own server | exactly the names in your MX records, e.g. mx1.example.com |
Check the result against your real MX records before you switch to enforce. “Load published record” fills the field from MX, and once a policy is published, the check reports every MX host the policy does not cover. Remember that a wildcard covers one label only: *.aspmx.l.google.com matches alt1.aspmx.l.google.com, but not aspmx.l.google.com itself, which is why that host needs its own line.
The file needs nothing but HTTPS with a valid certificate for mta-sts. plus your domain. Common ways to provide that:
/.well-known/mta-sts.txt.Whatever you use, the file must be served with status 200, directly from mta-sts. plus your domain, without a redirect to another host. Senders follow no redirects, and a redirected policy counts as missing.
Yes, but a minimal one. Senders fetch a small text file over HTTPS from mta-sts.yourdomain. Any web host or static hosting service with a valid certificate for that name will do; the file never changes unless your mail servers do.
In testing, senders check the policy and report failures through TLS-RPT but still deliver. In enforce, they refuse to deliver over a connection without valid TLS to a listed mail server. Start with testing and switch after the reports are clean.
They solve the same problem in two ways. DANE needs DNSSEC and is used by many European providers; MTA-STS works without DNSSEC and is supported by Gmail and Microsoft. Publishing both is common and does no harm.
One JSON report per sender and day: how many connections were made, how many succeeded with valid TLS and the reason for each failure, such as an expired certificate or a host missing from the policy. They contain no message content.
Change the file to mode: none, give the TXT record a new id and keep both online at least for the max_age you published before. Deleting the records right away leaves senders enforcing the cached policy until it expires.
No. Policy and records are built in the browser. “Load published record” reads MX, _mta-sts and _smtp._tls of the domain and fetches the published policy file, like any sender would. Nothing of it is stored.
“Load published record” asks our resolver for the MX records, the TXT records at _mta-sts and _smtp._tls, and fetches the policy file from https://mta-sts. plus your domain. The validator of the Email Security Check then compares every mx line of a published policy with the real MX hosts, so a server the policy does not cover is reported before enforce would block it.
The generator itself works in the browser: it writes the policy from the mode, servers and cache time you choose, uses a timestamp as id and builds the TLS-RPT record from your report address. It cannot set up the web server or the certificate for the mta-sts subdomain, and it does not test whether your mail servers present valid certificates; the TLS reports will.