# TLS-RPT check: verify your published reporting record > TLS-RPT check: verify the published TLS reporting TXT record, read its rua value, and understand what a passing result does not prove for your domain. A TLS-RPT check looks for a DNS TXT record at `_smtp._tls.yourdomain.com` and confirms whether it declares `v=TLSRPTv1`. Any domain can publish this optional reporting policy. A passing DNS result shows that the record is visible and can expose its reporting destination, but it does not prove that reporting systems can deliver a report or that a report will arrive. ## Quick takeaways - TLS-RPT is defined by [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html), a final IETF RFC for reporting SMTP TLS connection failures. - The TLS-RPT record belongs at `_smtp._tls.` as a DNS TXT record. - A valid record begins with `v=TLSRPTv1` and uses the `rua` tag to name one or more report destinations. - RFC 8460 permits `mailto` and `https` report URIs. - TLS-RPT is optional and does not require an MTA-STS policy. - A published record check cannot prove that a receiver generated, signed, delivered, or that you received a report. ## Who is affected? TLS-RPT applies to domain owners who want reports about failures to establish TLS for SMTP delivery to their domains. It is intended as a companion to MTA-STS, but [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html) does not make MTA-STS a prerequisite. A reporting receiver can use the `no-policy-found` policy type when it found neither a DANE nor MTA-STS policy. The domain owner publishes the TLS-RPT DNS record and operates, or delegates, the destination named by `rua`. Sending systems decide whether to generate reports. The standard does not require every SMTP sender or mailbox provider to send them. This makes TLS-RPT useful for transport visibility, not as a guarantee of encrypted delivery. Read [what MTA-STS is](/learning/what-is-mta-sts) separately when you need to understand the policy that tells sending servers how to handle a TLS failure. TLS-RPT is part of the broader [email infrastructure and transport](/learning/infrastructure) work for a domain. It does not replace message authentication such as SPF, DKIM, or DMARC. ## What are the requirements? ### The record is published at the TLS-RPT policy name RFC 8460 defines a TLS-RPT policy record as a DNS TXT record at `_smtp._tls.`. The record starts with the version tag `v=TLSRPTv1`. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:reports@yourdomain.com" ``` This is an illustrative structure only. Publish the record under your own domain and use a report destination your team controls. A TLS-RPT check should query the exact `_smtp._tls` host, not the root domain's TXT records. A generic DNS lookup can display the raw TXT value, but the [DNS lookup tool](/tools/dns-lookup) does not identify the TLS-RPT owner name or interpret the policy tags for you. ### The `rua` tag names report destinations RFC 8460 requires a `rua` tag when the domain requests aggregate TLS reports. The tag contains one or more reporting URIs, separated by commas. Only `mailto` and `https` URI schemes are permitted by the standard. ```text v=TLSRPTv1; rua=mailto:reports@yourdomain.com,https://reports.yourdomain.com/v1/tlsrpt ``` For a `mailto` destination, RFC 8460 states: "Reports sent via SMTP MUST contain a valid DomainKeys Identified Mail (DKIM) signature by the reporting domain. Reports lacking such a signature MUST be ignored by the recipient." The RFC also says that the receiving domain's DKIM record `SHOULD` declare the `s=tlsrpt` service type. This is a report-delivery condition, not something a basic published-record check can establish. ### The record must identify TLS-RPT version 1 A TLS-RPT checker can identify a record when it finds `v=TLSRPTv1`. This verifies the policy version marker and lets the checker extract a `rua` value if one is present. It does not validate every operational property of the destination. For example, a record check does not prove that an `https` endpoint accepts reports, that a `mailto` destination can receive them, or that the receiving side will accept the reporting domain's DKIM signature. ![TLS-RPT publication checklist showing the DNS owner name, version tag, rua destination, and report-delivery limits](/images/editorial/tls-rpt-check/tls-rpt-check-checklist.webp "1200x582") *Source: Palisade.* ## When does the requirement take effect? There is no mailbox-provider TLS-RPT publication deadline or sender-volume threshold established by the sources for this article. TLS-RPT is an optional, receiver-driven protocol defined in final [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html). RFC 8460 was published in September 2018. It replaced the earlier Internet-Draft work on SMTP TLS reporting with a final RFC. Its reporting cadence is guidance rather than a delivery deadline: a report `SHOULD` cover a full day from `00:00-24:00 UTC` and should arrive after a delay, perhaps several hours. Expect a newly published record to appear in DNS according to its TTL, then allow at least a reporting day and delivery delay before treating an empty inbox as meaningful. Even then, a lack of reports does not prove that every sender attempted delivery or that every reporting system supports TLS-RPT. ## How do I implement the requirement? ### 1. Choose a report destination Decide whether reports should go to a mailbox through `mailto` or to an HTTPS endpoint. The destination needs to be owned and monitored by the team responsible for mail transport. For `mailto`, account for the DKIM requirement in RFC 8460. The report recipient must be able to accept mail signed by the reporting domain. Do not point `rua` at an address that cannot process XML report attachments or that is outside your team's control. ### 2. Publish the TLS-RPT TXT record Create the record at `_smtp._tls.yourdomain.com`, with `v=TLSRPTv1` first and a `rua` value containing the destination URI or URIs. ```text _smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=https://reports.yourdomain.com/v1/tlsrpt" ``` This is illustrative only. Use the hostname and endpoint generated for your own reporting service. Do not copy another organization's reporting address. DNS publication alone does not configure MTA-STS. If your objective includes enforcement instructions for sending servers, configure and validate that policy separately. ### 3. Check the published record Use the [MTA-STS and TLS-RPT checker](/tools/mta-sts) with the sending domain. The checker looks up `_smtp._tls.`, displays the TXT record on its TLS-RPT row, and extracts the reporting URI on its `Reports to (rua)` row. A result marked `Not configured` means the checker did not find a `v=TLSRPTv1` record for that domain. Because TLS-RPT is optional, this is not by itself evidence that SMTP transport is broken. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=tls-rpt-check) ### 4. Preserve the raw DNS evidence Keep the exact record value with the domain, query time, resolver, and DNS TTL in your change record. Querying an authoritative source and at least one public resolver helps separate a publishing problem from resolver propagation. If the record contains a `mailto` URI, also document which domain signs reports and where its DKIM `s=tlsrpt` service declaration is published. This is outside the basic DNS result, but it is necessary evidence for report acceptance. ## How do I validate compliance? Validate TLS-RPT at separate layers: - DNS: Query `_smtp._tls.yourdomain.com` through the authoritative DNS service and a public resolver. Confirm the TXT value begins with `v=TLSRPTv1` and inspect the complete `rua` value. - Record interpretation: Run the [MTA-STS and TLS-RPT checker](/tools/mta-sts) to confirm it finds the record and extracts the intended destination. - Report delivery: For `mailto`, inspect a received report's DKIM signature and the recipient domain's applicable `s=tlsrpt` declaration. For HTTPS, inspect endpoint logs for a received report. - Reporting behavior: Wait for the reporting interval described in RFC 8460 and compare received reports with known SMTP delivery activity. A green record result is DNS evidence only. It does not validate a URI scheme, prove the `mailto` DKIM prerequisite, test an HTTPS endpoint, or prove that any sender will generate a report. It also cannot show whether an individual SMTP connection used TLS successfully. If reports start arriving, use [Google MTA-STS TLS reports](/learning/google-mta-sts-tls-reports) for the adjacent task of understanding report delivery and related MTA-STS evidence. ## Check the published TLS-RPT record before relying on reports A published TLS-RPT record is the first evidence to collect when reports are missing or a new destination has been configured. Check the domain's `_smtp._tls` record and compare the displayed `rua` with the destination you intended to publish. [Check the TLS-RPT record](/tools/mta-sts) The check confirms that a public DNS lookup found `v=TLSRPTv1` and can extract `rua`. It does not prove report delivery, validate the destination service, monitor future DNS changes, or guarantee that a reporting sender will send data. ## Sources and further reading - [RFC 8460: SMTP TLS Reporting](https://www.rfc-editor.org/rfc/rfc8460.html) - [RFC 8460 text version](https://www.rfc-editor.org/rfc/rfc8460.txt) - [MTA-STS and TLS-RPT checker](/tools/mta-sts) - [What is MTA-STS?](/learning/what-is-mta-sts) ## Frequently asked questions ### How do I check whether my TLS-RPT record is published? Use the [MTA-STS and TLS-RPT checker](/tools/mta-sts) with your bare domain. It looks up `_smtp._tls.`, shows the TLS-RPT TXT record, and extracts the `rua` report destination when it finds `v=TLSRPTv1`. ### What does "Not configured" mean in a TLS-RPT check? It means the checker did not find a TLS-RPT record beginning with `v=TLSRPTv1` for the domain. TLS-RPT is optional under [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html), so the result does not by itself mean that mail delivery or TLS is failing. ### Does a passing TLS-RPT check mean I will receive reports? No. A passing check confirms the published DNS record, not report delivery. For `mailto` destinations, RFC 8460 requires reports sent through SMTP to carry a valid DKIM signature by the reporting domain, and recipients must ignore reports without one. ### How long until TLS-RPT reports start arriving? RFC 8460 says a report `SHOULD` cover a full UTC day and should arrive after a delay, perhaps several hours. Allow for DNS propagation, a reporting day, and delivery delay. A report may still not arrive if no reporting sender generates one. ### Do I need MTA-STS before TLS-RPT works? No. RFC 8460 defines a `no-policy-found` result for cases where neither DANE nor MTA-STS policy was found. TLS-RPT is intended to complement MTA-STS, but it can report transport outcomes without an MTA-STS policy. ### What should a TLS-RPT `rua` value look like? A `rua` value contains one or more comma-separated `mailto` or `https` URIs, as specified by [RFC 8460](https://www.rfc-editor.org/rfc/rfc8460.html). For example: `rua=mailto:reports@yourdomain.com` or `rua=https://reports.yourdomain.com/v1/tlsrpt`.