SMTP transport security has an observability problem. A recipient domain can publish an MTA-STS policy or DANE TLSA records, yet many failures occur on remote sending systems: certificate validation can fail, an MX host can become unreachable, STARTTLS negotiation can break, or a published transport policy can be invalid. The recipient needs telemetry from those senders to distinguish a working deployment from a policy that silently blocks delivery.
SMTP TLS Reporting, commonly called TLS-RPT, defines that telemetry channel in RFC 8460. A recipient domain publishes a DNS TXT record that names one or more report destinations. Participating sending systems then produce aggregate reports describing successful policy-compliant TLS sessions and failures encountered while delivering mail to that domain.
TLS-RPT does not itself require TLS for SMTP delivery. It reports transport-security outcomes. MTA-STS and DANE can impose or authenticate transport requirements; TLS-RPT supplies operational evidence about the resulting sessions.
The reporting policy lives at _smtp._tls
A recipient publishes its TLS-RPT policy as a TXT record beneath _smtp._tls for the policy domain. A minimal policy using email delivery can look like this:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"RFC 8460 defines TLSRPTv1 as the version value. The rua directive contains the URI or URIs that receive aggregate reports. Version 1 supports mailto and https report destinations.
An HTTPS destination can instead be published as:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://reports.example.com/v1/tlsrpt"The DNS record is a reporting policy, not an SMTP transport policy. Publishing it does not make STARTTLS mandatory, select acceptable MX hosts, or define certificate identity rules. Those controls belong to mechanisms such as MTA-STS or DANE.
Record handling is deliberately strict around ambiguity. After records that do not begin with the TLS-RPT version marker are discarded, a sender that does not obtain exactly one applicable record treats the domain as not implementing TLS-RPT. This avoids merging independent policy records into an accidental configuration.
Reports summarize both success and failure
A TLS-RPT report is an aggregate document encoded as I-JSON. Its metadata identifies the reporting organization, contact information, a report identifier, and the covered time range. Policy sections describe the policy domain and the transport policy that the sender applied.
The report also carries aggregate session counts. total-successful-session-count records sessions that established a policy-compliant TLS connection. total-failure-session-count records sessions that did not establish the required connection.
Success data matters because a report containing only failures gives no baseline for comparison. A stream of successful sessions acts as a heartbeat that the reporting path is active and that compliant SMTP TLS negotiation is occurring.
Failure details can classify events such as certificate validation problems, STARTTLS negotiation failures, MTA-STS policy errors, or DANE-related validation failures. A single delivery attempt can encounter more than one failure type, so failure counts are not necessarily mutually exclusive.
TLS-RPT therefore should not be treated as a message-delivery ledger. Its unit of observation is transport behavior across SMTP sessions and applied policies, summarized for operational analysis.
MTA-STS and DANE remain separate enforcement mechanisms
RFC 8460 is designed to report results associated with SMTP transport security, including MTA-STS and DANE. The distinction between reporting and enforcement is important during incident analysis.
MTA-STS lets a recipient publish expected TLS availability, certificate identity requirements, and MX matching rules through its policy mechanism. DANE for SMTP uses DNSSEC-protected TLSA data to associate TLS authentication information with mail servers. TLS-RPT can report failures related to either model.
Consider a recipient that has a valid MTA-STS policy but deploys a replacement certificate whose identity no longer satisfies that policy. Supporting senders can record the resulting validation failures and include them in aggregate reports. The TLS-RPT DNS record did not cause the rejection; it provided a destination for evidence generated by the transport-policy evaluation.
The same separation applies to DANE. TLSA validation remains part of DANE processing. TLS-RPT provides a standardized format in which compatible senders can report DANE policy results.
Failure categories narrow the fault domain
Transport failures can look similar from the recipient’s perspective. Mail may be delayed or absent whether the cause is DNS resolution, an unavailable MX, a missing STARTTLS capability, an untrusted certificate, or a malformed transport policy.
TLS-RPT result types give operators a more precise fault signal. Reports can identify policy validation failures and include fields such as the receiving MX hostname, receiving IP address, and failed session count. The schema also permits additional information associated with a failure result.
This structure is useful during controlled changes. If an operator changes MX hosts, certificates, MTA-STS policy content, or DANE records, aggregate reports can expose a shift from successful sessions toward a particular failure class. The report does not prove malicious interference; the same result can arise from ordinary configuration faults.
That qualification matters for security monitoring. RFC 8460 was designed to surface both potential attacks and accidental breakage. A certificate mismatch, for example, is evidence of a validation failure, not by itself evidence that an attacker caused it.
Report transport has its own security properties
TLS-RPT reports can be delivered by email or HTTPS. The two paths have different handling rules.
For email delivery, RFC 8460 defines TLS-RPT media types and requires reports sent through SMTP to carry a valid DKIM signature from the reporting domain. The specification also prevents the reporting channel from being trapped by the same transport failure it is describing: failure reports sent by SMTP are delivered without honoring MTA-STS or DANE TLSA failures for that report delivery.
That exception is narrow. It applies to report transport so that a broken recipient transport policy does not suppress the evidence needed to diagnose the breakage.
For HTTPS delivery, the report is submitted with an HTTP POST to the configured endpoint. Reports may be plain JSON or gzip-compressed using the media types defined by the specification.
A report endpoint is an input boundary. RFC 8460 explicitly discusses risks including flooding and untrusted report content. Processing systems should treat report fields as untrusted data rather than executable material or trusted configuration.
Aggregate telemetry still needs careful interpretation
TLS-RPT gives a recipient visibility that cannot be reconstructed solely from its own mail server logs. A remote sender may fail before reaching the intended MX, or may reject a connection because a transport policy cannot be validated. Reports move some of that remote observation back to the policy domain.
Coverage, however, depends on participating sending systems. Absence of a reported failure does not establish that every sender reached the domain successfully, and a report stream is not a complete census of Internet mail delivery.
The strongest operational use is correlation. DNS changes, certificate rotations, MTA-STS revisions, DANE updates, and MX migrations can be compared with changes in TLS-RPT success and failure classes. Recipient-side logs can then provide the local half of the same event.
TLS-RPT fills a specific gap in SMTP security architecture: enforcement mechanisms can reject unsafe transport, while the reporting mechanism carries structured evidence about those decisions back to the domain responsible for the policy. That separation keeps telemetry from becoming another enforcement control and gives operators a direct signal when secure-mail policy and deployed infrastructure stop matching.