TLS-RPT record has a syntax error
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.
Rebuild the record in the generator and publish it as one TXT record.
Delete any other
_smtp._tlsTXT records.
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.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.