Inputs
Example
example.com -> _smtp._tls TXT with v=TLSRPTv1 and mailto or HTTPS rua destinations.
TLS-RPT Checker/Generator
Assess TLS-RPT TXT records, validate RUA destinations, flag external providers, and return conformance findings with remediation warnings.
Use it to verify TLS-RPT reporting records before relying on SMTP TLS failure reports from MTA-STS or DANE deployments.
The feedback channel mail TLS policies depend on
TLS-RPT is the reporting half of modern SMTP transport security: MTA-STS and DANE state what senders must require, and TLS-RPT is how those senders tell you when the requirement fails. Without it, an enforcing policy fails silently — mail from affected senders simply stops, and the first report you get is a human asking where their message went. One small _smtp._tls TXT record turns that silence into aggregate reports naming the failure classes and the affected sending infrastructure.
This checker validates the record end to end: version syntax, the rua destination list, mailto versus HTTPS endpoint shape, and the informational question of whether reporting flows to an external provider. It also drafts a conservative starter record when none exists, so the reporting channel can be live before the first policy tightening makes it indispensable.
Checking records and destinations that must actually work
Paste a proposed TXT value while designing, or query live DNS to see what the world resolves right now. Then treat the destinations as the real subject of the review: a syntactically valid rua pointing at an unmonitored mailbox is functionally no reporting at all. Verify that the mailbox exists, survives the domain's own mail filtering, and is actually read — or that the HTTPS endpoint accepts report submissions.
Publish exactly one _smtp._tls record and list multiple destinations comma-separated inside it, rather than publishing multiple records. Once reports arrive, read them for trends rather than singletons: one sender failing once is network weather, one failure class persisting across senders is a configuration problem on your side — an expired certificate, a policy that no longer matches your MX set, a host still negotiating legacy TLS. Re-check the record after every mail-infrastructure change; reporting is cheap insurance only while the destination keeps working.
Syntax checks, drafts, and their boundaries
Pasted records stay local; live DNS lookups use Cloudflare DNS-over-HTTPS from the browser first, with the same-origin DNS fallback if that path fails, and send only the queried names. The tool validates syntax and destination shape — it does not send test reports, cannot confirm that a provider accepts submissions, and does not judge the quality of a provider's parsing. Whether reports ultimately arrive depends on sender behavior and the destination's operation, both outside this page's view.
Frequently asked questions
What is TLS-RPT actually used for?
It lets sending mail systems report SMTP TLS policy failures — most usefully alongside MTA-STS or DANE deployments, where it is the routine feedback channel showing that a policy blocks legitimate senders before users notice missing mail.
Can I point rua at an external reporting provider?
Yes, and it is common — parsing aggregate reports is genuine work. The tool marks external destinations as informational findings: a trust decision to make consciously, since the provider sees your failure telemetry.
Should I publish several TLS-RPT TXT records?
No. Publish one _smtp._tls record and put multiple destinations in a comma-separated rua list inside it. Multiple records create ambiguity that some senders resolve by ignoring them.
Does a valid record prove reports will arrive?
No. The record is the invitation; delivery depends on senders that implement TLS-RPT and on the destination accepting mail or submissions. Large operators send reliably, so a working destination usually sees traffic within a day or two.
Do I need TLS-RPT without MTA-STS or DANE?
It still works — senders can report opportunistic TLS failures too — but its main value is as the observability layer for an enforced policy. Deploying it first is the sensible order: reporting before enforcement.
What should alarm me in a report?
Persistent failure classes: certificate-validation failures after a renewal, STARTTLS suddenly unavailable on an MX host, or policy-fetch errors senders keep repeating. Those patterns describe your infrastructure, not the sender's — they are the reason this channel exists.