TLS-RPT check: verify your published reporting record
ChatGPT
Claude
Gemini
Perplexity
GrokIn brief
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.
At a glance
Quick takeaways
- TLS-RPT is defined by RFC 8460, 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=TLSRPTv1and uses theruatag to name one or more report destinations. - RFC 8460 permits
mailtoandhttpsreport 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 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 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 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.
_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 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.
v=TLSRPTv1; rua=mailto:reports@yourdomain.com,https://reports.yourdomain.com/v1/tlsrptFor 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.
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.
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.
_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 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.
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.comthrough the authoritative DNS service and a public resolver. Confirm the TXT value begins withv=TLSRPTv1and inspect the completeruavalue. - Record interpretation: Run the MTA-STS and TLS-RPT checker 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 applicables=tlsrptdeclaration. 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.
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 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.
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.
Evidence
Sources and further reading
Questions readers ask
Frequently asked questions
Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, AI-first DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →
