MTA-STS and TLS-RPT: enforcing TLS for incoming email

Why is STARTTLS not enough?

Mail servers encrypt SMTP with STARTTLS, but only opportunistically. The sending server asks the receiving server whether it supports TLS and falls back to plain text if the answer is no. It also accepts almost any certificate, because there has traditionally been no way to know which certificate to expect.

An attacker on the network path can remove the STARTTLS offer from the server's response, a so-called downgrade or stripping attack, and read the mail in clear text. An attacker who can tamper with DNS can also point your MX record to their own server. Without a policy, the sender has no reason to treat either case as an error.

What does MTA-STS do?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain publish a policy that says: deliver to these MX hosts only, only over TLS, and only if the certificate is valid for the MX hostname. Sending servers that support MTA-STS fetch the policy over HTTPS and cache it.

With the policy in enforce mode, a supporting sender will not deliver over plain text or to a server with an invalid certificate. It retries and later returns the message as undeliverable instead. Because the policy is fetched over HTTPS with a valid certificate, an attacker cannot forge it by tampering with DNS alone.

MTA-STS protects mail that others send to your domain. Whether your outgoing mail is protected depends on the receiving domains' policies.

How do I set up the _mta-sts DNS record and policy file?

MTA-STS has two parts. The first is a TXT record at _mta-sts on your domain. It tells senders that a policy exists and gives it an id:

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

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: mail.example.com
mx: *.mail.example.net
max_age: 604800

The second part is the policy file, served at https://mta-sts.example.com/.well-known/mta-sts.txt as text/plain. version is always STSv1. Each mx line names an MX host that may receive your mail, and a wildcard covers one label on the left. max_age is how long senders may cache the policy, in seconds, up to 31557600 (about one year). A week, 604800, is a common starting point.

The mta-sts host must have a valid, publicly trusted certificate for mta-sts.example.com, and it must answer without redirects. Every MX host must present a certificate that is valid for its MX hostname and chains to a trusted certificate authority. Self-signed or expired certificates fail validation in enforce mode.

Whenever you change the policy file, change the id in the TXT record as well. Senders only fetch the policy again when the id changes or their cached copy expires. A date and time is a practical id format. The id may be up to 32 letters and digits.

What is the difference between testing, enforce and none?

• mode: testing means senders check the policy and report failures through TLS-RPT, but still deliver the mail.
• mode: enforce means senders refuse to deliver if TLS or certificate validation fails, or if the MX host is not listed.
• mode: none tells senders to stop applying a policy they have cached. Use it when you want to remove MTA-STS, and keep it published until the old max_age has passed.

What is TLS-RPT and what do the reports show?

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a TXT record at _smtp._tls on your domain. It tells sending servers where to report the result of their TLS connections to you:

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

Senders that support TLS-RPT send a compressed JSON report, usually once per day. It shows the policy they applied, how many sessions succeeded, how many failed, and why. Failure types include certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure and sts-policy-fetch-error.

TLS-RPT is useful on its own, even without MTA-STS. It shows whether senders can reach your MX hosts over TLS and whether your certificates validate. DMARC Vision monitors TLS reports alongside DMARC reports.

How do I roll out MTA-STS safely?

1. Publish a TLS-RPT record and read the reports for a week or two. Fix any certificate or STARTTLS problems they reveal.
2. Set up the mta-sts host with a valid certificate, publish the policy file with mode: testing, and add the _mta-sts TXT record.
3. Watch the TLS-RPT reports for policy failures. Check that every MX host is listed in the policy and that its certificate matches.
4. When the reports show no unexpected failures, change the policy to mode: enforce and update the id.
5. Increase max_age once enforce has run without problems, and keep monitoring the reports. Remember to update the policy and id before you change MX hosts or mail providers.

How does MTA-STS relate to DANE?

DANE for SMTP (RFC 7672) solves the same problem a different way. It publishes TLSA records next to each MX host, which tell senders which certificate or key to expect. DANE requires DNSSEC on the zones that hold your MX hosts, and the sender must validate DNSSEC.

MTA-STS does not need DNSSEC and relies on the web certificate system instead. The two can be used together. A sender that supports both must not let MTA-STS override a failed DANE check.