MTA-STS and TLS reporting

Mail servers negotiate TLS opportunistically, which means an attacker sitting on the path can strip the encryption offer and the message goes through in plaintext instead. Neither end notices. MTA-STS is how you say that TLS is required for mail to your domain.

The two pieces

It needs a TXT record announcing the policy, and the policy file itself served over HTTPS from a dedicated subdomain.

plaintext

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

plaintext

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

Publish it in testing mode first

Set mode: testing to begin with. Senders will report failures without refusing to deliver, which lets you find a missing MX in the policy or a certificate that does not match before it costs you real mail. Switch to enforce once the reports are clean.

Every hostname in the policy needs a valid certificate covering that name, from a public CA. This is the part that usually breaks, because opportunistic TLS was happily accepting a self signed or mismatched certificate before.

TLS-RPT

The companion record asks senders to tell you when TLS delivery to you fails. It costs one TXT record and is worth having even before MTA-STS, because it shows you problems you would otherwise never hear about.

plaintext

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

The id in the MTA-STS record has to change whenever you change the policy file, otherwise senders keep using the version they cached.