Free email tools

TLS-RPT Record Checker

See whether your domain requests reports about inbound SMTP TLS negotiation and policy failures.

Enter your receiving mail domain. The checker reads _smtp._tls TXT records; it does not ingest or send reports.

Use the receiving email domain, without the _smtp._tls prefix.

No registration required. Checks run on our server using Google Public DNS. Our DNS cache lasts up to five minutes; upstream DNS caches can delay changes further. No email test allowance is used.

How to use TLS-RPT Record Checker

  1. Find your receiving mail domain: the part after @ in addresses that receive mail, or the domain configured with your inbound mail provider.
  2. Enter only that domain. For support@example.com, use example.com; the checker constructs _smtp._tls.example.com itself.
  3. Select Check TLS-RPT. Domain is required. There are no optional fields and you do not paste or upload a report.
  4. Compare the reported destinations with your report collector. An illustrative record is v=TLSRPTv1; rua=mailto:tls-reports@example.com; replace that example address with a collector you have configured before publishing.

What this tool checks

The checker reads public TXT records at _smtp._tls.domain through Google Public DNS. It checks:

  • Whether a single recognized v=TLSRPTv1 record exists. Multiple policies and unsupported versions are separate findings from a missing optional record.
  • Tag formatting and uniqueness, the version as the first tag, and a nonempty rua list of report destinations.
  • Each comma-separated destination for supported mailto: email address or https: URL syntax, and repeated identical endpoints.

Only DNS and destination syntax are inspected. The checker does not contact HTTPS report collectors, test mailbox existence, establish destination ownership, send reports or analyze their contents. It also does not test your mail servers’ TLS connections.

Understanding your results

TLS-RPT is optional and complements MTA-STS. Set up a mailbox or HTTPS report processor you control before publishing rua. Example addresses are illustrative.

TLS-RPT publication and endpoint findings.
FindingMeaning & likely causeNext action
Info: not publishedNo recognized TLS-RPT record is available at the lookup name. Reporting is optional.If reports are wanted, configure a collector and publish one TXT record at the indicated name.
Pass: publication / syntax / endpointThe specific record or destination passes its syntax check.Verify separately that the mailbox or HTTPS collector is configured to accept reports.
Fail: multiple records / version / syntaxMore than one policy, an unsupported version, malformed tags or missing rua was found.Keep one record starting with v=TLSRPTv1 and provide a nonempty destination list.
Fail: report endpointA destination is malformed or uses an unsupported scheme.Use mailto:tls-reports@example.com or a valid HTTPS collector URL, replacing examples with your actual destination.
Warning: duplicate endpoint / unrecognized TXTAn endpoint is repeated, or TXT data exists but no recognized version prefix was selected.Remove duplicate destinations or correct the intended TLS-RPT version prefix.
Unknown: DNS lookupThe resolver timed out, refused the query or could not complete it. This differs from an empty successful answer.Retry and inspect DNS availability if the problem persists. Do not infer that reporting is unconfigured.

What is TLS-RPT and why does it matter?

SMTP TLS Reporting (TLS-RPT) lets a receiving domain request aggregate feedback about transport encryption and policy failures. TLS, or Transport Layer Security, protects a connection while mail travels between servers. Reports can help a domain operator notice certificate or policy problems experienced by participating senders.

TLS-RPT requests visibility; it does not itself require encrypted delivery. Use it alongside the MTA-STS checker when rolling out or troubleshooting a receiving transport policy. A correct reporting record does not guarantee that any sender will submit a report or that mail will reach the inbox.

To connect report collection with a transport-policy rollout, read MTA-STS and TLS-RPT: Setup and Troubleshooting.

Frequently asked questions

Do I enter _smtp._tls or my normal domain?

Enter the normal receiving domain only. For addresses at example.com, use example.com. The tool adds _smtp._tls automatically; entering that prefix yourself is not the intended input.

Can I send TLS reports to HTTPS instead of an email address?

Yes. This checker accepts syntactically valid HTTPS report URLs and mailto addresses. An HTTPS website URL is not automatically a report collector; configure its receiving endpoint before publishing it.

Can rua contain more than one destination?

Yes. Separate destinations with commas. Repeating an identical URI produces a warning. Each listed destination is checked for syntax, but none is contacted to confirm report acceptance.

The record passes. Why are no reports arriving?

Check your collector setup and its logs, and confirm that the relevant sending systems support reporting. This page does not test delivery of reports or establish a reporting schedule. If DNS changed recently, our cache can last up to five minutes and upstream caches may still hold an older answer.

Do I need TLS-RPT before I can receive email?

No. It is optional reporting. Use the MX checker to inspect published receiving destinations, and review MTA-STS separately if you want a transport policy.