What is the difference between mode enforce, testing and none?

enforce = senders must use TLS with a valid certificate, otherwise no delivery. testing = violations are only reported via TLS-RPT, delivery happens anyway. none = policy disabled, a signal to senders to forget it.

How do I set up MTA-STS?

Set up the mta-sts subdomain with a valid HTTPS certificate and provide the file at /.well-known/mta-sts.txt (version, mode, mx, max_age). Then set the TXT record _mta-sts with v=STSv1 and an id value. Start with mode: testing plus TLS-RPT, switch to enforce after error-free observation.

My mta-sts.txt is not reachable, what causes that?

Common causes: the subdomain has no certificate of its own, it redirects to HTTP or to the main domain, the path is not exact, or the Content-Type is not text/plain. RFC 8461 requires HTTPS without redirects at exactly this path.

What is the mx comparison for?

Every MX host of the domain must match at least one mx: pattern of the policy. If an MX matches no pattern, delivery there fails with enforce.

Do I need MTA-STS if I already have DANE?

Not necessarily, both enforce TLS. DANE requires DNSSEC, MTA-STS the Web PKI. Publishing both reaches senders with DNSSEC validation as well as those without. No contradiction arises.

What does the TLS-RPT record give me?

Through _smtp._tls the domain publishes a rua address to which sending servers send daily reports about successful and failed TLS deliveries. Without it you only notice MTA-STS or STARTTLS problems when mail stops arriving.

MTA-STS and TLS-RPT Check

Check the MTA-STS record and HTTPS policy, MX comparison, certificate, TLS-RPT.

MTA-STS makes sure that sending mail servers reach a domain only over TLS with a valid certificate and cannot be downgraded to an unencrypted connection by a man in the middle. SMTP knows transport encryption only as an option (STARTTLS); MTA-STS makes it mandatory for a domain and closes the downgrade gap. TLS-RPT is the matching reporting channel over which sending servers report when a TLS delivery fails.

What this tool checks

MTA-STS consists of two parts. This tool fetches the TXT record at _mta-sts.<domain> (version and id) and the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. It checks the syntax of the policy (version, mode, max_age, mx), compares every mx: pattern against the domain's actual MX records and shows the issuer and remaining validity of the certificate of the mta-sts subdomain. The HTTPS fetch goes through an SSRF guard, only https, no redirects. In addition, the TLS-RPT record at _smtp._tls.<domain> is read and its rua targets are checked.

Reading the result

Green means: TXT record and policy present and syntactically clean, mode: enforce, a trusted certificate and every MX covered by an mx: pattern. mode: testing is a warning: useful for the introduction, but with no protective effect. An error stands for an unreachable or invalid policy where the TXT record exists, for an expired or untrusted certificate of the mta-sts subdomain, or for an MX that no pattern covers. If TLS-RPT is missing, that is only a note.

Background

MTA-STS is defined in RFC 8461, TLS-RPT in RFC 8460. RFC 8461 requires HTTPS with a valid, publicly trusted certificate for mta-sts.<domain> for the policy and forbids following HTTP redirects. A policy change is signalled through a new id value in the TXT record, otherwise senders use the cached version until max_age expires. MTA-STS and DANE (RFC 7672) pursue the same goal through different trust anchors (Web PKI versus DNSSEC) and do not exclude each other.

Common problems and how to fix them

TXT record present, policy not reachable. The mta-sts subdomain needs a reachable HTTPS endpoint with a valid certificate and the file at the exact path /.well-known/mta-sts.txt, served as text/plain. No HTTP, no redirect to the main domain.
Stuck at mode: testing. Testing only reports, it enforces nothing. Once the TLS-RPT reports show no more failed attempts, switch to enforce and change the id value in the TXT record.
MX not covered by an mx: pattern. With enforce, conforming senders refuse delivery to that host. Extend the policy so that every current MX host name matches, wildcards such as *.example.net are allowed.
Policy changed, senders use the old one. The id in the TXT record must change with every policy change, otherwise the cache holds until max_age (often a week or more).
Certificate of the mta-sts subdomain expired. That makes the policy invalid for senders and the protection drops out. Include the certificate in the automatic renewal like any other.

More background in the blog article MTA-STS (Strict Transport Security) on frankysweb.de (in German).

Common questions

What is the difference between mode enforce, testing and none?: enforce = senders must use TLS with a valid certificate, otherwise no delivery. testing = violations are only reported via TLS-RPT, delivery happens anyway. none = policy disabled, a signal to senders to forget it.
How do I set up MTA-STS?: Set up the mta-sts subdomain with a valid HTTPS certificate and provide the file at /.well-known/mta-sts.txt (version, mode, mx, max_age). Then set the TXT record _mta-sts with v=STSv1 and an id value. Start with mode: testing plus TLS-RPT, switch to enforce after error-free observation.
My mta-sts.txt is not reachable, what causes that?: Common causes: the subdomain has no certificate of its own, it redirects to HTTP or to the main domain, the path is not exact, or the Content-Type is not text/plain. RFC 8461 requires HTTPS without redirects at exactly this path.
What is the mx comparison for?: Every MX host of the domain must match at least one mx: pattern of the policy. If an MX matches no pattern, delivery there fails with enforce.
Do I need MTA-STS if I already have DANE?: Not necessarily, both enforce TLS. DANE requires DNSSEC, MTA-STS the Web PKI. Publishing both reaches senders with DNSSEC validation as well as those without. No contradiction arises.
What does the TLS-RPT record give me?: Through _smtp._tls the domain publishes a rua address to which sending servers send daily reports about successful and failed TLS deliveries. Without it you only notice MTA-STS or STARTTLS problems when mail stops arriving.