TLS-RPT record has a syntax error
Updated
What this check looks for
The record exists but cannot be read, so no reports are sent. You have the appearance of TLS reporting without the reporting.
Why it matters
You would only discover this when you went looking for a report that was never going to arrive — usually during an incident.
When the check passes, your report says: “The TLS-RPT record parses, so the reports are actually sent”.
What it costs your score
When this check fails it removes 4 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.
It shares the email-transport.tls-rpt family ceiling of 10 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 4 points
- Family cap
- email-transport.tls-rpt · 10
- Category
- Email transport
- Module
- Email tls rpt
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Republish a single, valid TLS-RPT record.
An invalid record produces no reports at all.
Read what is published with
dig +short TXT _smtp._tls.‹domain›.Rebuild the record in the generator and publish it as one TXT record.
Delete any other
_smtp._tlsTXT records.Give a reporting service its address inside your single
rua=tag, separated from yours by a comma, rather than a record of its own.
How to confirm it worked
dig +short TXT _smtp._tls.‹domain› — expect exactly one v=TLSRPTv1 record
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
Parsing _smtp._tls.‹domain› failed: ‹parse error›. RFC 8460 §3 requires v=TLSRPTv1 as the first tag followed by a rua= tag; the value is a comma-separated list of mailto: or https: URIs. Multiple TLSRPT records at the same name are also invalid.
A well-formed record is one TXT value such as v=TLSRPTv1; rua=mailto:tls-reports@example.com. Tags are separated by semicolons, the version is case-sensitive, and each rua destination carries its scheme: a mailto: address receives each day's report as a compressed JSON attachment, and an https: address receives it as a POST. Unlike DMARC, a reporting address at another domain needs no authorisation record from that domain.
The usual faults are a missing semicolon between tags, an address written without mailto:, typographic quotes or invisible characters carried over from a document, and a second record added by a reporting service beside the original. When more than one record at _smtp._tls begins with v=TLSRPTv1, senders are told to treat the domain as having none, so adding a record never adds a destination.
The reports matter most beside MTA-STS. They are how you learn that a sender could not set up TLS to one of your MX hosts — before you switch an MTA-STS policy to enforce, and afterwards, when a lapsed certificate would otherwise surface only as mail that stopped arriving.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.