TLS-RPT asks participating sending systems to share aggregate SMTP TLS outcomes. Its DNS record is separate from MTA-STS discovery and separate from DMARC reporting. Publishing a valid record enables a reporting request; it does not enable transport enforcement or guarantee that every sender will submit a report.
Choose an owned destination
References: RFC 8460 §3, RFC 8460 §5.4.
For example.com, publish a TXT resource record at _smtp._tls.example.com. A minimal illustrative value is v=TLSRPTv1; rua=mailto:tls-reports@example.com. Replace the example address with a mailbox or collection service that you control and are authorized to use. Verify delivery capacity, processing, retention and who can access the resulting reports.
RFC 8460 supports mailto and https report URIs. HTTPS reporting uses POST rather than the GET used to retrieve an MTA-STS policy. A TLS-RPT destination is not the policy-host URL. Use the collector's actual supported endpoint and authorization process rather than sending reports to a general website or an arbitrary vendor address.
Publish one applicable record
References: RFC 8460 §3.
The version field must come first with the exact TLSRPTv1 value, and rua is required. Multiple destinations are comma-separated URI values in that same record. Characters with delimiter significance inside a URI need appropriate encoding. A reporting sender may attempt only one of several endpoints; do not assume identical copies will arrive everywhere.
If multiple TXT records are returned, records not beginning v=TLSRPTv1; are discarded. Exactly one applicable record must remain for TLS-RPT discovery. Multiple strings within one TXT record are concatenated without inserting spaces. Two independent TLS-RPT policies do not merge into one list of destinations.
Reproduce the record-boundary check
Create a lab answer with one v=TLSRPTv1; rua=mailto:tls-reports@example.com record and an unrelated verification TXT value. The intended selection leaves one candidate. Add a second independent TLSRPTv1 record and the discovery count becomes invalid. The supplied offline fixture was rerun for this review and executes this narrow candidate-selection case; it is not a complete URI validator, DNS server or reporting client.
For the actual domain, query the absolute owner _smtp._tls.YOURDOMAIN. with type TXT directly from each authority and through a recursive resolver. Preserve TTLs, full records and any aliases. Then verify the collector separately using its documented test workflow. This article contains no live DNS publication, report transmission or confirmed report receipt.
Validate incoming reports before trusting them
References: RFC 8460 §3, RFC 8460 §7.
For reports delivered by SMTP, RFC 8460 requires a valid DKIM signature by the reporting domain and forbids DKIM l= body-length limitation. Reports lacking the required valid signature must be ignored. The DKIM key should declare the tlsrpt service type; the specification permits a collector to ignore reports lacking that declaration.
Apply parser size limits and retain reporter identity and reporting period. Avoid interpreting silence as healthy transport: traffic volume, sender support, reporting schedules and collector failures can all affect arrivals. Correlate received transport reports with the named policy and SMTP route rather than treating them as SPF, DKIM or DMARC results for ordinary messages.
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 package contains a synthetic TLS-RPT JSON report linked to the actual loopback SMTP hostname failure. Its policy domain is example.test, its MX is mx.old.example.test, its result-type is certificate-host-mismatch and its failed-session-count is 1. The report’s period brackets the lab run, and its summary contains one failure and zero successful sessions for that selected scenario. The matching SMTP event records valid=false with the hostname-verification error. This report was generated locally from the observed event, not received from an independent sender and not DKIM authenticated. No redaction was needed because all names and addresses are lab-only. The optional additional-information field is omitted; RFC 8460 defines its value as a URI, so explanatory provenance is retained outside the report rather than placed in that field. It demonstrates the report-to-problem mapping, while actual DNS publication, collector receipt, signature validation and any production-specific evidence remain separate from this educational example.