How to Read TLS-RPT Reports (Aggregate TLS from Google)

What is TLS-RPT? SMTP TLS Reporting: a DNS record that tells senders where to deliver summaries of TLS negotiation to your MX. How to read TLS-RPT reports is the follow-on job — opening the daily JSON (often gzip) without drowning in attachments. Google’s human-readable part often starts with this is an aggregate TLS report from google.com. That sentence is expected, not a lure.

TLS-RPT is inbound: mail delivered to your domain. It is not a log of your outbound newsletters. Identity authentication still comes first — DMARC setup. The policy that controls inbound TLS is What is MTA-STS. This article is the field guide for the reports.

What is TLS-RPT

RFC 8460 defines SMTP TLS Reporting. You publish a TXT at _smtp._tls.<domain> so senders know where to send reports:

_smtp._tls.example.co.za. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.co.za"

rua= may also be an https: URL. Either way, reports describe sessions to your receiving MX, not mail you send.

A typical report is I-JSON, often gzip (.json.gz), mailed as multipart/report; report-type=tlsrpt: a short text/plain body plus application/tlsrpt+json or application/tlsrpt+gzip. Cadence is daily-ish. Transient network errors are not required to be reported.

MTA-STS is the control (policy file + DNS). TLS-RPT is visibility. Confirm the TXT exists with free tools; that check is DNS only — it is not a TLS analytics suite.

This is an aggregate TLS report from google.com

When Google (or another reporter) emails TLS-RPT, the human part often begins:

This is an aggregate TLS report from google.com

RFC 8460 uses the same “This is an aggregate TLS report from …” pattern. Treat it as a cover note. The work is the JSON (or gzip) part.

Do not confuse it with a DMARC aggregate (rua) report. That XML is about who sent as your domain. TLS-RPT JSON is about whether other MTAs could talk TLS to your MX.

How to read TLS-RPT reports

Open one reporting window and walk these fields. You do not need every optional tag.

Report metadata (organization-name, date-range, contact-info, report-id) sits at the top. Each policies[] row then has three siblings: policy, summary, and failure-details. summary is per policy, not a top-level key — grepping a Google gzip for a root summary will miss it.

What to look at	Plain-language question	Action if wrong
organization-name / report-id	Who produced this summary?	Label the reporter (Google, Microsoft, …)
date-range (start-datetime / end-datetime)	Which window?	Compare week-on-week, not one gzip
contact-info	How do we reach the reporter?	Keep for escalation; ignore for triage
policies[].policy	What policy did they apply?	See policy-type below
policies[].summary.total-successful-session-count	Are senders still connecting over TLS?	Heartbeat — silence plus failures is an outage signal
policies[].summary.total-failure-session-count	How much TLS failed?	Material count → open failure-details
policies[].failure-details[]	Which result-type, which MX, how many?	Map the token, then fix MX/cert/policy

policies[] (one object per policy the reporter evaluated):

• policy-type: sts (MTA-STS), tlsa (DANE), or no-policy-found
• policy-string: what they fetched (STS file lines, or TLSA)
• policy-domain / mx-host: which name they checked

failure-details[] rows that matter operationally:

• result-type — the IANA / RFC 8460 token (table below)
• sending-mta-ip — the sender’s connecting IP
• receiving-mx-hostname / receiving-ip — which of your MX they hit
• failed-session-count — how many sessions this row represents
• optional failure-reason-code — short TLS error code or text
• optional additional-information — a URI to extra detail (not free-form notes)

Answer first: if successful sessions are healthy and failures are a handful of unknown IPs, note and move on. If failures spike on certificate-expired or sts-policy-fetch-error from large senders, fix that path before you debate JSON schema.

Result-type meanings

RFC 8460 §4.3 / IANA tokens only — do not invent others. Transient network errors need not appear.

