TLS-RPT

TLS-RPT (RFC 8460) is the reporting half of inbound-mail TLS hardening. Sending MTAs send you daily JSON reports about TLS handshake failures and MTA-STS policy violations they hit while delivering mail to your domain. Without TLS-RPT, you have no visibility into delivery failures during MTA-STS rollout (or any other TLS issue), and you are flying blind when you switch MTA-STS from testing to enforce mode. RedScore passes when a v=TLSRPTv1 record exists with at least one rua= destination.

This check only runs when your domain has a non-null MX. If you have only a null MX or no MX, it shows as not applicable rather than failing.

How the verdict maps to evidence

• Pass: a v=TLSRPTv1 TXT record exists at _smtp._tls.yourdomain.tld with a rua= destination.
• Warn: a TLS-RPT record exists but rua= is not set.
• Fail: no v=TLSRPTv1 TXT record at _smtp._tls.yourdomain.tld.

Fail or warn: publish a record with rua=

TLS-RPT is a single TXT record. The rua= tag points at one or more destinations that receive daily JSON reports. Destinations can be mailto: addresses or https: endpoints. Most operators use mailto: with a managed reporting service.

_smtp._tls.yourdomain.tld.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.tld"

_smtp._tls.yourdomain.tld.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.tld,mailto:abc123@tlsrpt.postmarkapp.com"

Choosing a reporting destination

Same options as DMARC reporting:

• Self-hosted parser. Point rua= at a mailbox like tlsrpt@yourdomain.tld and parse the JSON attachments yourself. parsedmarc handles TLS-RPT alongside DMARC.
• Managed service. Most DMARC platforms (dmarcian, EasyDMARC, Postmark, Valimail, Red Sift OnDMARC) also accept TLS-RPT and surface failures in the same dashboard.
• https: endpoint. RFC 8460 supports HTTPS POST destinations, but adoption among major receivers is uneven. mailto: is the safer default today; if you need HTTPS, list a mailto: as a fallback in the same record.

Verify the fix

• Run dig +short TXT _smtp._tls.yourdomain.tld @1.1.1.1 and confirm v=TLSRPTv1 with a rua= destination.
• Wait 24 to 48 hours for the first reports. Reports arrive daily from receivers that delivered mail to you in the previous day, so a low-traffic domain may take longer.
• Open the destination mailbox or dashboard and confirm reports are arriving. Each report is a JSON file describing successful and failed connection attempts per sending MTA.
• If you have published MTA-STS in testing mode, look here for policy-failure entries before flipping MTA-STS to enforce.
• Re-run the RedScore lookup.

Common pitfalls

• TLS-RPT without MTA-STS or DANE. The record is still useful (you see opportunistic-TLS failures), but the highest value comes from pairing it with a TLS-enforcing policy. Publish MTA-STS too if you can.
• Reporting mailbox on a non-DMARC-compliant domain. Same as DMARC: receivers refuse to send reports to mailboxes on domains that fail DMARC. Use a domain that passes DMARC for the mailbox.
• Forgetting to parse the reports. Like DMARC, TLS-RPT JSON is unreadable by humans and accumulates fast. Set up a parser or managed service before publishing.
• Wrong host label. The record lives at _smtp._tls.yourdomain.tld (note the underscores and the order). _tls._smtp or _tls-rpt are common typos.
• Multiple TLS-RPT records. Like SPF and DMARC, TLS-RPT allows exactly one record at _smtp._tls. Two or more makes the entire policy permerror at receivers.
• Trusting a single rua= mailbox without monitoring. If the mailbox fills up, gets renamed, or its parser breaks silently, you stop noticing TLS failures. Set an alert on "no reports arrived in 7 days" if your traffic is normally steady.