TLS-RPT Lookup
SMTP TLS Reporting (TLSRPT) record.
Enter a value above to run TLS-RPT Lookup
e.g. example.com
Quick answer
TLS-RPT Lookup reads the TXT record at _smtp._tls.<domain> and shows where daily reports about TLS delivery failures to your mail servers are sent. The rua= tag holds the destination, usually a mailto: address or https: endpoint that collects the aggregate reports.
TLS-RPT Lookup reads the SMTP TLS Reporting policy that a domain publishes at _smtp._tls.<domain> as a DNS TXT record. This record tells sending mail servers where to send daily aggregate reports about the success or failure of TLS-secured SMTP connections. It is the reporting companion to MTA-STS and DANE. Use this tool to confirm your TLSRPT record exists, is syntactically correct, and points to a mailbox or HTTPS endpoint that can actually receive the reports.
How it works
The tool queries the DNS name _smtp._tls.example.com and returns the TXT record found there. A valid TLSRPT record starts with v=TLSRPTv1 and includes a rua= tag listing one or more report destinations, either a mailto: address or an https: URL, separated by commas. Sending servers that support TLS reporting read this record, batch connection outcomes for the day, and send a JSON report to each destination you list.
How to read the results
Check that exactly one TXT record is returned and that it begins with v=TLSRPTv1. Multiple TLSRPT records are invalid and reporting senders will ignore them. Confirm the rua= value uses a full scheme, for example mailto:[email protected] or https://reports.example.com/tlsrpt. If the mailbox lives on a different domain, that domain may need to authorise reports for yours. An empty result means no policy is published yet.
Why it matters
MTA-STS and DANE fail silently by design: if TLS negotiation breaks, mail may be deferred or delivered insecurely without anyone noticing. TLSRPT is how you find out. The daily aggregate reports reveal certificate expiries, STS policy mismatches, downgrade attempts, and misconfigured relays before they turn into lost or intercepted email. Without a TLSRPT record you have a policy but no visibility into whether it is working.
Frequently asked questions
- Do I need MTA-STS or DANE before adding TLSRPT?
- Not strictly. A TLSRPT record on its own asks senders to report TLS connection outcomes, which is still useful data. However, the reports are most meaningful when you also enforce a policy with MTA-STS or DANE, since that is when failures indicate real problems worth investigating rather than ordinary opportunistic TLS behaviour.
- What is the difference between TLSRPT and DMARC rua reports?
- They cover different layers. DMARC reports describe SPF and DKIM authentication results for messages. TLSRPT reports describe the transport encryption of the SMTP connection itself, whether STARTTLS succeeded and whether the certificate matched. You can send both to the same mailbox, but they answer separate questions and use different report formats.
- Why am I not receiving any TLSRPT reports?
- Common causes are a missing or malformed record, a rua destination with no scheme, or a receiving mailbox that rejects the reports. Reports are also sent only by senders that support TLS reporting, and only once per day, so low mail volume means few or no reports. Verify the record here first, then confirm the destination accepts inbound JSON reports.