MTA-STS and TLS-RPT: enforcing encrypted delivery to your domain

The problem: STARTTLS can be stripped

When one mail server delivers to another, it connects in plain text and asks to upgrade the connection with STARTTLS - but only if the receiver offers it. If the offer is missing, or the certificate is invalid, most senders deliver anyway, unencrypted. That keeps mail flowing between badly configured servers, but it also means an attacker who can tamper with the connection can simply delete the STARTTLS line from the receiver's reply, or point the sender at a server of their own (for example by forging the MX answer), and read every message. The sender never notices.

SPF, DKIM and DMARC don't help here: they authenticate the sender of a message. MTA-STS protects the transport of mail coming to your domain.

How MTA-STS works

You publish two things. A small TXT record announces that your domain has a policy; the policy itself is a text file on a web server, fetched over HTTPS. The HTTPS part is the point: the certificate on the policy host proves the policy really comes from you, without needing DNSSEC.

1. Before delivering to your domain, a sender that supports MTA-STS looks up _mta-sts.example.com.
2. If the record exists and it has no current copy of the policy, it downloads https://mta-sts.example.com/.well-known/mta-sts.txt and caches it for max_age seconds.
3. It then only delivers to MX hosts that match the policy's mx: lines, over TLS, with a certificate that is valid for the MX hostname. In enforce mode, if any of that fails, it doesn't deliver to that host at all.

Step 1: the policy file

The policy is served at a fixed address: the host mta-sts. plus your domain, path /.well-known/mta-sts.txt. It is a plain-text file of key: value lines:

version: STSv1
mode: testing
mx: mx1.mailprovider.example
mx: mx2.mailprovider.example
max_age: 604800

The web server has to meet a few strict requirements, and each one is a common reason the policy is ignored:

• The certificate must be valid for mta-sts.example.com itself and issued by a publicly trusted authority - a certificate only for example.com or www doesn't count.
• The file must be answered with HTTP 200 directly. Senders must not follow redirects, so a redirect from mta-sts.example.com to your main website breaks it.
• Serve it as text/plain; senders are told to check the media type. The RFC specifies CRLF line endings.

Step 2: the TXT record

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261026"

The id is a version label of 1 to 32 letters and digits. Senders compare it with the id of the policy they cached: if it changed, they fetch the policy again. Change it every time you change the policy file - a date or timestamp is the usual choice - and update the file first, the record second, so nobody fetches the old file under the new id. Don't forget the web side either: mta-sts.example.com needs its own A/AAAA (or CNAME) record pointing at the server that hosts the file.

The MX hosts must have valid certificates

This is the part that's easy to overlook. Under an enforced policy, a sender refuses to deliver to an MX host whose certificate is expired, self-signed or issued for a different name. Before you switch to enforce, make sure every host in your MX records presents a publicly trusted certificate covering its own hostname, and that each one is listed in the policy's mx: lines. If your mail is hosted, that's a question for your provider: an enforced policy pointing at a provider whose MX certificate doesn't match would stop your incoming mail from MTA-STS-aware senders.

Modes: testing, enforce and none

A safe rollout

1. Set up TLS-RPT first (next section), so failures are reported to you.
2. Publish the policy in testing mode with a short max_age, such as one day (86400), so mistakes don't linger in caches.
3. Read the TLS reports for a couple of weeks and fix anything they show.
4. Switch to enforce, raise max_age to weeks or more (RFC 8461 expects values "in the range of weeks or greater"; 1209600 is two weeks), and change the id.

The long max_age matters for security. A sender is only protected once it has your policy cached, and the moment it fetches the policy is the moment an attacker could block it. The longer the cache lives, the fewer such moments there are.

Turning it off again

Don't just delete the record and the file: senders would keep applying the cached policy until it expires. RFC 8461 (section 8.3) suggests publishing a policy with mode: none and a short max_age, changing the id, waiting until every previously served policy has expired, and only then removing both.

Changing mail providers

Under an enforced policy, add the new provider's MX hosts to the mx: lines (and change the id) before you change the MX records - otherwise senders with the old policy cached will refuse to deliver to the new servers. Remove the old hosts once the move is complete. See the MX record guide for the rest of the switch.

TLS-RPT: reports about encrypted delivery

SMTP TLS Reporting (RFC 8460) is a companion standard: you publish an address, and senders that support it send you a daily report of their connections to your domain - how many TLS sessions succeeded, and which failed and why. It covers MTA-STS and DANE failures as well as basic STARTTLS problems, and it works as a heartbeat when everything is fine.

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

• rua accepts mailto: addresses and https: URLs; several can be listed, separated by commas.
• Reports are JSON, usually gzip-compressed, and normally cover one UTC day. They are written for software, so a mailbox you never open isn't much use - forward them to a tool that parses them, or at least check them during a rollout.
• Failure types you will see include starttls-not-supported, certificate-expired, certificate-host-mismatch, validation-failure and, for MTA-STS, sts-policy-fetch-error.
• TLS-RPT only describes mail sent to you, so you can publish it whichever provider hosts your mail - the reports come to the address you choose.

DANE as an alternative

DANE for SMTP (RFC 7672) solves the same problem differently: instead of an HTTPS policy, you publish a TLSA record with the fingerprint of the MX server's key, at a name such as _25._tcp.mx.example.com. The record is trusted because it is signed with DNSSEC, so DANE requires DNSSEC on your domain and on the zone of each MX host. Where DNSSEC is available, DANE avoids the first-fetch weakness of MTA-STS; where it isn't, MTA-STS was designed precisely so you don't need it. The two can coexist - a sender that supports both must not let MTA-STS override a failed DANE check. With a hosted provider, DANE is only possible if the provider publishes TLSA records for its own MX hosts.

MTA-STS with AnyMail

AnyMail doesn't host MTA-STS policy files for customer domains, so there is no MTA-STS step on the DNS setup page. TLS-RPT, on the other hand, you can publish at any time - it's just a TXT record pointing at an address of your choice. The email authentication checker reports whether a domain has MTA-STS and TLS-RPT records, which mode its policy is in, and whether the policy's mx: lines cover the domain's MX hosts; these results are informational and don't affect the grade.