TLS-RPT record has no reporting destination

What triggers this finding

Three situations produce it:

• The rua tag is absent entirely. Usually a record that was half written, or one where a destination was removed when a mailbox got decommissioned and nobody replaced it.
• The rua tag is present but contains nothing parseable as a URI. The most frequent version is a bare email address: rua=tlsrpt@example.com rather than rua=mailto:tlsrpt@example.com. The scheme is not optional. Without it there is no URI, just a string.
• The rua uses an unsupported scheme. Only mailto: and https: are defined. Plain http:, ftp:, or anything else is not a valid destination.

How to fix it

Add at least one destination with an explicit scheme:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

For an HTTPS collector, or for more than one destination, list them comma-separated inside the single rua value:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/v1/tlsrpt"

Add destinations inside the existing rua. Do not publish a second TXT record for the second destination. If two records at _smtp._tls both start with the version tag, senders treat the domain as not implementing TLS-RPT at all - adding a destination that way silently disables the mechanism you were trying to extend.

Choosing between mailto and https

mailto: Delivers the report as an email - a multipart/report message with a human-readable part and the JSON attached, gzipped in most cases. Setup is trivial: create a mailbox, point the record at it. Reports carry TLS-Report-Domain and TLS-Report-Submitter headers, so filtering by report domain is a header match. The subject line follows a defined structure containing the report domain, submitting domain, and a report ID - natural deduplication keys.

https: Senders POST the report to a URL you control and expect a 2xx status back. Suits teams that already run an ingestion pipeline. One quirk: report submitters are explicitly permitted to ignore certificate validation errors when POSTing reports. That is deliberate - a domain with a broken mail TLS setup quite plausibly has broken web TLS too, and refusing to deliver would suppress the diagnostic you need. Do not read a successfully delivered report as evidence your collector's certificate is valid.

Verify the DKIM signature on inbound reports

This gets skipped constantly, and it is the difference between a reporting pipeline and an unauthenticated data feed.

Reports delivered over SMTP must carry a valid DKIM signature from the reporting domain, and reports arriving without one are meant to be discarded. The spec also says the signature must not use the l= body length tag, which would otherwise let someone append content to a report without breaking the signature. A DKIM record used for TLS-RPT reporting should carry s=tlsrpt.

The reason to care: your reporting endpoint is published in DNS for anyone to read. Without signature verification you are ingesting attacker-controlled JSON into a system that probably parses it automatically and may display it on a dashboard. Fabricated reports could mask a real attack or manufacture a fake one.

Send reports to a tool, not a person

Reports arrive daily from every sender that implements the mechanism, and the large mail providers do. The volume is small but constant, and the payload is compressed JSON. A human inbox is not a reporting pipeline. It becomes a folder of unopened attachments within a month.

Most teams point TLS-RPT at whatever service already handles their DMARC aggregate reports. The operational shape is the same: daily aggregate JSON from many senders, needing parsing, storage, and trend visualisation rather than individual review. The useful output is not individual reports - it is trend data. A single certificate-expired entry from one sender is noise. The same result type appearing across multiple independent senders on the same MX host is a real finding.

A note on where to host the mailbox

Advice to host the reporting mailbox on an unrelated domain circulates widely, usually justified by the idea that reports about a TLS failure cannot be delivered through the failing TLS. The spec addresses that specific case directly: senders must deliver TLS-RPT reports even when TLS to your domain is failing, and must not honour MTA-STS or DANE failures while doing so. The broader argument still stands though - if your mail platform is down, the reports explaining why should not be sitting behind the same outage.