TLS-RPT Record Validator

Mail transport encryption can fail because of certificate problems, DNS errors, policy mismatches, or STARTTLS negotiation failures. Transport Layer Security Reporting, usually shortened to TLS-RPT, gives a receiving domain a standard way to tell sending systems where aggregate reports about those successes and failures should go.

TLS-RPT is a reporting channel rather than an encryption policy. Publishing it does not force a sender to use TLS, repair a certificate, or block insecure delivery. Its value comes from visibility: repeated reports can expose a broken mail path, an unintended policy change, or signs that encrypted delivery is being interfered with.

Policy domain

The domain whose reporting policy is published below the dedicated _smtp._tls DNS name.

v field

The case-sensitive version marker. RFC 8460 defines TLSRPTv1.

rua field

One or more aggregate report destinations using mailto: or https: URIs.

TXT record

The DNS text record that carries the reporting policy.

A valid policy needs exactly one matching TLS-RPT record at the policy name. The version marker comes first, followed by at least one report destination. Multiple destinations are separated by commas, so reserved commas, semicolons, and exclamation marks inside URI data must be percent-encoded rather than treated as policy separators.

DNS answers are snapshots. Recursive resolvers may hold different cached versions during a change, and a time-to-live value describes cache lifetime rather than policy correctness. A clean syntax result should therefore be followed by a check against the authoritative change plan and, after publication, another lookup from the resolver views that matter.

Mail Transfer Agent Strict Transport Security (MTA-STS) and DMARC records can add useful context, but their presence does not change whether the TLS-RPT record itself satisfies the RFC checks. Likewise, a valid destination URI says where a report could be sent; it does not prove that the mailbox or HTTPS receiver accepts and safely processes reports.

Treat received reports as untrusted input. RFC 8460 warns that reporting endpoints can be flooded and that report content can be malicious. Parsing, storage, access control, and retention need the same care as other externally supplied security telemetry.

How to Use This Tool:

Choose between checking the current public DNS answer and validating one record value before publication.

1. Select Live DNS and enter the Policy domain to query its TLS-RPT TXT owner, or select Record text and paste exactly one policy value for a browser-local check.
2. For a live lookup, choose automatic resolver fallback or pin a resolver when comparing answers. Set the request timeout from 500 to 15,000 milliseconds and decide whether to check related MTA-STS and DMARC presence.
3. Run the validation, then correct every Fail finding. Review duplicate-field warnings and confirm that each report destination belongs to the intended recipient.
4. Build the publishing value from the destination list, inspect the final TXT snippet, and validate the published answer again after DNS propagation.

Interpreting Results:

Pass means all six policy checks passed. Warn means the record passed the required checks but contains repeated field names. Fail means at least one required condition failed, such as the wrong number of matching policies, an invalid first tag, a missing rua value, or an unsupported destination URI.

A Pass result is limited to the inspected record and resolver answer. Verify the published owner name, compare the answer with the approved DNS change, and test the actual report receiver separately. Related-policy presence signals are context only and never upgrade or downgrade the TLS-RPT verdict.

Technical Details:

RFC 8460 places the reporting policy at _smtp._tls.<policy-domain>. A live TXT answer can contain unrelated text records, so only values beginning exactly with v=TLSRPTv1; are counted as TLS-RPT candidates. After that filter, the candidate count must be exactly one.

Lookup Core:

Live mode sends DNS-over-HTTPS queries to the selected public recursive resolver. Automatic mode tries Cloudflare first and falls back to Google Public DNS when the first request fails. The result records the resolver, DNS status, first TXT answer’s time to live, and elapsed lookup time.

Optional related checks query the MTA-STS and DMARC TXT owners. They report only whether a matching version marker was found through the same resolver path. Missing or unavailable related answers produce review warnings but do not enter the six TLS-RPT policy checks.

Rule Core:

The verdict is reduced from six ordered findings. Any Fail makes the overall result Fail; otherwise any Warn makes it Warn; only six Pass findings produce Pass.

Extension names accept 1 to 32 letters, digits, underscores, hyphens, or dots. Syntactically valid unknown fields are accepted and ignored. The validator still warns on repeated field names because duplicates can make policy intent ambiguous.

The publishing record joins unique destinations into v=TLSRPTv1; rua=… and adds a 3600-second TXT example. An additional HTTPS destination is included only when it is a valid https:// URI. Recheck all manually entered destination text before publishing because the generated snippet is a draft, not proof of DNS authority or endpoint ownership.

Limitations and Privacy Notes:

Syntax and public DNS presence do not prove that reports will arrive, that a receiver handles them securely, or that SMTP transport is correctly protected.

• Live mode reveals the policy domain and, when enabled, its related MTA-STS and DMARC owner names to Cloudflare or Google Public DNS.
• Record-text mode performs the RFC checks in the browser and does not run a DNS query.
• Resolver caches, propagation, split-horizon DNS, timeouts, and provider availability can make live answers differ.
• Do not publish a report destination until its ownership, access control, capacity, and untrusted-input handling are confirmed.

Worked Examples:

References:

• RFC 8460, SMTP TLS Reporting, Internet Engineering Task Force, September 2018.