TLS-RPT Lookup – Complete Guide to SMTP TLS Reporting Records

You deployed STARTTLS on your MX hosts, maybe MTA-STS as well. But how would you know if a certificate expired on the backup MX, if a sender could not validate your chain, or if your new MTA-STS policy is blocking mail from a large provider? Without reporting, those failures stay on the sender's side. TLS-RPT asks sending servers to tell you.

The TLS-RPT Lookup checks the record that makes this possible: the TXT record at _smtp._tls.<domain>. It reports whether a record exists, whether its version tag is correct, and whether every report destination is a valid mailto: or https: URI. Use it when you set up MTA-STS, when you change where reports go, or when you expect reports and none arrive.

What is TLS-RPT?

In simple terms

TLS-RPT is an address you publish for feedback about encrypted mail delivery. Senders that support it collect statistics on their TLS connections to your mail servers and once a day send you a report: how many connections worked and which ones failed, and why.

Technical background

SMTP TLS Reporting is defined in RFC 8460. The policy domain publishes a TXT record at _smtp._tls.<domain>:

v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.net/v1/tlsrpt

• v=TLSRPTv1 is required and must come first.
• rua lists one or more report destinations, comma-separated. A mailto: URI receives reports by email; an https: URI receives them by HTTP POST.

Reports are JSON documents covering a 24-hour window, usually gzip-compressed. They are organized per policy: an MTA-STS policy, a DANE TLSA policy or no policy. Each policy entry contains counts of successful and failed sessions and failure details such as certificate-expired, certificate-host-mismatch, starttls-not-supported or sts-policy-fetch-error, along with the receiving MX host and sending IP.

TLS-RPT does not change how mail is delivered. It only gives the receiving domain visibility, which is why it is normally deployed before or together with MTA-STS enforcement or DANE.

Why use TLS-RPT Lookup?

• Confirm the record exists before you rely on reports for an MTA-STS rollout.
• Catch syntax errors such as a wrong version string, a missing rua, a destination without mailto: or a non-HTTPS URL.
• Detect duplicate records, which make the policy invalid.
• Verify a change after switching to a report-processing service.

Who should use it?

• Mail administrators deploying MTA-STS or DANE for inbound mail.
• Security teams monitoring transport encryption for their domains.
• Anyone troubleshooting why TLS reports never arrive.
• Auditors documenting a domain's email security posture.

How TLS-RPT Lookup works

The NetTools.tech server queries the TXT records at _smtp._tls.<domain> through public resolvers (Cloudflare 1.1.1.1 and Google 8.8.8.8) and keeps the records starting with v=TLSRPTv1. It then checks:

1. Presence: no record produces a warning that you receive no TLS failure reports.
2. Uniqueness: more than one TLS-RPT record is an error.
3. Tag syntax: the record is parsed into tags; malformed tags are errors.
4. Version: v must be exactly TLSRPTv1.
5. Destinations: rua must be present, and each comma-separated entry must be a mailto: address or an https:// URL.

If all checks pass, the result lists where reports go. The operation has a 10-second time limit and is rate limited per client. It does not send anything to the report destinations.

How to use the NetTools.tech TLS-RPT Lookup

1. Open TLS Reporting (TLS-RPT).
2. Enter the Domain that receives mail, for example example.com. Do not add _smtp._tls; the tool builds the name.
3. Press Run TLS Reporting (TLS-RPT), or run /tls-rpt example.com in the terminal.
4. Read the record and the findings below it.
5. Use Copy to keep a text version of the result.

Understanding the results

Example: adding a reporting service

Before the change, a lookup for example.com returns:

Record   v=TLSRPTv1; [email protected]

with the error that [email protected] must be a mailto: or https: URI. The address is missing its mailto: prefix, so compliant senders ignore it. The corrected record, now also sending a copy to a processing service at example.net:

v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.net/v1/tlsrpt

The lookup then shows the pass finding listing both destinations. The same query from a shell:

dig +short TXT _smtp._tls.example.com

Common use cases

• MTA-STS rollout: publish TLS-RPT, run MTA-STS in testing mode, read reports, then enforce.
• DANE deployments: reports show TLSA validation failures from senders that support DANE.
• Provider migration: confirm that the record still points to a monitored mailbox after moving mail platforms.
• Domain audits: TLS-RPT is also part of the Email Health Check report.

Troubleshooting

The record is valid but no reports arrive

Not every sender implements TLS-RPT, and reports are sent once per day, so wait at least a day after publishing. Check that the mailbox accepts mail from external senders and does not reject large gzip attachments, or that the HTTPS endpoint accepts POST requests. A domain with little inbound traffic may receive few reports.

The lookup finds no record although you published it

Check the host name: it must be _smtp._tls under your domain, not _tls._smtp or _smtp-tls. In DNS panels that append the domain, enter _smtp._tls only. Recent changes may still be cached; Email DNS Propagation can compare the TLS-RPT record across several public resolvers.

Reports show failures for a host you no longer use

Senders report on the MX hosts they actually tried. If an old MX record is still published or cached, update DNS with MX Lookup as a check, and update your MTA-STS policy accordingly.

Common mistakes

• Omitting mailto: before an email address.
• Publishing the record on the domain itself or under the wrong label.
• Creating a second record for a new destination instead of adding it to rua.
• Pointing reports at a mailbox nobody reads, which defeats the purpose.
• Assuming TLS-RPT enforces anything. It only reports; enforcement is MTA-STS or DANE.

Limitations

• The lookup validates the record syntax only. It cannot tell whether a mailbox exists, whether an HTTPS endpoint accepts reports or whether anyone reads them.
• It does not fetch, parse or display TLS reports.
• Answers come from the public resolvers used by the NetTools.tech server and may reflect cached data after a recent change.
• How many senders actually send reports is outside your control and cannot be measured from DNS.

Security & privacy

Only a public domain name is processed; internal names are rejected and the query goes to public resolvers, not your internal DNS. No email is sent and the report destinations are not contacted. The TLS-RPT record is public by design, so anyone can see the report addresses; use a dedicated mailbox. Reports themselves contain sending IP addresses and MX host names but no message content. No credentials are required.

Related tools

• MTA-STS Lookup – the policy whose failures TLS-RPT reports (guide).
• SMTP Test – check STARTTLS and certificates on your MX hosts directly (guide).
• MX Lookup – list the mail servers that receive your mail (guide).
• DMARC Lookup – the other reporting mechanism, for authentication results (guide).
• Email Health Check – TLS-RPT together with the other email checks (guide).

Summary

TLS-RPT tells sending servers where to report TLS problems when they deliver mail to your domain. The NetTools.tech TLS-RPT Lookup reads _smtp._tls.<domain>, checks the version, uniqueness and that each destination is a valid mailto: or https: URI. Publish it before enforcing MTA-STS, and use the SMTP Test to investigate the failures the reports reveal.