# TLS-RPT (SMTP TLS Reporting): Definition and How It Works

Source: https://wraps.dev/glossary/tls-rpt

AuthenticationSMTP TLS ReportingTLS reporting record

TLS-RPT (RFC 8460) is a DNS record naming an address that receives daily aggregate reports of SMTP transport-security failures against your domain, the reporting half of MTA-STS.

## The record and what it points at

TLS-RPT lives at \`\_smtp.\_tls.<domain>\` as a DNS TXT record, starting with \`v=TLSRPTv1\` and a \`rua=\` tag naming one or more report destinations, most commonly a \`mailto:\` address. The shape is deliberately similar to DMARC's own \`rua=\` reporting mechanism — a familiar pattern applied to a different layer of the mail path.

## It reports failures MTA-STS and DANE can't tell you about directly

Without TLS-RPT, a domain enforcing MTA-STS or DANE has no visibility into how often connecting mail servers actually fail to meet the policy — a sending server that cannot negotiate a compliant TLS session to you simply queues, retries, or eventually bounces the message, and nothing tells the receiving domain's operator that it happened. TLS-RPT closes that by having every reporting sender publish daily aggregate statistics: how many sessions succeeded, how many failed, and broken down by failure type and by which sending system.

## What actually shows up in a report

Reports are JSON, aggregated per day and per reporting sending domain, and categorize failures — certificate expired, certificate mismatch, no supported TLS version, MTA-STS policy fetch failure, and so on — rather than reporting on individual messages. It is a health signal on the transport layer, not a message-level audit trail, which is exactly the granularity that matters for spotting a misconfigured MX host or an expiring certificate before it becomes a delivery outage.

## It is worth almost nothing without MTA-STS or DANE already deployed

TLS-RPT reports on enforcement outcomes for policies that already exist. Publishing a TLS-RPT record with no MTA-STS policy and no DANE (DNSSEC-backed TLSA records) in place gives you reports about opportunistic STARTTLS behavior that nobody is actually required to honor, which is a much thinner signal than reports about an enforced policy.

## Why it matters

Transport-layer failures are otherwise invisible from the receiving side — a sender that cannot deliver over the required TLS configuration to you does not notify you, it just fails silently from your point of view. TLS-RPT is the only standard mechanism that turns that into a report you can actually read and act on.

## How to check it

```
dig +short TXT _smtp._tls.example.com
```

## Common questions

### Do I need MTA-STS for TLS-RPT to be useful?

You get far more out of it with MTA-STS (or DANE) already deployed. Without an enforced policy, TLS-RPT reports on opportunistic STARTTLS behavior that nobody was required to follow, which is a much weaker signal than reports on actual policy violations.

### Is TLS-RPT the same mechanism as DMARC reporting?

They share a shape — both are daily aggregate reports sent to a mailto: address named in a DNS record — but they report on different things. DMARC reports on message authentication outcomes; TLS-RPT reports on transport-layer encryption outcomes.

### What kind of failures show up in a TLS-RPT report?

Certificate problems, unsupported TLS versions, and MTA-STS policy fetch failures are the common categories, aggregated per day and per sending domain rather than reported per message.