TLS-RPT Checker/Generator
Validates the reporting record, RUA destinations, and external-provider context that make report delivery possible.
Email SecurityReading TLS-RPT Reports in Practice
TLS-RPT is not a stream of individual bounce notices. It is aggregate evidence about which sending systems could satisfy your SMTP transport policy, and it becomes useful only when you preserve volume, policy, route, and time context.
Read the envelope before the failures
A report is JSON, commonly delivered as a compressed attachment or submitted to an HTTPS destination. The top level identifies the reporting organization, contact information, a report ID, and a UTC date range. Treat the tuple of organization, report ID, and interval as the deduplication key; large senders may retry delivery, and counting the same report twice manufactures an incident. Reject malformed documents into a quarantine queue rather than silently dropping them or feeding partial data into trends.
The policies array is the working body. Each entry names the policy domain, policy type such as sts, tlsa, or no-policy-found, relevant policy strings or MX hosts, a summary of successful and failed sessions, and optional failure-details. One report can therefore describe several evaluated policies. Do not total the document first and ask questions later; keep each policy entry attached to its domain, MX context, and reporting sender.
The summary is your denominator
total-successful-session-count and total-failure-session-count give the population observed by that reporter during the interval. Always calculate both the failure count and failure rate. Ten failures out of twelve sessions demand a different response from ten failures out of twelve million. Likewise, a zero-failure report is valuable evidence that ingestion works and that one sender successfully used the policy; retaining only documents with errors destroys the baseline needed for sensible alarms.
Session counts are not message counts and reports are not a complete census. A sender may deliver many messages over one SMTP session, may not implement TLS-RPT, or may aggregate differently from another operator. Never infer exact lost-message volume from the totals. Use them to compare the same reporting population over time, and correlate sharp changes with your MX logs, certificate deployment, DNS changes, and queue events. The report says what the sender observed, not whether a user eventually received a particular message.
Failure details turn counts into hypotheses
Each detail typically supplies a result-type, failed-session count, and some combination of sending MTA IP, receiving MX hostname, receiving IP, receiving HELO, failure reason, or additional-information URI. Group first by policy domain, result type, and receiving endpoint. That preserves the operational question: did all senders fail against one MX, did one sender fail against every MX, or did one address family expose a different server? Raw reason strings are supporting evidence, not stable taxonomy; normalize carefully and retain the original.
Be suspicious of false precision. Reports differ in which optional fields they populate, and an absent receiving IP does not prove DNS was never resolved. Failure details are aggregates, not packet captures. A result type should nominate the next test, not close the incident. Confirm the current route with a live SMTP TLS Handshake / Mail Domain Delivery Readiness, then inspect historical server evidence for the report interval. The live check sees now; TLS-RPT saw then. Disagreement often means the fault was transient or already rolled back.
What the common classes say about you
starttls-not-supported usually means the selected exchanger did not advertise STARTTLS: an old backup, a plaintext listener, a middlebox, or an accidental service binding. Certificate hostname, trust, expiry, and validation failures point to the TLS terminator and its deployment path. If they start immediately after renewal, suspect a wrong certificate, missing intermediate, stale node, or name mismatch before blaming the reporter. Concentration on one receiving IP is particularly strong evidence of fleet drift.
MTA-STS policy-fetch and policy-validation failures implicate the fixed HTTPS policy surface, its certificate, content, DNS, or availability. An MX mismatch says the policy no longer describes the routing set — the signature of an uncoordinated migration. TLSA or DNSSEC failures belong to the DANE binding: wrong owner name, bogus DNSSEC, stale association data, or a certificate/key change performed before DNS rollover. Use the MTA-STS Checker/Generator to compare STS surfaces; validate DANE separately rather than treating every “TLS” failure as the same system.
Trends beat anecdotes, with two exceptions
A single failed session from one reporter can be Internet weather: a timeout, a sender-side resolver problem, or a short deployment edge. Track a rolling baseline by reporter, policy, result type, and receiving endpoint. Escalate when a class persists across consecutive daily reports, appears from several independent large senders, or clusters on infrastructure you own. Compare week-over-week rates as well as absolute counts; low-volume domains otherwise oscillate wildly, while high-volume domains can hide thousands of failures inside a tiny percentage.
Two classes deserve immediate attention even as single observations: evidence that an enforced policy rejects every observed session, and a new deterministic validation failure directly after your change. Waiting for a trend only collects more failed deliveries. Conversely, avoid alerting merely because a new reporter appears or no-policy-found is present where you intentionally publish no strict policy. Alerts need an expected-state inventory. Without one, the monitoring system cannot distinguish non-adoption from regression.
Build thresholds around blast radius
Page on a complete or near-complete failure rate from any material sender, a certificate or STARTTLS failure affecting a preferred MX, the same infrastructure-owned class from multiple reporters, or a sudden step change after deployment. Create a ticket, rather than a page, for low but persistent rates, failures confined to a backup, and repeated policy-fetch trouble without known delivery impact. Suppress isolated low-volume noise only with an expiry; permanent suppressions are where dead backup MX hosts go to hide.
Store raw reports, parsed rows, ingestion errors, and the policy snapshot that applied during each interval. Test the reporting destination itself and validate the published _smtp._tls record with the TLS-RPT Checker/Generator; it checks record syntax and destinations, not report contents. Finally, attach changes to timelines. TLS-RPT is most decisive when the graph says “certificate rollout at 09:10, hostname mismatch from three reporters at 09:15,” not when an inbox contains five JSON files nobody has joined.