TLS-RPT Record Validator

Introduction:

Email transport security reporting records are small text policies that a domain publishes so other mail systems know where to send reports when encrypted delivery fails. A practical email security record validator helps you confirm that the policy is present and that report destinations are written correctly before you rely on them. That matters during migrations, new gateways, or vendor changes, when one missing character can quietly drop reports.

Type your domain, run a check, and read the result as simple pass, warn, and fail messages that point to what needs attention. You will also see the published policy record and a token by token breakdown that makes it easier to spot duplicates and typos. If you are starting from scratch, the builder can draft a clean record string that you can paste into your domain configuration.

A realistic example is setting reports to go to a shared mailbox and a secure web endpoint, then checking that both targets are accepted and the version is correct. The tool also surfaces related email policy signals, which helps you confirm that reporting sits alongside your other protections. Warnings are often about interoperability and consistency, while failures usually mean the policy is missing or a destination is invalid.

A well formatted record does not prove that reports will arrive, that a mailbox is monitored, or that every connection is protected. Treat report addresses as operational data and avoid sharing them widely unless you need to. After publishing changes, validate again later because caches and propagation can delay what different resolvers return.

Step-by-Step Guide:

Validate a TLS reporting policy record for a domain, then use the results to correct report destinations and publish a clean TXT entry.

1. Enter the Domain you want to check, such as example.com.
2. Optionally choose a Resolver and adjust Timeout in milliseconds.
3. Optionally enable Related policy checks to look for supporting email signals.
4. Select validate and wait for the summary to show record count, TTL, resolver, and elapsed time.
5. Review the checks and focus first on any FAIL items.
6. Open the record view to confirm the v and rua tokens were parsed as expected.
7. If you need to publish or fix a policy, use the builder output and copy the zone snippet.
8. Validate again after publishing, especially if your TTL is high or changes are recent.

Pro tip: make one small change at a time, publish, then validate from two resolvers to separate syntax issues from propagation delays.

Technical Details:

SMTP TLS Reporting (TLS-RPT) records are Domain Name System (DNS) TXT policies that tell sending mail systems where to deliver aggregated reports about Transport Layer Security (TLS) delivery failures. This validator measures whether _smtp._tls.<domain> returns a policy, how its tags are structured, and whether reporting destinations follow the accepted schemes.

The core computation is a structured parse of the TXT value into semicolon separated segments, then into tag and value pairs. Each rule produces a discrete result with a status and a short note that explains what was detected.

Results are categorized into PASS, WARN, FAIL, and INFO. PASS indicates the record matches the expected structure, WARN flags likely workable configurations that can reduce interoperability, and FAIL indicates missing or invalid required elements.

Comparisons across runs depend on DNS propagation and resolver cache state. When multiple TXT answers exist, the tool warns and selects the longest unique value as the primary record for token parsing.

Processing pipeline

1. Sanitize the input into a hostname and convert it to ASCII form if needed.
2. Query TXT records for _smtp._tls.<domain> using the selected DNS over HTTPS resolver.
3. If Auto is selected, query Cloudflare first and fall back to Google only on request failure.
4. Extract TXT strings by joining quoted segments and trimming whitespace.
5. De-duplicate TXT answers and select the longest answer as the primary record.
6. Split the primary record on semicolons, then parse each segment into a tag and value.
7. Validate v equals TLSRPTv1 and warn if v is not the first tag.
8. Split rua on commas, then accept only mailto: addresses and https: URLs.
9. Report PASS, WARN, or FAIL for each check and summarize TTL and request time.

v=TLSRPTv1; rua=mailto:tlsrpt@example.com, https://reports.example.com/tlsrpt

1) v = TLSRPTv1
2) rua = mailto:tlsrpt@example.com, https://reports.example.com/tlsrpt

Constants and built-in assumptions

Units, precision, and rounding

• Elapsed request time is measured with a high resolution timer and rounded to the nearest whole millisecond.
• Timeout is configured in milliseconds and applies per DNS over HTTPS request.
• TTL is shown in seconds when supplied by the resolver response, otherwise it is left blank.
• JSON output is formatted with two space indentation for readability.

Validation rules and bounds

I/O formats and encoding

Networking and storage behavior

• DNS lookups are performed via DNS over HTTPS requests to the selected public resolver.
• Requests include an Accept header requesting application/dns-json.
• Each request can be aborted after the configured timeout using AbortController, and timeout zero disables the extra abort timer.
• No local or session storage calls are present in the app code, and results live in memory until you reload.

