MTA-STS · RFC 8461 — TLS-RPT · RFC 8460

MTA-STS and TLS-RPT: is TLS required, and who hears when it fails

Type a domain to read the record that announces its MTA-STS policy and the record that says where senders report TLS failures. Both are explained; the policy file itself is not fetched.

Check a domain All seven records at once The email doctor grades them

The MTA-STS and TLS-RPT check

MTA-STS

_mta-sts.<domain> · TXT

Not checked yet

Whether an MTA-STS policy is announced, its version id, and whether the policy host exists.

TLS-RPT

_smtp._tls.<domain> · TXT

Not checked yet

Where the domain asks senders to report deliveries that failed over TLS.

What MTA-STS is

Mail between servers is encrypted only when both sides agree to it at the moment of delivery, and an attacker in the path can remove the offer. MTA-STS lets a domain declare that its mail hosts support TLS with a certificate senders can verify, and tell senders what to do when that fails (RFC 8461). It has two parts: a TXT record at _mta-sts.<domain> that announces the policy, and the policy itself, a small text file served over HTTPS.

_mta-sts.example.com. IN TXT "v=STSv1; id=20160831085700Z;"

The example record of RFC 8461 §3.1.

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.net
mx: backupmx.example.com
max_age: 604800

The example policy of RFC 8461 §3.2, served at https://mta-sts.example.com/.well-known/mta-sts.txt.

How to read the record

v=STSv1 is the version and must come first.
id= is 1 to 32 letters and digits that identify this version of the policy. Senders compare it with the id they have cached and fetch the policy again only when it changed, so the id has to change every time the policy file does (RFC 8461 §3.1).
If the number of records that begin with v=STSv1 is not exactly one, senders act as if the domain had no policy.

How to read the policy file

mode is one of three. With enforce, senders must not deliver to a host that fails the check. With testing, they deliver anyway and report the failure. With none, they treat the domain as having no policy (RFC 8461 §5). mx lists the mail hosts that may receive the domain's mail, and max_age is the lifetime of the policy in seconds, at most 31557600.

The checker reads the TXT record and looks up whether the policy host mta-sts.<domain> has an address. It does not fetch the file, because that would send the domain you typed somewhere other than the two DNS operators. The card gives the address of the file so that you can open it yourself.

TLS-RPT: the reports

TLS-RPT is the companion record. A TXT record at _smtp._tls.<domain> that begins with v=TLSRPTv1 gives senders an address, mailto: or https:, to which they report deliveries that failed over TLS (RFC 8460 §3). Without it a domain in enforce mode does not learn that a sender could not deliver.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=mailto:reports@example.com"

The example record of RFC 8460 §3.1.1.

The common mistakes

The policy changed, the id did not. Senders that hold the old policy in their cache keep using it.
An id with punctuation. Only letters and digits are allowed; a date written with hyphens is not valid.
No policy host. The record is published and mta-sts.<domain> does not exist. Senders that have no cached policy then deliver as if MTA-STS were not there (RFC 8461 §3.3).
A redirect on the policy URL. Senders must not follow HTTP redirects when they fetch a policy (RFC 8461 §3.3).
Expecting subdomains to inherit. A policy covers its own domain only: for mail to user@mail.example.com senders look at mail.example.com, never at example.com (RFC 8461 §3.4).
A wildcard TXT record in the zone. It answers for _mta-sts and _smtp._tls too. Records that do not begin with the right version are discarded, and the checker says when it has discarded some.

Method, sources and privacy

How this page reads the record.

Where the answers come from

Each question goes from your browser to two public DNS-over-HTTPS resolvers: Google Public DNS, at https://dns.google/resolve, and Cloudflare, at https://cloudflare-dns.com/dns-query, asked with Accept: application/dns-json. Both answer live, at the moment you ask, from their own caches: a record changed a moment ago can still be served in its old form until its time to live runs out (RFC 2181 §8). The answers are compared. When they differ both are shown; when one does not answer within 8 seconds the page names it; when neither answers, the card says so and concludes nothing. The panel This run dates the reading to the second, in UTC.

What is computed here

Everything else happens in your browser: each record is selected by its version tag, the policy id is checked, and the policy host mta-sts.<domain> is looked up for an address; the policy file itself is not fetched (the email doctor, on our server, does fetch it). Every finding links to the section of the document it rests on. The documents this page was written against are listed here, each with the date it was read; all seventeen are on the method page.

What happens to what you type

The domain goes to those two resolvers and to no one else: not to labs.llc's server, not into the page address, not into your browser's storage, and not to analytics, whose tag records this page's address, which never holds it. Of an email address only the part after the @ is used; the rest is dropped in your browser. The two resolvers see the question and the Origin header of labs.llc, and handle it under their own policies (Google Public DNS, Cloudflare). Changing the edition, paper or dark, reloads the page as it does everywhere on labs.llc, and clears the reading on screen: nothing of it is kept to bring back.