TLS-RPT Record Validator

Introduction:

SMTP TLS Reporting, usually shortened to TLS-RPT, gives receiving mail domains a way to ask senders for aggregate reports about encrypted delivery problems. The record is small, but the signal is useful: it can reveal STARTTLS failures, certificate trouble, policy mismatches, and other transport-security errors that would otherwise stay buried inside remote mail systems.

A TLS-RPT policy lives in DNS as a TXT record under _smtp._tls.<domain>. It does not make mail more secure by itself. Its job is to publish reporting destinations so compatible senders know where to send daily aggregate feedback when they try to deliver mail using MTA-STS or DANE policy information. That makes the record especially useful after a new MTA-STS rollout, a certificate change, an MX migration, or a period of unexplained TLS delivery failures.

The meaningful part of the policy is the destination list. A domain can ask for reports to be delivered to a mailbox, an HTTPS ingestion endpoint, or more than one destination. If that list is empty, malformed, or published at the wrong DNS name, senders either have nowhere reliable to submit reports or may treat the policy as unusable.

TLS-RPT should be read as monitoring support, not as proof that the delivery path is protected. MTA-STS and DANE influence how senders validate transport security. TLS-RPT reports the aggregate outcomes of those attempts. A clean-looking reporting record does not prove that the report mailbox is watched, that an HTTPS endpoint accepts submissions, or that every sender supports the reporting standard.

Live validation also has a privacy boundary. Checking a domain requires sending DNS questions for that domain to a public DNS-over-HTTPS resolver. The result is useful for publication review and troubleshooting, but it should be treated as a public DNS check rather than a private mailbox, endpoint, or delivery audit.

Technical Details:

A TLS-RPT policy is discovered by querying the policy domain for a TXT record at the fixed name _smtp._tls.<domain>. RFC 8460 defines two core directives for this record. The v directive identifies the policy version and must be TLSRPTv1. The rua directive is a comma-separated list of aggregate report destinations, using mailto: or https: URI schemes.

TXT records can be returned as quoted fragments, and DNS resolvers may return more than one TXT answer for the same owner name. Standards-aware interpretation is stricter than ordinary TXT display: records that do not begin with the TLS-RPT version are not useful as reporting policies, and multiple resulting TLS-RPT records should be treated as a publication problem. The validator keeps the returned strings visible, parses the longest unique answer as the primary record, and warns when the publication is not a single clean policy.

Unknown fields deserve review rather than immediate deletion. RFC 8460 allows parsers to ignore unknown fields in a syntactically valid superset, which helps future extensions remain possible. This validator still flags unknown tags because a human reviewer should know when the live TXT value contains material outside the two tags it checks natively.

Rule Core:

The URI check is intentionally narrow. It confirms the destination scheme and a basic address or URL shape; it does not send a test message, post a sample report, verify ownership of a third-party receiver, or inspect HTTPS endpoint behavior. A mailto: destination can pass the syntax check even if the mailbox is unmonitored, and an https: destination can pass the URL check even if the application behind it rejects reports.

Validation Path:

Related policy checks are separate DNS signals. When enabled, the page checks for v=STSv1 at _mta-sts.<domain>, checks for v=DMARC1 at _dmarc.<domain>, and asks whether mta-sts.<domain> has A or AAAA records. Those rows help place TLS-RPT beside nearby mail-security controls, but they do not validate the MTA-STS policy file, the DMARC policy tags, MX certificates, or live SMTP behavior.

The record builder follows the same small policy shape. It emits v=TLSRPTv1 plus a rua list. If no reporting destination is entered, it starts with mailto:tlsrpt@<domain>. If an HTTPS destination is entered, it is merged into the same list and duplicates are removed. The zone snippet uses a sample TTL of 3600 seconds, which should be adjusted to match the DNS operator's rollout plan.

Everyday Use & Decision Guide:

Use the validator first as a publication check. Enter the receiving mail domain, leave Resolver on Auto, and run Validate TLS-RPT. The summary badges tell you how many TXT answers were seen, how many checks passed or warned, which resolver answered, the returned TTL, and how long the lookup took.

The best first read is the Validation Findings tab. Failures on record publication, v=TLSRPTv1, or rua should be fixed before warnings. Warnings such as duplicate tags, unknown tags, multiple TXT answers, or a version tag that is not first may not break every receiver, but they make the policy less predictable and harder to support after a DNS change.

• Use Record Tags when you need to inspect the live TXT value, parsed tags, duplicate tag notes, invalid URI notes, and related policy rows in one table.
• Use Validation Findings when you want the shortest repair list. The status badge tells you whether the row is a pass, warning, or failure.
• Use Record Builder when no record exists yet or when you want a clean replacement value based on known report destinations.
• Use JSON when you need to preserve the domain, resolver choice, TTL, parsed tokens, checks, related rows, and builder output for a ticket or change note.

Resolver choice matters during rollouts. A brand-new TXT value can look wrong from one resolver while another already sees the new answer. If the record changed recently, compare Resolver, TTL, and Records before editing the policy again. A long TTL can explain why stale data remains visible after the DNS control panel already shows the intended value.

