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.
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
- Find your receiving mail domain: the part after
@in addresses that receive mail, or the domain configured with your inbound mail provider. - Enter only that domain. For
support@example.com, useexample.com; the checker constructs_smtp._tls.example.comitself. - Select Check TLS-RPT. Domain is required. There are no optional fields and you do not paste or upload a report.
- 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=TLSRPTv1record 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
rualist of report destinations. - Each comma-separated destination for supported
mailto:email address orhttps: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.
| Finding | Meaning & likely cause | Next action |
|---|---|---|
| Info: not published | No 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 / endpoint | The 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 / syntax | More 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 endpoint | A 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 TXT | An 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 lookup | The 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.
