[ Transport security ]

TLS-RPT explained through a transport-failure report

Read a TLS-RPT report by authenticating its context, separating policy entries and session counts, and translating failure categories into bounded investigation questions.

By the EmailAuth research team · 6 min read

[ Key points ]

Authenticate report delivery context before trusting extracted JSON.
Keep policy arrays, time windows and reported policy content intact.
Do not sum overlapping failure details into an assumed unique count.
Preserve current errata status and actual parser behavior when handling schema inconsistencies.

On this page

Key points
Read a TLS report as a bounded observation
Verify the reporting context
Establish the window and the applied policy
Work through fictional counts carefully
Turn result types into investigation questions
Preserve schema and source caveats
Close the loop without claiming universal health
Role perspectives
Glossary
Primary sources and evidence scope

Read a TLS report as a bounded observation

A TLS-RPT report describes what one reporting system observed while attempting transport connections under particular policies. It can guide an investigation into TLS negotiation, certificates or policy retrieval. It is not a message-level delivery ledger, a DMARC verdict or proof that every sender sees the same configuration. Begin with the reporter, time window and applied policy before interpreting its counts.

No original report or customer connection evidence accompanies this article. The worked numbers below are fictional, and the method is a proposed review process. A production incident needs the unchanged report, its receipt context and corroborating connection or hosting observations. Do not relabel an illustrative report as an observed outage.

Verify the reporting context

A domain requests reporting through a TXT record at _smtp._tls.<domain>, using TLSRPTv1 and one or more rua destinations. That request does not itself impose a transport-security policy. Reports can concern MTA-STS, DANE or the absence of a policy. Preserve the reporting request and the intended recipient organization when later collecting evidence, especially where a service processes reports for several domains. RFC 8460 sections 2–3

An SMTP-delivered report requires a valid reporting-domain DKIM signature that does not use the l= body-length tag. A generic DKIM pass with partial body coverage does not satisfy this reporting requirement. RFC 8460 directs recipients to ignore reports without the required signature and prohibits body-length limiting so that misleading content cannot be appended outside the signed coverage. Authenticate and retain the original message before trusting an extracted JSON attachment. Names and contact fields inside JSON are claims, not independent sender authentication. Treat attachments as untrusted input and process them with appropriate file-size and parser limits. RFC 8460 sections 3 and 7

Establish the window and the applied policy

Read organization-name, report-id and date-range together. The specification recommends a full UTC day and delayed delivery to reduce processing spikes. Receipt time therefore need not match the event time. Keep a deduplication record keyed to the authenticated reporter and report identity, with the original file hash, before aggregating repeated deliveries. The exact deduplication design is an operational recommendation, not a mandated schema field. RFC 8460 sections 4.1 and 4.4

The policies field is an array, even for a single applied policy. For each entry, inspect policy-type, policy-domain, policy-string and the applicable MX information. A report about sts must be interpreted against the reported MTA-STS policy, which may differ from the body currently hosted. Cached policy history can explain that difference without implying that the report is fabricated. RFC 8460 sections 4 and 4.4 RFC 8461 section 3.3

Work through fictional counts carefully

Imagine an authenticated report from fictional Sender Delta covering one UTC day for example.com. Its single sts entry describes an enforce policy. The summary contains 480 successful sessions and 20 failed sessions. Failure details list 12 certificate-expired sessions for mx1.example.com and 8 starttls-not-supported sessions for mx2.example.com. In this invented case, the two detail groups are stipulated to be disjoint.

The summary supports a 20 divided by 500, or 4 percent, failure share among this reporter's counted sessions for that entry and interval. It does not establish that 4 percent of messages were lost, because sessions are not messages and later attempts may have different outcomes. Nor does it estimate the receiving domain's global failure rate without information about other senders and reporting coverage. RFC 8460 section 4.2

Real detail counts require more care than this simple example. Failure types are nonexclusive, and one attempt can encounter multiple errors. Several policy entries may describe the same domain and MX. Summing every detail row, or every policy's counts, can double-count underlying attempts. Retain each policy entry and its summary rather than forcing every report into a single unqualified total. RFC 8460 section 4

Turn result types into investigation questions

For the fictional expiration group, request the receiving hostname, receiving address, event window and available certificate detail. The next question is whether the server presented an expired certificate at that time, not whether the operator now has an unexpired file on disk. For the STARTTLS group, examine the relevant SMTP endpoint and its advertisement or response. Neither observation establishes a policy-host HTTPS problem. RFC 8460 section 4.3.1

Policy failures have separate labels. sts-policy-fetch-error indicates retrieval failure; sts-policy-invalid concerns the overall policy; sts-webpki-invalid means the policy could not be authenticated through PKIX validation. Use the reporter's failure-reason-code and endpoint context where available. A broad label narrows the investigation but does not prove whether a firewall, routing change, certificate chain or application response caused it. RFC 8460 section 4.3.2.2

