Documentary review: 8 November 2026. No reporting destination, mailbox, HTTPS collector or DNS record was configured or tested. The destination contract and fictional example are proposed operational artifacts, not evidence of successful report delivery.
Choose a reporting destination as a service dependency
TLS-RPT asks participating sending systems to report observations about SMTP transport-security policy and delivery. The receiving domain publishes a TXT record at _smtp._tls followed by its policy domain. The version is TLSRPTv1, and rua identifies one or more reporting URIs. This is a reporting channel, not the HTTPS location that serves an MTA-STS policy and not a DMARC aggregate-report record. Reporting policy
Choose the destination owner before publishing it. Decide who receives reports, who operates parsing and storage, who investigates failures and who can change the destination. A third-party collector may receive operational metadata about sending organizations, receiving hosts and failure observations. Obtain the organization's approval for that data-sharing purpose and confirm the collector's supported format and account binding.
RFC 8460 permits mailto and https URIs, including a comma-separated list. It does not define the DMARC-style external-destination authorization DNS handshake. Do not create an invented authorization record or assume a DMARC collector's onboarding proves TLS-RPT collection is enabled. Any supplier-specific verification or permission requirement must be established separately from the protocol. TLS-RPT URI syntax and delivery
Resolve duplicate reporting policies before delivery diagnosis
RFC 8460 section 3 defines deterministic record selection: discard TXT resource records that do not begin with the literal prefix "v=TLSRPTv1;". If the number of remaining records is not exactly one, senders MUST assume TLS-RPT is not implemented for the domain. Two independently published TLS-RPT policies are therefore not a valid way to request two destinations. Multiple character strings within one TXT resource record are a different DNS representation issue, not automatically multiple policy records. Check the returned resource-record boundaries, remove unintended duplicate policy records through the approved DNS change process, and then repeat discovery before diagnosing collector delivery. No DNS change or discovery query was executed for this article. TLS-RPT record selection
Understand what multiple destinations promise
Publishing two destinations does not guarantee two identical copies of every report. RFC 8460 allows a reporter to attempt each supported URI, but it may choose only one. A report should not be considered successfully delivered until an endpoint accepts it. Treat multiple URIs as supported delivery options rather than an assured fan-out or audit-replication mechanism.
If the business requires a durable central archive plus an operational dashboard, design that retention within an approved collector workflow. Do not infer it from two rua values. Record which component is the system of record and how a missing dashboard item can be traced back to its received report identifier.
Keep URI syntax exact. The standard requires encoding delimiters such as commas, exclamation marks and semicolons when they occur within a URI. A malformed address or endpoint path can prevent collection even though a DNS editor accepts the TXT record. Preserve the complete logical TXT value; multiple strings in one record are concatenated without inserted spaces under the specification. Reporting policy grammar
Establish the mailbox delivery contract
For mailto delivery, the collector needs a functioning mailbox or ingestion address that accepts the expected report messages. RFC 8460 defines a multipart/report message with a machine-readable JSON or gzip part and TLS-specific metadata. Confirm that forwarding rules, attachment inspection and quotas do not silently discard the machine-readable payload before the parser sees it. Email report transport
Reports delivered over SMTP must have a valid DKIM signature from the reporting domain, and a recipient must ignore reports without that signature. The signature must not use the l= body-length limitation. The reporting key should declare the tlsrpt service type; a receiver may ignore a report without that declaration. Distinguish these report-integrity checks from SPF, DKIM and DMARC results for the ordinary business messages being transported. Report-signature requirements
The reporting channel intentionally avoids a failure loop: SMTP report delivery must proceed despite TLS-related failures and must not honor MTA-STS or DANE TLSA failures for the report itself. Such a report can therefore arrive without encrypted transport. Do not put confidential message contents into diagnostic attachments or assume the reporting channel has the same transport guarantees as an enforced business-mail route.
Establish the HTTPS delivery contract
For https delivery, the reporter submits a POST to the declared endpoint. The receiving server must return a successful HTTP response, typically 200 or 201. It may store the report for later processing; acceptance is not proof that parsing, attribution or dashboard display completed. Monitor those later stages separately. HTTPS report transport
The standard permits report submitters to ignore HTTPS certificate-validation errors when delivering reports. This is a reporter permission intended to preserve failure visibility, not a recommendation to run a broken collector certificate. Keep the collector's TLS configuration sound and distinguish this rule from MTA-STS policy fetching, which has its own certificate-validation requirements.
Gzip compression is recommended for both email and HTTPS reports. RFC 8460 mentions a commonly observed receiver size limit as motivation, not a universal maximum that every collector must support. Obtain the actual collector's documented compressed and expanded size limits and protect parsing against oversized or malicious input. Treat reports as untrusted data; never evaluate their contents as commands. Compression and security considerations
Set realistic timing and failure expectations
Reports should cover a full UTC day, and delivery should be delayed to reduce synchronized load. The specification gives an illustrative randomized delay, not a guaranteed receipt deadline. It does not promise a report from every sender every day. Do not diagnose a collector failure solely because a newly published destination has no message within a few minutes.
After delivery failure, a sender should attempt redelivery for up to 24 hours after the first attempt, ideally with exponential backoff. Reports remain optional, so this is not a guarantee that a lost report will be retried or eventually arrive. Use collector ingress logs, queue state and processing results to distinguish transport acceptance from end-to-end ingestion. Reporting time frame and retries
Retain the report's internal metadata as the authoritative interpretation when it differs from subject or filename metadata. Track report identifiers and reporting organizations to identify duplicates. Do not add retries or duplicate files to delivery-success totals as if they were independent transport observations.
Destination acceptance worksheet
Complete this proposed contract before authorizing a publication or collector migration.
- Scope: policy domain ___; destination owner ___; approved reporting purpose ___; data recipient and retention decision ___.
- Publication: exact _smtp._tls owner ___; single intended policy record ___; logical TXT content ___; supported URI schemes and encoding ___.
- Mailto path: ingestion address ___; mailbox/quota handling ___; DKIM validation ___; attachment and gzip processing ___.
- HTTPS path: exact POST endpoint ___; successful acknowledgment behavior ___; storage queue ___; parser limits ___; certificate owner ___.
- Observability: ingress reference ___; report organization/id/time range ___; parse result ___; domain attribution ___; dashboard or archive result ___.
- Timing: expected UTC reporting period ___; known sender participation ___; retry assumptions ___; missing-report escalation ___.
- Migration: old and new destination owners ___; overlap and retention plan ___; changed record evidence ___; final acceptance decision ___.
No delivery has been performed for this worksheet. A test must be separately authorized and must distinguish a synthetic collector check from a genuine sender-generated report.
Fictional example: the second inbox is empty
This scenario is fictional. A domain publishes two mailto URIs, expecting one report in its security mailbox and another in a vendor dashboard. A participating sender delivers successfully to the vendor endpoint only. The security team treats its empty mailbox as evidence that TLS-RPT failed.
The proposed investigation checks the accepted report at the vendor and compares the configured URIs with RFC 8460's multiple-destination behavior. The team changes its archival design rather than accusing the sender of violating a guaranteed duplication rule. It then documents collector ownership and the distinction between receipt, parsing and display. Independent review, actual delivery evidence, visual checks and owner release remain pending for this draft.