MTA-STS · TLS-RPT

Deploying MTA-STS and TLS-RPT: securing in-transit email encryption

22 October 2026

MTA-STS tells sending MTAs to require TLS to your published MX hosts using a policy file over HTTPS. TLS-RPT gives those senders a place to report TLS failures. Together they harden in-transit delivery; they do not replace SPF, DKIM, or DMARC.

What receivers need

TXT at _mta-sts.brand.example (policy ID / version).
HTTPS policy at https://mta-sts.brand.example/.well-known/mta-sts.txt with a certificate covering that hostname.
TXT at _smtp._tls.brand.example for TLS-RPT (v=TLSRPTv1; rua=mailto:…).

Hosted path on Sender Identity

On a paid domain card, choose Host MTA-STS / TLS-RPT. We publish hosted TXT targets and a policy host under the zone apex (Universal SSL–friendly single label).
On your DNS, publish CNAMEs for _mta-sts and _smtp._tls (DNS only) to the targets shown.
CNAME mta-sts.brand.example to the sts-<hash> name we show. If that name is on Cloudflare, orange-cloud (Proxied) is appropriate so the hostname gets a certificate—unlike Hosted DMARC’s _dmarc, which must stay DNS only.
Confirm the policy at https://mta-sts.brand.example/.well-known/mta-sts.txt and re-run the static audit.

Mode and MX hygiene

Start in testing until TLS-RPT shows clean connects, then move to enforce. Policy MX patterns must match the MX you actually publish—stale MX in the policy file causes avoidable failures.