What is TLS-RPT?

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) is an email security standard defined in RFC 8460 that enables receiving mail servers to send diagnostic reports about TLS negotiation failures back to the domain owner. It is the reporting companion to MTA-STS (Mail Transfer Agent Strict Transport Security).

When a sending mail server attempts to deliver email to your domain and cannot establish a valid TLS connection — whether due to a certificate error, a TLS version mismatch, or an MTA-STS policy violation — TLS-RPT allows you to receive a JSON report describing what happened.

Why TLS Visibility Matters

Without TLS-RPT, TLS negotiation failures are invisible to domain owners. A sending server that cannot verify your TLS certificate may fall back to plaintext or drop the message entirely — with no notification to you. TLS-RPT closes this gap with structured daily reports that show:

• How many connections succeeded or failed
• The failure type (certificate expired, policy mismatch, etc.)
• Which sending mail servers were affected
• The MX hostnames that were involved

How to Set Up TLS-RPT

TLS-RPT is enabled by publishing a DNS TXT record at _smtp._tls.yourdomain.com:

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

• v=TLSRPTv1 — version tag (required).
• rua= — the reporting URI. Accepts either a mailto: address or an https: endpoint that accepts POST requests.

You can specify multiple reporting URIs separated by commas. Reports are sent daily in gzip-compressed JSON format.

TLS-RPT Report Structure

Reports arrive as .json.gz files with a defined schema. Each report contains:

• organization-name: The sending organization generating the report.
• date-range: The UTC time window (start and end timestamps) covered by the report.
• contact-info:The reporting organization's contact email.
• policies: An array of policy records, each describing the MTA-STS or DANE policy in effect and the results for that policy.
• summary: Total successful session count and total failure session count.
• failure-details: Array of failure records with result type, sending MTA IP, receiving MX hostname, and count.

Relationship with MTA-STS

TLS-RPT and MTA-STS are designed to work together. MTA-STS tells sending servers to require valid TLS for your domain; TLS-RPT reports back when TLS negotiation fails. You can deploy TLS-RPT without MTA-STS to monitor opportunistic TLS, but deploying MTA-STS without TLS-RPT leaves you blind to enforcement failures. The recommended approach: deploy MTA-STS in testing mode, review TLS-RPT reports, then promote to enforce once reports are clean.

Common TLS-RPT Failure Types

• starttls-not-supported: The receiving server did not advertise STARTTLS support. Often indicates a misconfigured MX host.
• certificate-host-mismatch: The TLS certificate presented does not match the MX hostname. Typically a certificate configuration error.
• certificate-expired: The TLS certificate has passed its expiry date. Critical to resolve immediately.
• certificate-not-trusted: The certificate chain does not lead to a trusted root CA. Often occurs with self-signed certificates.
• sts-policy-fetch-error: The sending server could not retrieve your MTA-STS policy file. Check HTTPS availability.
• sts-policy-invalid: The MTA-STS policy file contains syntax errors or invalid fields.

Frequently Asked Questions

Do I need MTA-STS to use TLS-RPT?

No. TLS-RPT is independent of MTA-STS and will report opportunistic TLS failures without any MTA-STS policy in place. That said, the two standards work best together — MTA-STS enforces TLS and TLS-RPT monitors the enforcement.

How often are TLS-RPT reports sent?

RFC 8460 specifies that sending MTAs should generate and send reports once per day per policy per reporting domain. Large senders like Google and Microsoft send reports for all domains they attempt to deliver to, so most active domains will receive daily reports from multiple providers once TLS-RPT is configured.

Where should I send TLS-RPT reports?

You can use any email address you control, but processing raw JSON reports manually is impractical. Using a dedicated email security platform — or configuring an HTTPS endpoint — allows automated parsing and alerting. DDMARC supports TLS-RPT report ingestion and provides a dashboard for visualizing failures over time.