DnsGuard › Guides › MTA-STS & TLS-RPT

MTA-STS and TLS-RPT explained

SMTP between mail servers uses TLS opportunistically: if a sender can't negotiate TLS, or an attacker strips it, the message is usually delivered in plain text anyway. MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) lets a domain that receives email say "only deliver to my listed mail servers, over TLS with a valid certificate". TLS-RPT (SMTP TLS Reporting, RFC 8460) asks senders to email you a daily report when TLS delivery to you fails. Both are optional and much less common than SPF, DKIM and DMARC, and they protect a different thing: the connection, not the sender's identity.

The two parts of MTA-STS

1. A TXT record at _mta-sts.<domain>:

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

id is 1–32 letters or digits. Change it every time you change the policy file, so senders know to fetch the new version. Publish exactly one such record.

2. A policy file served over HTTPS at exactly https://mta-sts.<domain>/.well-known/mta-sts.txt, with a valid certificate for mta-sts.<domain>, HTTP 200, Content-Type: text/plain and no redirects:

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

A safe rollout plan

1. Publish TLS-RPT first (below) so you get reports.
2. Serve the policy file with mode: testing, list every MX host, and use a short max_age such as 86400 (one day). Publish the TXT record.
3. Read the TLS reports for a few weeks and fix any MX host with an expired or mismatched certificate.
4. Switch to mode: enforce, raise max_age to 604800 (one week) or more, and change the id.
5. When you change mail providers, add the new MX hosts to the policy (and change the id) before you change your MX records.

TLS-RPT: reports about TLS failures

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

rua takes one or more mailto: addresses or https:// endpoints, separated by commas. Senders such as Google and Microsoft then send a daily JSON report listing successful and failed TLS sessions to your mail servers. It works with or without MTA-STS (it also covers DANE).

Common mistakes

• A TXT record with no reachable policy file, or a policy on a host whose certificate doesn't cover mta-sts.<domain>.
• Redirecting the policy URL (for example to www). Senders must not follow redirects, so the policy is ignored.
• mode: enforce with an MX host missing from the mx lines. Senders that support MTA-STS will refuse to deliver to it.
• Changing the policy but not the id, so senders keep using the cached old policy until max_age runs out.
• Staying on mode: testing forever.

How DnsGuard scores MTA-STS and TLS-RPT (bonus: up to 5 points)

These are bonus points on top of the 100 points from MX, SPF, DKIM, DMARC and BIMI, and the total is capped at 100. A missing record scores 0 with an info note, so it never lowers your score. Bonus points apply only when SPF passes and DMARC is at quarantine or reject.

MTA-STS (up to 3): a valid record and policy in enforce mode scores 3, testing 1 and none 0. An enforce policy whose mx patterns don't cover every MX host scores 0. A max_age under 86400 (one day) costs 1 point (never below 0). MTA-STS scores 0 if the TXT record is missing or invalid (or there is more than one) or its DNS lookup fails, if the policy file can't be fetched (the policy host has no address or a private one, a connection or certificate error, a timeout after 3 seconds, a status other than 200, a redirect, a non-text response or more than 64 KB), or if the policy is invalid (including a max_age above 31557600). For a domain with a null MX, the policy file isn't fetched and MTA-STS scores 0.

TLS-RPT (up to 2): 2 points for exactly one valid v=TLSRPTv1 record whose rua destinations are all valid mailto: or https:// URIs; otherwise 0.

DnsGuard fetches only https://mta-sts.<domain>/.well-known/mta-sts.txt for the domain you check. It never follows redirects and doesn't fetch the rua endpoints.

More guides: SPF · DKIM · DMARC · BIMI