What it is

A TXT record at _smtp._tls.yourdomain of the form v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain. Sending servers that support it — Google, Microsoft and most large providers — send a daily report to that address describing every attempt to deliver to you over TLS and whether it succeeded. The format is defined in RFC 8460.

What the reports contain

Each report is a gzip-compressed JSON file covering one day from one reporting organisation. It lists the policy it applied (MTA-STS, DANE, or none), the number of successful sessions, and for every failure the type — certificate mismatch, STARTTLS not offered, policy fetch failure — with the MX host involved. On a healthy Google or Microsoft domain every report says the same thing: all sessions succeeded, zero failures.

The moment an MX host is missing from your MTA-STS policy, or a certificate expires, the failures appear here first. Nobody else will tell you.

Setting it up

Publish the record before you publish an MTA-STS policy, so you have visibility from the first day of testing mode. Use a dedicated mailbox or a reporting service that also handles DMARC aggregates; the raw JSON is fine to read by hand for one domain and unmanageable for a fleet. Then confirm with the MTA-STS checker that the record is visible and has a valid rua.

Record syntax and where reports go

The record is a TXT at _smtp._tls.yourdomain.com: v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com. The rua can be a mailto address, an https endpoint, or both separated by a comma. Reporting senders — Google, Microsoft and a growing list of others — send one report per day per domain to that address, as a gzip-compressed JSON attachment. The TLS-RPT generator writes the record; the TLS-RPT checker confirms it resolves and is well-formed.

Use a dedicated mailbox. On a fleet, the volume is one report per receiver per domain per day, which on a Gmail-heavy list is a few hundred small files a week. If the mailbox is on a different domain from the one being reported on, that is fine — unlike DMARC, TLS-RPT has no cross-domain authorisation step.

Reading a report

Each report has a policies array. For each policy the sender applied to your domain it lists the policy type (sts, tlsa for DANE, or no-policy-found), the policy text it fetched, a summary of successful and failed session counts, and a failure-details list. The summary is the number you watch: on a healthy domain, failed sessions are zero. Any non-zero count is a delivery you nearly did not get, and in enforce mode, one you did not.

Failure types and what they mean

• starttls-not-supported — your MX did not offer TLS. On Workspace or M365 this does not happen; on a self-hosted MX it means the server is misconfigured.
• certificate-expired / certificate-not-trusted — the MX certificate is bad. Again, not on the big providers; on your own MX, renew it.
• certificate-host-mismatch — the certificate is valid but not for the MX hostname. Common when an MX points at a hostname the provider does not hold a certificate for.
• sts-policy-fetch-error — the sender could not retrieve your MTA-STS policy file. The policy host is down, has a bad certificate, or something in front of it returned HTML.
• sts-policy-invalid — the file was fetched but does not parse, or its mx lines do not match your MX.
• sts-webpki-invalid — the certificate on the policy host itself is not trusted.

The last three are the ones a cold email fleet actually sees, and they all point at the MTA-STS policy host rather than the mail servers. Fix the host, bump the policy id, and the next day's report should be clean. The MTA-STS checker reproduces the sender's fetch and shows which of these it hits.

Check yours

These run free in your browser. Nothing you type reaches a server.

Common questions