30 MTA-STS + TLS reporting

Caveats

• This is a running obligation, not a set-once record — the policy is served over HTTPS, so its certificate must be renewed like any other, and if that certificate expires or the mta-sts host goes down, senders fall back to the cached policy until max_age lapses and the protection then simply disappears. Budget for monitoring it, or do not publish it.
• An enforce-mode policy that names the wrong MX hosts makes senders REFUSE to deliver to you — run in testing mode, read the TLS-RPT reports, and only then enforce. Any later MX change means updating the policy file and bumping its id first, or mail breaks.
• It protects mail coming TO you, and only from senders that implement it — it does nothing about mail you send, nothing about a sender that ignores the policy, and nothing about message content. It is a transport control, not an anti-phishing one.

Setup steps

1. 1. Publish the MTA-STS policy file over HTTPS. Unlike SPF, DKIM and DMARC (4 Email authentication (SPF/DKIM/DMARC)), this is not a DNS record you set once: it is a document served from an mta-sts subdomain, on a certificate you now have to keep valid.

   https://mta-sts.<domain>/.well-known/mta-sts.txt — version: STSv1; mode: testing; mx: <each MX host>; max_age: 604800

2. 2. Publish TLS-RPT first, so reporting is live before senders honor the policy and failed TLS delivery arrives as a report rather than as mail that silently never comes.

   TXT _smtp._tls.<domain> = v=TLSRPTv1; rua=mailto:tlsrpt@<domain>

3. 3. Publish the DNS record that points senders at the policy file. The id — 1–32 alphanumeric characters, commonly a timestamp — must change whenever the policy changes, or senders keep using the cached copy.

   TXT _mta-sts.<domain> = v=STSv1; id=<1–32 alphanumeric id, e.g. a timestamp>

4. 4. Read the TLS-RPT reports until they are clean, then switch the policy file from testing to enforce and bump its id. Do not skip the testing phase.

   Policy file mode: testing → enforce; TXT id bumped

5. 5. For the handful of partners whose mail must never fall back to cleartext, add a Secure transport (TLS) compliance rule in both directions. MTA-STS protects what the sending platform chooses to honour; this rule is Gmail itself refusing to send or accept mail for the named domains without validated TLS.
   open ↗

   

   https://admin.google.com/ac/apps/gmail/compliance · captured 2026-07-15

   Apps › Google Workspace › Gmail › Compliance

   Secure transport (TLS) compliance: Inbound + Outbound rule for the <partner domains> address list; Require CA-signed certificate = On; Validate certificate hostname = On (run Test TLS connection before saving)

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

1. 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

2. 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>