Read the report envelope, policy scope and session summaries before interpreting individual transport failures. Use this guide to prepare and interpret evidence before changing a receiving service. The worked example is explicitly synthetic and the checks remain separate from any production acceptance decision.
Start with the envelope
References: RFC 8460 §4.1, RFC 8460 §4.4, RFC 8460 §5.6.
A TLS-RPT document is an aggregate report, not an SMTP transcript. Read organization-name, report-id, contact-info and date-range first. Store the start and end instants with their timezone rather than assigning every observation to the day the attachment arrived. Reporting normally covers a UTC day and can deliberately arrive hours later. The organization-name field is a claim inside a document; ingestion must retain the authenticated transport context separately. These distinctions prevent a delayed report from being mistaken for a new outage.
Keep each policy entry intact
References: RFC 8460 §4, RFC 8460 §4.4.
The policies member is an array even when only one policy is reported. Each entry contains policy, summary and potentially failure-details. Inspect policy-type, policy-domain, policy-string and mx-host before combining entries. An STS entry describes the policy observed by the reporter, which may differ from today’s published policy because caching and changes intervene. Preserve the original strings as evidence. Do not replace them with a current DNS lookup and then claim that the new lookup explains the historical session.
Calculate one bounded example
References: RFC 8460 §4, RFC 8460 §4.2.
Use a synthetic entry with total-successful-session-count 240 and total-failure-session-count 60. The failure share is 60 / (240 + 60), or 20 percent for this reporter, policy and reporting period. Suppose failure-details includes 40 certificate-expired observations and 30 certificate-not-trusted observations. Their sum of 70 does not disprove the summary: categories can overlap when an attempt has multiple errors. Do not relabel 70 as unique failed sessions. If both summary counts are zero, show the ratio as unavailable rather than divide by zero or imply perfect service.
Route the category to the right investigation
References: RFC 8460 §4.3.
starttls-not-supported points to SMTP capability; certificate-host-mismatch points toward identity validation; certificate-not-trusted needs the available failure-reason-code and certificate chain. sts-policy-fetch-error concerns retrieving the policy, while sts-webpki-invalid concerns authenticating that HTTPS endpoint. A generic validation-failure is not a diagnosis of an obsolete TLS version. Preserve unfamiliar categories and label them unclassified instead of silently discarding them. RFC 8460 anticipates expansion of the result vocabulary.
Build a safe reader rather than a trusting renderer
References: RFC 8460 §7.
Validate JSON structure, numeric counts and date parsing before analysis. Apply input and decompression limits, preserve the raw digest, and escape strings before showing them in a dashboard. Report-supplied additional-information links are untrusted input, not instructions to browse automatically. Treat missing endpoint fields as unavailable evidence. Pair the aggregate result with authorised endpoint checks before assigning root cause or customer impact. The newly recorded arithmetic fixture in this package is a local teaching test; no production sender or production report was tested.
Retained historical evidence and remaining scope
The following describes preserved 7 November 2026 observations, not a network experiment rerun for this review. Newly executed offline checks are recorded separately.
The preserved historical tls_lab.py script and its dated capture record a loopback SMTP greeting, EHLO, STARTTLS and certificate-validated TLS handshake. A positive control negotiated TLSv1.3. A certificate issued for web.example.test failed verification for mx1.example.test with OpenSSL verify code 62. evidence/report_reader/annotated_lab_report.json contains a complete manually authored report representing exactly those two observations, with annotations mapping its failure to the recorded handshake and public certificate fingerprint. It was not generated by a reporting MTA, and its STS policy context is illustrative rather than discovered. This is retained controlled endpoint evidence, not current customer telemetry or a new test run. Reproduction requires Python with cryptography and local loopback sockets. Fresh runs generate new keys and timestamps, so compare the expected outcomes rather than requiring byte-identical certificate fingerprints.
Primary-source basis
The field definitions, discovery behavior and reporting limits come from RFC 8460, SMTP TLS Reporting, sections 3 and 4. Where STS validation is discussed, consult RFC 8461. The operational recommendations are distinguished from protocol requirements.