TLS-RPT record has invalid syntax

How serious this is

DNSAudit flags this as Informational, not as a warning or a failure. TLS-RPT is a reporting mechanism. It does not encrypt anything or block anything. A broken record leaves your domain in exactly the same security position as a domain with no record at all, and a missing record is itself only informational. So a broken record cannot honestly carry a higher security severity than a missing one.

What makes it worth surfacing is that it is an unambiguous mistake rather than a choice. Someone deployed TLS-RPT and it silently does not work, and nothing else will ever tell them. That is a fix worth making. It is just not a security exposure.

The grammar, precisely

A TLS-RPT record (RFC 8460) is a TXT record made of semicolon-separated tag=value pairs. Two rules govern whether it is valid:

• The record must begin with v=TLSRPTv1. This is case-sensitive as specified, and it must be first - not merely present somewhere in the string.
• There must be at least one rua tag. The spec marks it required, so a record with a valid version tag and nothing else is incomplete.

That is the entire mandatory grammar:

v=TLSRPTv1; rua=mailto:tlsrpt@example.com

TLS-RPT looks like DMARC but has a different tag set. There is no p, no sp, no pct, no ruf, no adkim, no aspf. The whole vocabulary is v, rua, and extension tags. RFC 8460 requires parsers to ignore unrecognised fields, so a stray p=none copied in from a DMARC record does not invalidate the record - but it does signal it was pasted from a template.

What actually breaks a record

Every breaking case comes back to the two mandatory rules:

Wrong or missing version tag

v=TLSRPT1, v=TLSRPTv1.0, v=TLSRPTV1, or a record starting with rua= and no version at all. Senders discard any TXT at that name not beginning with the version tag, so a typo here produces a record that does not exist as far as the mechanism is concerned.

Version not first

rua=mailto:tlsrpt@example.com; v=TLSRPTv1 contains everything needed and still fails, because the version has to lead.

Broken tag separators

Tags are separated by semicolons. Using commas between tags is a common slip, because commas are the correct separator inside a rua list, so the two get confused. v=TLSRPTv1, rua=mailto:... is not valid.

More than one TLS-RPT record at the same name

Senders first discard every TXT at _smtp._tls that does not start with the version tag. If what remains is not exactly one record, the sender must treat the domain as not implementing TLS-RPT. Two valid records is not belt-and-braces - it turns the whole mechanism off. This is the most common way a well-intentioned change breaks a working deployment: someone adds a second destination by publishing a second record instead of adding a second URI to the existing rua.

Unencoded reserved characters inside a URI

Commas, semicolons, and exclamation points inside a URI must be percent-encoded. An unencoded comma will be read as the boundary between two URIs, producing two malformed destinations instead of one working one.

String-splitting damage

DNS splits long TXT records into multiple character strings of up to 255 bytes. The strings are concatenated with nothing inserted between them before parsing. A stray space at the join, or a missing space before a tag, produces a mangled token. A TLS-RPT record is short enough that it should not normally need splitting at all.

How to check what is actually published

Query the record directly rather than trusting the DNS provider's UI, which often normalises or re-quotes what you typed:

dig +short TXT _smtp._tls.example.com

Read the output carefully: is there exactly one record starting with v=TLSRPTv1? Are the tag separators semicolons? To see raw strings including how they were split:

dig TXT _smtp._tls.example.com

And to check against the authoritative servers rather than a cache:

dig +norecurse TXT _smtp._tls.example.com @<your-authoritative-ns>

How to fix it

Replace whatever is there with a single clean record:

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

Delete any other TXT records at that name that start with the version tag. If you need multiple destinations, add them inside the one rua value, comma separated, rather than publishing a second record. Then re-scan - if the record now parses but has no usable destination, you will see the reporting destination finding instead. Allow a couple of days after fixing before concluding that a corrected record still is not working, since reports cover a full UTC day and are typically sent some hours after that period closes.