What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a DNS TXT record at _smtp._tls.yourdomain.com that asks sending mail servers to report, once a day, how many connections to your domain negotiated TLS and which ones failed your TLS policy, and why. It is the reporting companion to MTA-STS (Mail Transfer Agent Strict Transport Security): MTA-STS sets the policy, and TLS-RPT shows where senders could not meet it.

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, for example a mailbox and an HTTPS collector:

v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt

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.

A trimmed report for one day looks like this:

{
  "organization-name": "Example Sender Inc.",
  "date-range": {
    "start-datetime": "2026-10-01T00:00:00Z",
    "end-datetime": "2026-10-01T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@sender.example",
  "report-id": "2026-10-01T00:00:00Z_example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "example.com",
      "mx-host": ["mx1.example.com"]
    },
    "summary": {
      "total-successful-session-count": 5326,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "203.0.113.56",
      "receiving-mx-hostname": "mx1.example.com",
      "failed-session-count": 3
    }]
  }]
}

Read the summary first: a handful of failures among thousands of successful sessions is noise, while a failure count that matches your traffic means mail is not arriving. The result-type in failure-details says why.

TLS-RPT vs 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. Check your MTA-STS and TLS-RPT records to see whether both are already configured.

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.

What does an HTTPS reporting endpoint receive?

With an https: URI in rua=, senders POST each report to that URL with the content type application/tlsrpt+gzip, a gzip-compressed JSON document. A mailto: URI receives the same JSON as an email attachment instead. RFC 8460 lets you list both, and senders deliver each report to every address listed.

Sources

1. RFC 8460: SMTP TLS Reporting
2. RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)