28 MTA-STS + TLS reporting
MTA-STS tells sending servers that mail for your domain must be delivered over authenticated, validated TLS to the MX hosts you name, so an attacker on the network path cannot strip the encryption or redirect delivery. Unlike SPF, DKIM and DMARC (4 Email authentication (SPF/DKIM/DMARC)), it is not a DNS record you set once: the policy is a document served over HTTPS from an mta-sts subdomain, pointed at by a TXT record whose id must change whenever the policy does. TLS-RPT is the paired reporting record that turns a failed TLS delivery into a report rather than mail that silently never comes.
Documentation: About MTA-STS and TLS reporting ↗
Caveats
Setup steps
-
https://mta-sts.<domain>/.well-known/mta-sts.txt — version: STSv1; mode: testing; mx: <each MX host>; max_age: 6048002. Create an MTA-STS policy ↗ 3. Publish your MTA-STS policy ↗
-
TXT _smtp._tls.<domain> = v=TLSRPTv1; rua=mailto:tlsrpt@<domain> -
TXT _mta-sts.<domain> = v=STSv1; id=<1–32 alphanumeric id, e.g. a timestamp> -
Policy file mode: testing → enforce; TXT id bumped
Ongoing maintenance
- automatable: script Continuously: the policy host’s TLS certificate must stay valid — expiry silently disables enforcement for senders.
- automatable: AI agent Monthly: read TLS-RPT reports for delivery failures.
How to verify
Both halves are public — check them from anywhere, no tenant access needed. The policy file the curl returns must say mode: enforce and list exactly the Google MXs.
dig +short TXT _mta-sts.<domain>; curl -s https://mta-sts.<domain>/.well-known/mta-sts.txt
Confirm TLS reporting is wired: the record must exist and its rua= address must be a mailbox someone reads.
dig +short TXT _smtp._tls.<domain>
v0.1.2Preventedition All (DNS + an HTTPS host) policy #6 · #27 ↗