Performance, determinism, and security notes

• Parsing work is linear in the length of the TXT record, and dominates only after network latency.
• Related policy checks add up to four additional DNS lookups when enabled.
• Given the same resolver responses, tokenization and rule outcomes are deterministic.
• TXT content is untrusted input from DNS, so treat copied and exported text as data, not code.

Assumptions and limitations

• Heads-up A valid looking record does not guarantee reports will be delivered or processed.
• Only v and rua are treated as known tags, and other tags are flagged for review.
• Duplicate tags are reported as a warning, and the first non-empty value is used for rule checks.
• When multiple TXT answers exist, the longest answer is selected as the primary record for parsing.
• Mailto validation checks only for an at sign in the address, not full mailbox syntax.
• HTTPS validation confirms URL parsing and scheme only, not reachability or authentication.
• Auto resolver failover occurs only on request failure, not on non-zero DNS status codes.
• Related checks validate record presence and basic host resolution, not policy file contents.
• Timeout is per request, so total runtime can exceed the timeout when multiple lookups are enabled.

Edge cases and common error sources

• Internationalized domains may normalize differently across inputs before ASCII conversion.
• Leading dots, trailing dots, and repeated dots are trimmed, which can change a pasted value.
• TXT values split across multiple quoted chunks are concatenated, which is normal for DNS.
• TXT answers split across multiple records can trigger a multiple record warning.
• Semicolons inside unexpected values can be misread as tag separators by simple parsing.
• Commas inside destination strings can be misread as separators because rua is split on commas.
• IPv6 literals in https: URLs require brackets and can fail URL parsing if malformed.
• Resolvers can return stale cache content after updates, especially when TTLs are high.
• Network blocks, CORS restrictions, or captive portals can cause resolver requests to fail.
• Missing AbortController support can prevent client-side timeouts from taking effect.
• Timing is rounded to whole milliseconds, so repeated runs can differ by small amounts.
• Rapid repeated validations can overlap network timing expectations, even if UI disables the button.

Standards and references

The record structure aligns with SMTP TLS Reporting as defined in RFC 8460, and the related signals correspond to MTA-STS in RFC 8461 and DMARC in RFC 7489. DNS over HTTPS transport is described in RFC 8484.

Privacy and compliance

DNS lookups are made from your browser using the selected resolver and results stay in memory, so handle domains and report addresses per your security policy and applicable privacy rules such as GDPR.

Troubleshooting:

• “Domain is required.” Enter an apex domain like example.com and avoid extra spaces.
• “No TLS-RPT record found.” Confirm the TXT record is published at _smtp._tls.<domain>.
• All checks fail quickly. Switch resolvers, increase timeout, and confirm your network allows DNS over HTTPS.
• Multiple TXT answers detected. Consolidate to a single policy record to avoid unpredictable sender behavior.
• “All rua URIs are invalid.” Use only mailto: or https: destinations and remove unsupported schemes.
• Copy actions do nothing. Check clipboard permissions, then use download as a fallback.
• Related policy signals show WARN. Treat them as supporting hygiene, not a blocker for TLS-RPT itself.

Advanced Tips:

• Tip Validate the apex domain unless you intentionally delegate mail policy by subdomain.
• Tip Keep v=TLSRPTv1 first even when extensions are present.
• Tip Use a shared mailbox alias for mailto: targets to avoid personnel churn.
• Tip Add an https: endpoint only if you control ingestion and can handle volume.
• Tip Compare results from Cloudflare and Google to separate propagation from resolver cache effects.
• Tip Treat WARN items as cleanup work to keep future troubleshooting simple.
• Tip Revalidate after each publish and wait at least one TTL when diagnosing inconsistent answers.

Glossary:

TLS-RPT

SMTP TLS Reporting, a DNS TXT policy for where to send aggregated failure reports.

DNS TXT record

A text value published under a domain name, used here to hold policy tags.

v tag

The version identifier, expected to be TLSRPTv1.

rua tag

Reporting destinations, listed as comma separated URIs.

TTL

Time to live, the cache lifetime for a DNS answer in seconds.

DoH

DNS over HTTPS, a method for DNS lookups transported over HTTPS.

MTA-STS

Mail Transfer Agent Strict Transport Security, a related mail transport security signal.

DMARC

Domain-based Message Authentication, Reporting, and Conformance, a related domain policy signal.

PASS, WARN, FAIL

Status categories for rule outcomes, indicating ok, needs review, or broken.

FAQ: