TLS-RPT reporting: how to read SMTP TLS reports

What are the requirements?

A TLS-RPT record supplies a reporting destination

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

_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 for the record-specific explanation.

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.

{
  "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:

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 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

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.