TLS-RPT Record Validator

Introduction

TLS-RPT records tell other mail systems where to send aggregate reports when encrypted SMTP delivery fails. They matter because a domain can publish strong transport policy and still miss the operational warning signs if reporting destinations are malformed, duplicated, or missing. This validator turns that quiet DNS record into something you can read, check, and publish with fewer guesswork errors.

The package looks up the TXT policy at _smtp._tls.<domain>, breaks the record into tags, and then grades the result as pass, warn, fail, or informational. It also times the DNS-over-HTTPS lookup, reports the returned TTL, and shows which resolver answered the request. That combination is useful when the record itself is correct but caches or resolver choice are hiding a recent change.

The tool is helpful both when a record already exists and when one has to be created from scratch. A team migrating mail gateways may want to verify that v=TLSRPTv1 is present, first, and paired with valid rua destinations. A domain owner setting up reporting for the first time may care more about the builder tab, which can assemble a publishable TXT value and zone-file snippet from the intended targets.

The page also checks nearby signals that often travel with TLS reporting. When enabled, the related-policy panel looks for supporting MTA-STS and DMARC presence and checks whether the mta-sts host publishes A or AAAA records. Those are not full audits of the surrounding policies, but they help explain whether a TLS reporting record is sitting in isolation or as part of a more complete mail-policy setup.

The practical limit is that a syntactically valid record is not the same as working reporting operations. This validator does not prove that a mailbox is monitored, that an HTTPS endpoint accepts reports, or that every remote sender will deliver them. It queries public DNS-over-HTTPS resolvers, so the looked-up domain leaves the browser as part of the validation request, and the result should be read as a DNS and token check rather than an end-to-end report-delivery test.

Everyday Use & Decision Guide

Start with the apex domain, not the reporting host name. The package builds the lookup name itself by prepending _smtp._tls., converts the domain to ASCII form when needed, and then queries the TXT record through the selected resolver. That matters because the validator is checking the published policy location, not a mailto address or web endpoint in isolation.

The resolver choice is mostly a troubleshooting decision. Auto tries Cloudflare first and only falls back to Google when the first request fails. If you suspect propagation differences or stale caching, run the same domain again with a specific resolver so you can tell whether the problem is the record or the answering cache. The TTL badge is useful here because a long value often explains why one resolver still shows an older answer.

The check list should be read in order of consequence. Missing records, missing v, invalid rua targets, or an empty value are the main failures. Duplicate tags, unknown tags, multiple TXT answers, or non-leading version tags are usually warnings instead. They may still work in some environments, but they make the record harder to reason about and less predictable across implementations.

The builder tab is best used as a record-drafting aid, not as proof that the live DNS answer is fixed. If no explicit target list is entered, the builder defaults to mailto:tlsrpt@<domain>. If an HTTPS endpoint is added, the tool merges it into the rua list and renders both the bare TXT value and a zone-file style snippet with a starting TTL of 3600 seconds.

Related-policy checks are supportive context, not substitutes for dedicated validators. A passing DMARC or MTA-STS signal helps confirm that reporting sits next to other mail protections, but it does not tell you whether those policies are complete or enforceable. Use this page to validate the TLS-RPT record itself first, then treat the related rows as cues for what to review next.

Technical Details

The validator sends DNS-over-HTTPS TXT queries to either Cloudflare, Google, or an automatic sequence that falls back from Cloudflare to Google only when the first request fails. The queried name is always _smtp._tls.<domain>. TXT answers are normalized by joining quoted fragments, trimming outer quotes, removing duplicates, and then selecting the longest unique answer as the primary record for token parsing.

Parsing is simple but strict. The primary TXT value is split on semicolons, each segment is trimmed, and each token becomes a tag/value pair. The package knows only two TLS-RPT tags natively: v and rua. It still preserves other tags in the record view, but it warns about them so readers can distinguish recognized TLS-RPT structure from extra material that may reduce interoperability.

The most important validation rules are attached to those two tags. v must exist and equal TLSRPTv1. The validator also warns if v is present but not the first tag. rua must exist, must not be empty, and is split on commas into one or more reporting URIs. Each URI is then checked by scheme: mailto: targets must contain an address with @, and https: targets must parse as valid HTTPS URLs. Other schemes are rejected.

The related-policy panel is built from additional DNS lookups, not from the TLS-RPT record itself. When the option is enabled, the script checks for an MTA-STS TXT record under _mta-sts.<domain>, DMARC under _dmarc.<domain>, and A or AAAA records on mta-sts.<domain>. Those rows are then summarized back into the main checks list as a supporting-policy signal.

The builder is deterministic. It emits a two-tag record with v=TLSRPTv1 and a rua list derived from the explicit target field or, if that field is empty, a default mailto:tlsrpt@<domain> target. If an HTTPS URI is provided, the package merges it into the target list and removes duplicates before generating both the record string and the ready-to-paste zone snippet.

Step-by-Step Guide

1. Enter the domain whose TLS reporting policy you want to inspect.
2. Choose a resolver or keep Auto if you just need a normal lookup path.
3. Enable related-policy checks if you want supporting MTA-STS and DMARC presence signals alongside the TLS-RPT result.
4. Run the validation and read the summary badges for record count, TTL, elapsed time, and resolver used.
5. Review the checks list from top to bottom, fixing failures before worrying about warnings.
6. Open the record tab to inspect token order, duplicate tags, and parsed rua targets.
7. If you need a replacement record, use the builder tab to generate the TXT value and zone-file snippet, then validate again after publishing.

Interpreting Results

A passing record with one warning is usually still usable, but the warning tells you where future confusion may come from. Multiple TXT answers, duplicate tags, or non-leading version tags are the common examples. They may not break every consumer, but they make the policy less predictable.

The resolver and TTL badges should be read together. If you just changed a record and one resolver still shows the old value, a long TTL or a cached answer is the first likely explanation. That does not automatically mean the new publication is wrong; it may mean the caches simply have not aged out yet.

The builder output is best interpreted as a draft. If the validation pane still fails after you publish the same value, the problem is likely in DNS publication, quoting, or propagation rather than in the policy string itself.

Worked Examples

Checking a newly published reporting mailbox

A domain owner publishes v=TLSRPTv1; rua=mailto:tlsrpt@example.com and immediately validates the apex domain. The record count is one, v is first, and the rua target passes. That is a good DNS-side confirmation, but it still leaves the operational question of whether the mailbox is monitored and can receive incoming reports.

Combining mailto and HTTPS report targets

A team wants reports to land in a mailbox and at an HTTPS ingestion endpoint. They add both destinations in the builder, publish the output, and then validate again. If one URI parses cleanly and the other does not, the validator surfaces that difference directly instead of collapsing the whole record into a single pass or fail.

Separating syntax from propagation problems

A recently updated domain passes under one resolver but still shows the old TXT answer under another. The record tab helps confirm that the live string itself is well formed, while the TTL and resolver badges explain why the answers disagree. That is a propagation problem, not a reason to start rewriting a correct record.

FAQ

Glossary

TLS-RPT

SMTP TLS Reporting, a DNS-published policy that tells senders where to deliver aggregate TLS failure reports.

rua

The report destination list inside the TLS-RPT record, typically using mailto: and optionally https: URIs.

TTL

Time to live for a DNS answer, which influences how long caches may continue serving an older value.

MTA-STS

A separate mail policy that tells senders whether TLS is expected and where the associated policy can be fetched.

DMARC

A domain-based email policy and reporting standard used here only as a nearby signal, not as part of TLS-RPT parsing.

References

• RFC 8460: SMTP TLS Reporting
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)