MTA-STS & TLS-RPT

What MTA-STS does

SMTP between mail servers upgrades to TLS with STARTTLS, but by default a sender falls back to plain text if TLS fails, and accepts any certificate. An attacker on the path can strip the upgrade or impersonate your mail server.

MTA-STS (RFC 8461) lets you publish a policy that says "only deliver to these MX hosts, over TLS, with a valid certificate". Gmail, Microsoft 365 and other large senders honour it. TLS-RPT (RFC 8460) asks those senders to email you a daily report of TLS failures, so you see problems before mail is lost.

What the checker tests

• The _mta-sts TXT record: exactly one, starting v=STSv1, with an id of 1 to 32 letters and digits.
• The policy host: https://mta-sts.<domain>/.well-known/mta-sts.txt must answer 200 directly, without redirects, over a trusted certificate for that name, as text/plain.
• The policy syntax: version: STSv1, a valid mode (enforce, testing or none), max_age up to one year, and at least one mx line.
• MX coverage: every MX host must match an mx line (*.example.com matches exactly one extra label). In enforce mode, an unmatched host stops receiving mail from MTA-STS senders, which is the most common way a rollout breaks delivery.
• The _smtp._tls TLS-RPT record and its mailto: or https: report destinations.

MX servers' own STARTTLS certificates aren't checked here, because that needs port 25, which our hosting provider blocks. TLS-RPT reports cover it from real senders.

A safe rollout

• Publish TLS-RPT first, so reports start arriving.
• Publish the policy in mode: testing with an mx line for every MX host, and the _mta-sts record. The checker builds this starting setup from your current MX records.
• After a week or two of clean reports, change to mode: enforce and change the record's id. Senders cache the policy for max_age, so the id change is what makes them fetch the new one.
• Before changing mail provider, add the new MX hosts to the policy (and bump the id) first, then change the MX records.

Questions

Why does my MTA-STS policy fail with a redirect?

Senders must not follow HTTP redirects when fetching the policy. Hosting platforms often redirect mta-sts.example.com to www or to a trailing-slash URL; serve /.well-known/mta-sts.txt directly with status 200.

Do I need to change the id every time?

Yes. Senders re-fetch the policy only when the id in the DNS record changes or their cached copy expires after max_age. Using a date such as 2026102101 makes changes easy to track.

What max_age should I use?

One to several weeks, for example 604800 (7 days) or 1209600 (14 days). Very short values make the protection lapse quickly if the policy host is unreachable; the maximum is 31557600 (one year).

Does MTA-STS replace DANE?

They solve the same problem differently. DANE pins certificates in DNSSEC-signed TLSA records and needs DNSSEC; MTA-STS uses a web-hosted policy and ordinary certificates. Many large senders support MTA-STS, and some also support DANE.