# TLS-RPT reporting: how to read SMTP TLS reports

> TLS-RPT reporting explains the JSON reports sent for SMTP TLS failures, their result types, delivery format, cadence, and how to interpret them.

TLS-RPT reporting lets a receiving domain learn how other mail systems experienced SMTP TLS connections to its MX servers. [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.txt) defines the JSON report format, result types, delivery methods, and reporting cadence. TLS-RPT is optional, with no protocol operative date or verified mailbox-provider mandate to publish a TLS-RPT record.

## Quick takeaways

- TLS-RPT is defined by RFC 8460, a Standards Track RFC published in September 2018.
- A TLS-RPT report can show successful TLS sessions as well as failed sessions.
- Reports identify the policy evaluated, session totals, and failure details when available.
- The reporting sender SHOULD cover a full UTC day and delivers the report after a delay.
- TLS-RPT works with MTA-STS, DANE, or cases where neither policy was found.
- A published TLS-RPT record tells senders where to send reports. It does not prove that reports will arrive or that mail delivery is healthy.

## Who is affected?

TLS-RPT applies to domains that publish a TLS-RPT DNS record and ask other mail systems to send SMTP TLS reports to the record's `rua` destination. Under [RFC 8460 section 2](https://www.rfc-editor.org/rfc/rfc8460.txt), sending domains compatible with MTA-STS or DANE can report their TLS connection experience to recipient domains.

The receiving domain publishes the reporting destination. The sending domain evaluates the recipient's transport security policy and may create a report for that destination. Microsoft documents that [Exchange Online sends TLS-RPT reports in JSON format](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email), so a report can come from a major sender without indicating that the sender or recipient has made an error.

TLS-RPT is a companion to MTA-STS, not a prerequisite for it. A TLS-RPT report can use `no-policy-found` when neither DANE nor an MTA-STS policy was found. For the transport policy itself, see [what MTA-STS is](/learning/what-is-mta-sts). For the Google-specific reason reports may arrive, see [why Google sends MTA-STS TLS reports](/learning/google-mta-sts-tls-reports).

## What are the requirements?

### A TLS-RPT record supplies a reporting destination

RFC 8460 defines a DNS TXT record at `_smtp._tls.<domain>`. Its `rua` tag contains one or more `mailto` or `https` destinations for reports.

```text
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"
```

This is an illustrative record shape only. Publish the reporting address or HTTPS endpoint that your organization controls.

The RFC requires the version tag `v=TLSRPTv1`. The `rua` value tells a reporting sender where it may deliver the report. It does not require a sender to generate a report, and it does not establish an MTA-STS policy. See [what `v=TLSRPTv1` means in a TLS-RPT record](/learning/glossary/tls-rpt-v-tlsrptv1) for the record-specific explanation.

![TLS-RPT reporting flow from a published DNS record to a reporting sender and a JSON report destination](/images/editorial/tls-rpt-reporting/tls-rpt-reporting-flow.webp "1200x829")

*Source: Palisade.*

### The report uses the RFC 8460 JSON schema

RFC 8460 section 4 defines an I-JSON report containing the reporting organization, the covered date range, a report ID, and policy results. Each policy entry includes a policy type, policy domain, MX host information, session totals, and optional failure details.

```json
{
  "organization-name": "Example Mail Sender",
  "date-range": {
    "start-datetime": "2026-08-12T00:00:00Z",
    "end-datetime": "2026-08-13T00:00:00Z"
  },
  "contact-info": "tls-reporting@example.net",
  "report-id": "example-report-id",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: enforce"],
        "policy-domain": "yourdomain.com",
        "mx-host": ["mail.yourdomain.com"]
      },
      "summary": {
        "total-successful-session-count": 125,
        "total-failure-session-count": 2
      },
      "failure-details": []
    }
  ]
}
```

The values above are illustrative only. Do not treat the example as a report received for a real domain.

Start with `total-successful-session-count` and `total-failure-session-count`. A report with successful sessions is also a heartbeat that TLS negotiation occurred as expected. A nonzero failure count needs investigation, but it does not identify the exact affected message unless the report's failure details contain enough evidence.

### Result types classify the connection failure

RFC 8460 section 4.3 defines result types for the failure details in a report. Negotiation failures include `starttls-not-supported`, `certificate-host-mismatch`, `certificate-expired`, `certificate-not-trusted`, and `validation-failure`.

DANE-specific result types include `tlsa-invalid`, `dnssec-invalid`, and `dane-required`. MTA-STS-specific types include `sts-policy-fetch-error`, `sts-policy-invalid`, and `sts-webpki-invalid`. The RFC also defines general and transient failures.

For `certificate-not-trusted` and `validation-failure`, RFC 8460 directs the reporting sender to provide more detail in `failure-reason-code`. Treat that field as sender-provided diagnostic context. It is useful evidence, but it does not replace checking the certificate, DNS, MX service, and production delivery path.

### Email delivery has a defined wrapper and filename

RFC 8460 section 5 permits report delivery by email or HTTPS. A report filename follows this shape:

```text
sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json
sender!policy-domain!begin-timestamp!end-timestamp[!unique-id].json.gz
```

The timestamps are seconds since the Unix epoch. The RFC permits gzip compression for `.json.gz` files.

