MTA-STS and TLS-RPT explained: policy, mode and MX

SMTP between mail servers can use TLS through STARTTLS, but by default it is opportunistic: if the encryption cannot be set up, mail is sent anyway, and certificates are rarely checked. MTA-STS, defined in RFC 8461, lets a receiving domain declare that its MX hosts support TLS with valid certificates. TLS-RPT, defined in RFC 8460, lets the same domain ask senders for reports about TLS problems they run into.

The two parts of MTA-STS

MTA-STS has a DNS record and a policy file.

The DNS record is a TXT record at _mta-sts.<domain>, for example:

_mta-sts.example.com.  TXT  "v=STSv1; id=20261025T120000;"

v=STSv1 must come first. id is 1 to 32 letters and digits that identify the current version of the policy. Senders compare it with the id of the policy they have cached; when it changes, they fetch the policy again. The record does not contain the policy itself.

If the record is missing, MTA-STS is simply not in use (MTASTS_NOT_FOUND). If there is more than one record that starts with v=STSv1, senders treat the domain as having no policy (MTASTS_MULTIPLE_RECORDS). A record with the wrong syntax, such as a missing id or an id with other characters, is reported as MTASTS_INVALID_RECORD.

The policy file

The policy is served at a fixed URL:

https://mta-sts.example.com/.well-known/mta-sts.txt

It is a short text file of key: value lines:

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

• version must be STSv1.
• mode is enforce, testing or none.
• mx appears once for each allowed MX host. A pattern may start with *., which matches exactly one label: *.example.net matches mx1.example.net but not a.b.example.net or example.net itself.
• max_age is the number of seconds a sender may cache the policy, at most 31557600 (about one year).

The HTTPS fetch has its own rules in RFC 8461 section 3.3. The certificate for mta-sts.<domain> must be valid for that name and chain to a trusted root. The response must be status 200 with a text/plain media type. Senders must not follow HTTP redirects. ProbeKit fetches the file with the same rules and reads at most 64 KB. When the fetch fails for any of these reasons, the check reports MTASTS_POLICY_UNAVAILABLE with the reason in the evidence, such as a certificate error, a timeout, a redirect, a wrong status or content type, or a file that is too large. A file that arrives but does not parse is MTASTS_INVALID_POLICY.

Modes

enforce tells senders to deliver only to MX hosts that match the policy and that offer TLS with a valid certificate for the host name. If that is not possible, the message is not delivered to that host.

testing tells senders to apply the same checks but deliver the message anyway, and to report failures through TLS-RPT. It is the safe way to start (MTASTS_MODE_TESTING).

none means the domain has no active policy. It exists mainly so a domain can withdraw a policy: senders that still have the old one cached replace it with none the next time they fetch (MTASTS_MODE_NONE).

The policy must cover your MX hosts

Under enforce, a sender only delivers to MX hosts that match one of the mx lines. An MX host that is missing from the policy will not receive mail from senders that apply MTA-STS. This happens easily after a provider change or when a backup MX is added. The check compares each MX host of the domain with the patterns and reports hosts that match none of them, as an error under enforce (MTASTS_MX_NOT_COVERED) and as a warning under testing (MTASTS_MX_NOT_COVERED_TESTING).

Choosing max_age

A long max_age is what gives MTA-STS its protection: a sender that has fetched the policy once keeps it, even if an attacker later blocks the HTTPS fetch or the DNS record. RFC 8461 suggests values of weeks or more. A very short value means the cached policy runs out quickly and gives little protection, so the check warns when max_age is below one day (MTASTS_LOW_MAX_AGE).

The flip side is that a mistake in an enforce policy also stays cached. Change the id in the TXT record whenever you change the policy file, so senders fetch the new version.

TLS-RPT

TLS-RPT is a TXT record at _smtp._tls.<domain>:

_smtp._tls.example.com.  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

v=TLSRPTv1 comes first. rua lists one or more report destinations separated by commas, each a mailto: or an https: URI. Senders that support TLS-RPT send a daily aggregate report in JSON with the number of successful TLS sessions and the failures they saw, for example certificate errors, a missing STARTTLS or a policy that could not be fetched.

TLS-RPT is independent of MTA-STS, but the two belong together. Without reports you do not see when senders fail to deliver because of your policy. A missing record is reported as TLSRPT_NOT_FOUND. If there are several records with v=TLSRPTv1, RFC 8460 says senders must assume TLS-RPT is not implemented; that and other syntax problems are reported as TLSRPT_INVALID.

A safe rollout

1. Publish a TLS-RPT record so reports start arriving.
2. Put a policy with mode: testing, all your MX hosts and a moderate max_age on https://mta-sts.<domain>/.well-known/mta-sts.txt.
3. Publish the _mta-sts TXT record with a new id.
4. Read the reports for a few weeks. Fix certificates and add missing MX hosts.
5. Change the mode to enforce, raise max_age, and change the id again.

Common mistakes

• The mta-sts host serves a certificate for a different name, or redirects to another URL.
• The web server returns text/html or a login page instead of the policy.
• A new MX host is added without updating the mx lines.
• The policy file is changed but the id in the TXT record is not.
• Two _mta-sts records are left behind after a change.

Use the MTA-STS and TLS-RPT check to read both records, fetch the policy and compare it with your MX hosts, or the domain health check to see it next to SPF, DMARC, DKIM and DNSSEC. The MX records themselves are explained in MX records explained.