Preserve schema and source caveats

Do not copy the RFC's example JSON blindly into a strict validator. Its current errata register includes Held for Document Update entry 6241 concerning the example's scalar mx-host versus the array definition. Preserve the original report, record the actual representation and document any parser compatibility handling. A held correction is not the same status as a verified correction. RFC 8460 section 4.4 RFC 8460 errata

Verified erratum 8070 clarifies that the reporter may choose to attempt delivery to only one of several reporting endpoints. Therefore, a second destination's empty mailbox does not prove no report was produced. The register also contains reported, held and rejected entries; retain their statuses rather than treating every proposed change as current protocol text. RFC 8460 errata

Close the loop without claiming universal health

Assign the suspected endpoint to its owner, retain the original report and compare any authorized repair with later windows from the same reporters. Some transient network failures need not be reported, and sender participation varies. An improving trend is evidence within that coverage, not proof that all transport paths are healthy. Original authenticated reports, endpoint traces, hosting history and independent review remain open requirements for this draft. RFC 8460 sections 4.3.4 and 7

[ Takeaway ]

A report is evidence about one reporter's sessions and time window. Preserve that scope instead of converting failure counts into lost messages or global outage rates.

[ By role ]

What this means for you

Choose your role for practical next steps.

Reporting analyst

Keep the arithmetic within its scope

The analyst should preserve the distinction between a reporter's sessions, overlapping detail categories and global delivery outcomes.

Next steps

Retain report identity, interval and original file hash.
Calculate rates from the matching summary entry.
Label coverage gaps and avoid message-loss claims unsupported by message evidence.

Mail service operator

Map each failure to its endpoint

SMTP negotiation and HTTPS policy retrieval have different dependencies and owners. A result type is the beginning of diagnosis.

Next steps

Request hostname, address and event-time context.
Correlate reported certificate errors with the actual serving certificate.
Compare post-repair windows without discarding the original failure evidence.

Report pipeline owner

Preserve authenticity and schema differences

A robust pipeline should retain the original authenticated report and make compatibility handling visible.

Next steps

Require a valid reporting-domain DKIM signature without the l= body-length tag for SMTP-delivered reports; do not accept a generic DKIM pass with partial body coverage.
Handle policies as an array and bound parser resource use.
Document the mx-host representation and current errata status instead of silently rewriting evidence.

[ FAQs ]

Frequently asked questions

Does TLS-RPT force sending servers to encrypt mail?

No. TLS-RPT requests reporting about transport and policy results. Delivery constraints come from the applicable transport policy and supporting sender behavior, not from the rua reporting destination.

Are twenty failed sessions the same as twenty undelivered messages?

No. The counters concern sessions or attempted connections, not unique messages or final mailbox delivery. Retries and different outcomes can occur later. Correlate message-level evidence separately if the investigation requires it.

Can I add every failure-detail count to get the failure total?

Not safely. Failure categories are nonexclusive and one attempt can encounter more than one error. Multiple applied-policy entries can also overlap. Preserve the summary and detail scope instead of assuming every row represents different attempts.

Why might the reported policy differ from today's hosted policy?

A sender may have applied a policy fetched and cached earlier. Compare the report interval, policy string and available cache history with the change timeline before treating a difference as false reporting or a current hosting defect.

What distinguishes sts-webpki-invalid from certificate-expired?

The first concerns authentication of the MTA-STS policy through PKIX. The second is a negotiation-failure category describing an expired certificate on the relevant receiving connection. Preserve endpoint context before assigning the issue to HTTPS hosting or SMTP.

What authentication is required for reports sent by SMTP?

Require a valid reporting-domain DKIM signature that does not use the l= body-length tag. A generic DKIM pass with partial body coverage does not satisfy RFC 8460. Reports without the required signature must be ignored; names inside JSON are not authentication evidence.

Does the mx-host erratum make every scalar report invalid?

The current register holds entry 6241 for a document update because the schema's array definition and example differ and implementation compatibility matters. Preserve the input and document parser handling; do not present the held proposal as a verified universal compatibility rule.

Does an empty second reporting destination prove there were no failures?

No. Verified erratum 8070 clarifies that the reporter may choose only one destination. Participation, delivery and collection also affect coverage. No original report or authenticated collection test was supplied for this article.

[ Sources ]

Sources

[ Glossary ]

Glossary

Reporting domain: The domain of the system supplying the report; for SMTP-delivered TLS reports its DKIM signature provides required authentication.
Policy entry: An element of the report's policies array containing an applied policy, summary and associated failure details.
Session count: An aggregate count of successful or failed transport connections within the reporting context, not a unique-message delivery count.
Failure reason code: A report field supplying a TLS-related error code or message to clarify a failure category.
Held for Document Update: An RFC errata status distinct from Verified; the TLS-RPT mx-host example issue is retained in this state in the reviewed register.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base