For email delivery, the message is `multipart/report` with `report-type="tlsrpt"`. The machine-readable part is `application/tlsrpt+json` or `application/tlsrpt+gzip`. The `TLS-Report-Domain` and `TLS-Report-Submitter` header fields MUST be included, which makes them useful filters in the mailbox receiving reports.

## When does the requirement take effect?

RFC 8460, "SMTP TLS Reporting," was published in September 2018 as a Standards Track RFC. It is the controlling specification for TLS-RPT reporting.

There is no operative date because TLS-RPT publication is optional. This article does not establish a mailbox-provider enforcement date, because no provider requirement or delivery consequence was verified for publishing a TLS-RPT record.

RFC 8460 section 4.1 says a report SHOULD cover a full day, from `00:00-24:00 UTC`. It should arrive after a delay, perhaps several hours. The RFC gives an example of a random delay of up to four hours. Reports therefore commonly describe the preceding UTC day rather than a live connection state.

## How do I implement the requirement?

### 1. Choose a report destination

Choose a controlled `mailto` address or HTTPS endpoint that can receive machine-readable TLS-RPT reports. Define who reviews reports and where compressed JSON files are retained.

Do not use a shared mailbox without a sorting process. The data can include repeated policy and connection outcomes that need technical review.

### 2. Publish the TLS-RPT TXT record

Publish a `v=TLSRPTv1` TXT record at `_smtp._tls.yourdomain.com` with the chosen `rua` destination.

Query the authoritative DNS server and at least one public resolver after publishing. DNS visibility proves that the record is reachable. It does not prove that another sender will generate or deliver a report.

### 3. Classify the policy and result type

When a report arrives, identify its `policy-type` first. Keep MTA-STS, DANE, and `no-policy-found` findings separate because they describe different transport-policy contexts.

Then compare the summary totals with `failure-details`. Prioritize persistent certificate, MX hostname, policy-fetch, or DNSSEC errors before transient connection failures. A failure classification should lead to a same-path test against the affected MX service, not a speculative DNS edit.

### 4. Preserve evidence for the delivery path

Keep the original report attachment or HTTPS payload, its date range, reporting organization, and report ID. If the report was delivered by email, retain the message headers that identify the report domain and submitter.

Compare report findings with MX configuration, certificate state, MTA-STS policy retrieval where applicable, and logs from the affected mail service. A TLS-RPT report is aggregate evidence. It does not include every message-level detail needed to diagnose a single SMTP transaction.

## How do I validate compliance?

Validate the published record at the DNS layer by querying `_smtp._tls.yourdomain.com` through the authoritative server and a public resolver. Confirm that the returned TXT value contains `v=TLSRPTv1` and the intended `rua` destination.

Use the [MTA-STS Checker](/tools/mta-sts) to inspect the `_smtp._tls` record and its parsed reporting destination. The checker evaluates the published record, not report contents. Its valid result means a `v=TLSRPTv1` record exists. It cannot prove a reporting sender used the destination, monitor future reports, or show the production SMTP path.

At the report layer, inspect a received JSON payload for its UTC date range, policy domain, policy type, session totals, and failure details. At the service layer, compare reported failures with certificate and MX evidence. At the message layer, test a real delivered message from the exact production sending path where an SMTP TLS failure is suspected. If the domain uses DMARC, aggregate reports provide a separate view of message authentication, not transport TLS reporting.

## Check where TLS-RPT reports are configured

Before waiting for reports, check the `_smtp._tls` record and confirm that its `rua` destination is the address or endpoint your team expects.

[Check the TLS-RPT record with the MTA-STS Checker](/tools/mta-sts)

A record check cannot show what a received TLS-RPT report contains, prove a sender generated one, or establish a receiver's future delivery decision.

If you need help monitoring TLS-RPT findings across your domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=tls-rpt-reporting).

## Sources and further reading

- [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.txt)
- [Microsoft Learn: How DANE secures email in Exchange Online](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email)
- [What is MTA-STS?](/learning/what-is-mta-sts)
- [Infrastructure learning hub](/learning/infrastructure)

## Frequently asked questions

### What is in a TLS-RPT report?

A TLS-RPT report contains an organization name, date range, contact information, report ID, and a `policies` array. Each policy entry includes policy information, successful and failed TLS session totals, and optional failure details, as defined in RFC 8460.

### How often do TLS-RPT reports arrive?

TLS-RPT reports SHOULD cover a full day from `00:00-24:00 UTC`, according to RFC 8460. They arrive after a delay, perhaps several hours, so they are not real-time connection monitoring.

### What do TLS-RPT result types mean?

TLS-RPT result types classify why an SMTP TLS connection did not meet the relevant policy or validation condition. Examples include certificate hostname mismatch, expired certificates, MTA-STS policy fetch errors, and DANE DNSSEC failures. Check `failure-reason-code` when the report includes it for sender-provided detail.

### Who sends TLS-RPT reports?

A sending domain that implements compatible MTA-STS or DANE reporting behavior may send reports to the recipient domain's published `rua` destination. Microsoft documents that Exchange Online sends TLS-RPT reports in JSON format.

### Do I need MTA-STS to receive TLS-RPT reports?

No. RFC 8460 defines `no-policy-found` for cases where neither DANE nor an MTA-STS policy could be found. TLS-RPT is a companion to MTA-STS, but MTA-STS is not a prerequisite for receiving reports.