Token	Plain English	Typical fix
starttls-not-supported	MX did not offer STARTTLS	Enable STARTTLS on inbound MX
certificate-host-mismatch	Certificate name did not match the MX hostname	Align cert SAN with published MX names
certificate-expired	Certificate past notAfter	Renew before expiry; monitor dates
certificate-not-trusted	Chain not trusted by the sender	Fix intermediate/CA chain
validation-failure	Other TLS validation failure	Check cert, hostname, and TLS config
tlsa-invalid	DANE TLSA did not match the cert	Fix TLSA, or stop advertising DANE until ready
dnssec-invalid	DNSSEC validation failed for DANE	Repair the DNSSEC chain
dane-required	DANE was required but not usable	Align TLSA + DNSSEC with the MX
sts-policy-fetch-error	Could not fetch the MTA-STS policy	HTTPS host, /.well-known/mta-sts.txt, DNS for mta-sts.
sts-policy-invalid	Policy fetched but unparsable or invalid	Fix version / mx: / mode in the file
sts-webpki-invalid	Policy HTTPS PKIX validation failed	Valid certificate on the policy HTTPS host

Do not confuse fetch vs invalid vs web PKI:

• unreachable policy host → sts-policy-fetch-error
• unparsable or invalid policy body → sts-policy-invalid
• HTTPS certificate/PKIX failure for the policy host → sts-webpki-invalid

Negotiation tokens (starttls-not-supported, certificate-*, validation-failure) are about the MX TLS handshake. STS tokens are about the policy file. DANE tokens only matter if you publish TLSA.

TLS-RPT vs DMARC aggregate reports

	TLS-RPT	DMARC aggregate (rua)
Question	Could senders negotiate TLS to our MX?	Who sent as our domain, and did SPF/DKIM align?
Direction	Inbound transport	Identity of outbound-claiming mail
Format	JSON / gzip	XML
Control plane	MTA-STS (and/or DANE)	p= on the DMARC record
DNS	_smtp._tls TXT	_dmarc TXT rua=

You want both. A domain can have clean DMARC and still accept plaintext fallback, or a solid STS policy and still have spoofing on p=none. Read how to read DMARC aggregate reports for the identity side.

Weekly triage checklist

Use the same pass every week. A mailbox nobody opens is archiving, not review — same discipline as unread DMARC rua.

1. Confirm reports arrive — _smtp._tls rua= mailbox (or HTTPS collector) has last-7-day files.
2. Confirm the TXT still publishes — free tools for _smtp._tls (DNS check only).
3. Scan heartbeats — total-successful-session-count from large reporters should not fall off a cliff.
4. Sort failures by result-type × receiving-mx-hostname.
5. Act on clusters — expired certs, host mismatch, STS fetch errors from multiple reporters.
6. Ignore one-off noise — a single unknown IP with one validation-failure is not a change ticket.
7. Record the fix (cert renew, policy file, MX cleanup) and re-check the next window.
8. Keep MTA-STS policy in sync with live MX — see What is MTA-STS.

Common mistakes

Treating TLS-RPT as DMARC

Different reports, different questions. TLS-RPT will not tell you who spoofed your From domain.

Reading outbound into inbound reports

These files are about delivery to you. A marketing ESP TLS problem will not show up here.

Panicking at one gzip

Successful-session counts are the heartbeat. One failure row from a scanner is not an outage.

Confusing STS fetch, invalid, and webpki

Wrong ticket if you renew the MX certificate for sts-policy-fetch-error, or chase DNS for sts-webpki-invalid.

Policy without reporting — or reporting without an owner

Publish TLS-RPT before or with MTA-STS enforce. Name who opens the JSON. Unwatched rua= is theatre.

Expecting a public DNS scan to replace reading reports

Free tools can confirm the _smtp._tls TXT exists. They do not interpret gzip for you. Basic DNS status on a monitoring plan is not a TLS-RPT analytics suite.

Final takeaway

TLS-RPT is how you see inbound TLS without guessing from bounce text. Publish _smtp._tls, keep MTA-STS policy accurate, and triage result-type weekly. Auth first (DMARC setup), policy next (MTA-STS), reports always.

Check the TLS-RPT TXT on free tools, then open this week’s aggregate JSON — including the next “this is an aggregate TLS report from google.com” sitting in the mailbox.