The builder is useful for drafting, not for proving that reporting works. Add comma-separated mailto: or https: destinations to Builder rua list, add a full HTTPS endpoint in Builder HTTPS URI when needed, then copy the generated TXT value or zone snippet. After publishing, run validation again against the domain so the live DNS answer, not the draft text, decides the result.

Keep Related policy checks enabled when reviewing a broader mail-security rollout. A TLS-RPT record is often published beside MTA-STS and DMARC, and missing related signals can point to the next review target. Treat those rows as prompts for follow-up validators, not as proof that the surrounding policies are complete.

Step-by-Step Guide:

Run the live lookup first, then use the builder only when the published record needs to be created or replaced.

1. Enter the target mail domain in Domain. If the alert says Domain is required., correct the field before running another check.
2. Keep Resolver on Auto for a normal first pass, or select Cloudflare or Google when comparing resolver-specific answers.
3. Leave Related policy checks on if you want nearby MTA-STS and DMARC presence signals. Turn it off when you need only the TLS-RPT record and want fewer DNS lookups.
4. Select Validate TLS-RPT. The TLS-RPT Summary should show the ASCII domain, record count, pass/warn/fail counts, TTL when available, lookup time, and resolver used.
5. Open Validation Findings. Fix FAIL rows first, especially missing record, missing version, missing rua, or invalid rua destinations.
6. Open Record Tags to inspect the parsed tag order and notes. If the row says Duplicate tag or Unknown extension tag, clean up the TXT value before treating the record as final.
7. Use Record Builder only after you know the intended report destinations. Copy the generated value or snippet, publish it in DNS, then validate the same domain again.
8. Use JSON or table exports when the review needs to be attached to a ticket, handed to a DNS operator, or compared after a cache window expires.

A good handoff includes the live record value, the failing finding row if any, the resolver used, and the TTL. Those four details usually tell the DNS owner what to change and when to recheck.

Interpreting Results:

The most important result is not the pass count by itself. Read the failing or warning rows beside the record count and the parsed rua value. One valid destination in the builder does not matter if the live TXT answer is still missing, and a visible TXT answer does not help if the primary parsed record lacks v=TLSRPTv1.

A passing syntax result can still create false confidence. The page does not prove that reports will arrive, that the destination owner agreed to receive them, or that daily TLS-RPT JSON files will be parsed correctly after delivery. The corrective check is operational: verify the receiving mailbox or HTTPS service, watch for the first aggregate report after publication, and compare future failures against MTA-STS or DANE changes.

When results differ between runs, compare resolver, TTL, elapsed time, and record count before changing the TXT value. If one resolver still shows an older answer and the TTL is high, waiting for caches may be the correct response.

Worked Examples:

A first TLS-RPT mailbox record

A team enters example.com, adds mailto:tlsrpt@example.com in Builder rua list, and copies the generated snippet. After DNS publication, TLS-RPT Summary shows Records 1, Validation Findings passes Version is TLSRPTv1, and rua URIs valid passes. That confirms the DNS-side reporting policy shape, while mailbox monitoring still needs to be checked outside the page.

A mixed mailbox and HTTPS destination

A security team wants reports in a mailbox and in an ingestion API. They set Builder rua list to mailto:tlsrpt@example.com and Builder HTTPS URI to https://reports.example.com/tlsrpt. The builder produces one rua value containing both destinations. If the live record later shows the HTTPS value without the https:// prefix, Validation Findings warns or fails the URI row, and Record Tags shows the malformed destination.

A record that exists at the wrong place

A DNS operator publishes v=TLSRPTv1; rua=mailto:reports@example.com as a TXT record on example.com instead of _smtp._tls.example.com. The validator returns No TLS-RPT record found. because it queries only the standard policy host. The fix is to move the TXT value to the generated lookup name, wait for DNS propagation, and rerun the same domain until Records 1 appears.

A rollout hidden by resolver caching

After a TXT update, Cloudflare still returns the old policy while Google returns the new one. The Resolver badge, TTL, and Record Tags table make the difference visible. If the new record passes under one resolver and the old answer has time left in cache, the next move is usually to wait or lower TTL for future changes, not to rewrite a valid replacement policy.

FAQ:

Glossary:

TLS-RPT

SMTP TLS Reporting, the DNS-published reporting policy that tells compatible senders where to submit aggregate TLS delivery reports.

Policy domain

The receiving mail domain whose TLS-RPT policy is published under _smtp._tls.

rua

The aggregate report destination list inside the TLS-RPT record.

MTA-STS

SMTP MTA Strict Transport Security, a related policy that tells senders when to require authenticated TLS for MX delivery.

DANE

A DNSSEC-based method for publishing TLS authentication information for mail delivery.

DNS-over-HTTPS

A DNS transport where DNS questions are sent through HTTPS to a resolver endpoint.

TTL

Time to live, the DNS cache lifetime returned with an answer when the resolver provides it.

References:

• RFC 8460: SMTP TLS Reporting, IETF, September 2018.
• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS), IETF, September 2018.
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), IETF, March 2015.
• RFC 8484: DNS Queries over HTTPS (DoH), IETF, October 2018.