TLS-RPT Record Validator

Report status

Domain:

Enter the apex mail domain, for example example.com; the lookup host is built automatically.

Resolver:

Use Auto for normal checks, or pin Cloudflare or Google when comparing resolver answers.

Related policy checks:

Turn on when reviewing mail security posture around the TLS-RPT record.

Builder rua list:

Enter comma-separated mailto: or https: URIs, e.g. mailto:tlsrpt@example.com.

Builder HTTPS URI:

Use a full https:// URL such as https://reports.example.com/tlsrpt.

Timeout:

Enter milliseconds in 100 ms steps; 0 disables the extra request timeout.

Field	Value	Notes	Copy
{{ row.field }}	{{ row.value }}	{{ row.note \|\| '-' }}

#	Tag	Value	Notes	Copy
{{ idx + 1 }}	{{ row.tag }}	{{ row.value }}	{{ row.note \|\| '-' }}

#	Check	Status	Notes	Copy
{{ idx + 1 }}	{{ c.label }}	{{ c.status }}	{{ c.note \|\| '-' }}

#	Target	Scheme	Host	Status	Authorization	Notes	Copy
{{ row.index }}	{{ row.target }}	{{ row.scheme }}	{{ row.host }}	{{ row.status }}	{{ row.authorizationRecord \|\| row.authorization }}	{{ row.note \|\| '-' }}

#	Signal	Status	Notes	Related tool	Copy
{{ idx + 1 }}	{{ row.label }}	{{ row.status }}	{{ row.note \|\| '-' }}	{{ row.href }}

#	Tag	Value	Notes	Copy
{{ idx + 1 }}	{{ row.tag }}	{{ row.value }}	{{ row.note \|\| '-' }}

{{ builderSnippet }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

SMTP delivery still negotiates encryption one connection at a time. STARTTLS lets mail servers upgrade an SMTP session to TLS, but the sending side needs to discover the receiving domain's expectations and then handle certificate, policy, routing, and downgrade problems correctly. TLS reporting gives domain owners a feedback channel for those failures.

SMTP TLS Reporting, usually written as TLS-RPT, is not an encryption policy by itself. It is a DNS-published reporting policy that tells compatible sending mail servers where to send aggregate information about TLS and transport-policy failures they saw while attempting delivery. Those reports can reveal broken MX certificates, stale MTA-STS policy files, DNS propagation mistakes, downgrade attempts, or reporting destinations that stopped accepting data.

Policy domain: The mail domain whose SMTP transport security is being monitored.
TLS-RPT owner name: The DNS TXT name below _smtp._tls for the policy domain.
rua: The aggregate report destination list. It can contain mailto: and https: destinations.
Related policy: MTA-STS or DANE can tell senders how to authenticate delivery. TLS-RPT tells compatible senders where to report failures.

The record is small, which makes placement mistakes easy to miss. For example.com, the record belongs at _smtp._tls.example.com, not at the bare domain, an MX hostname, or the report mailbox domain. A valid policy starts with v=TLSRPTv1 and includes a rua tag with at least one report destination.

Most TLS-RPT failures are operational rather than mathematical. A policy can parse correctly while reports go to an unwatched mailbox. A third-party collector can be appropriate, but the destination domain should intentionally authorize reports for the policy domain. A fresh DNS edit can also appear inconsistent across resolvers until caches expire.

TLS-RPT is strongest when it sits beside the rest of the mail-security rollout. MX hosts need working certificates, MTA-STS or DANE needs its own validation when used, and someone must review the aggregate report files after senders begin submitting them. The DNS record is the start of observability, not the end of transport security.

How to Use This Tool:

Start with the live DNS lookup, then use the builder output only after the intended report destinations are known.

Enter the mail domain in Domain. The lookup host is built as _smtp._tls.<domain>, so enter example.com rather than the full owner name.
Leave Resolver on Auto for a normal first pass. Pin Cloudflare or Google when comparing cache or propagation differences.
Keep Related policy checks enabled when reviewing a broader mail-security rollout. Turn it off when you only need the TLS-RPT record and fewer DNS lookups.
Use Builder rua list and Builder HTTPS URI only when preparing a replacement record. A blank builder list starts with mailto:tlsrpt@<domain>.
Set Timeout when slow DNS-over-HTTPS requests should stop after a chosen number of milliseconds. A value of 0 disables the extra request timeout.
Choose Validate TLS-RPT. The summary badges show record count, pass, warn, and fail totals, TTL when available, lookup time, and the resolver that answered.
Open Validation Findings before copying a record. Fix failures such as no TLS-RPT record, a missing v=TLSRPTv1 value, missing rua, malformed destinations, or destination authorization warnings.
Use DNS Record Evidence, TLS-RPT Tag Ledger, Report Destinations, and DNS Zone Snippet as handoff material for the DNS owner, then validate the domain again after publication.

If the result is surprising, compare Lookup host, DNS status, TTL, Resolver, and Primary record before editing DNS. Those fields usually separate a wrong owner name from a cache delay or resolver-specific answer.

Interpreting Results:

A visible TXT answer is not enough. The useful reading is the combination of Validation Findings, Report Destinations, and the selected Primary record. A generated builder record is also not proof that live DNS has changed; it is only a publishing draft until the lookup returns it.

TLS-RPT result meanings and follow-up checks
Result cue	What it means	What to verify next
All core findings pass	One TLS-RPT candidate was found, the version is recognized, and parsed destinations have acceptable basic syntax.	Confirm the mailbox or HTTPS collector is monitored and can process the aggregate reports that arrive later.
`No TLS-RPT record found.`	No usable TLS-RPT TXT policy appeared at the standard lookup host.	Publish the value under `_smtp._tls.<domain>` and recheck after the DNS change window.
`Single TLS-RPT record` warns	More than one candidate record is visible, or no single clean candidate can be selected.	Remove extra candidate policies so senders and humans do not have to choose between conflicting records.
`rua URIs valid` fails or warns	At least one report destination is empty, unsupported, or malformed.	Use a `mailto:` destination or a full `https:` URI and rerun the lookup.
`Report destinations authorized` warns	A parsed destination is outside the policy domain and the expected authorization signal was not visible.	Review the shown authorization owner name with the destination-domain owner or reporting provider.
`Related policy signals` warns	MTA-STS TXT, the MTA-STS policy host, or DMARC was not visible during companion checks.	Use dedicated MTA-STS, DANE, or DMARC validation before treating the broader mail-security posture as complete.

A passing syntax result can still give false confidence. TLS-RPT says where compatible senders should report; it does not prove that MTA-STS or DANE is enforced, that MX certificates are valid, or that anyone reads the aggregate reports.

Technical Details:

RFC 8460 defines TLS-RPT as a DNS-discovered reporting policy for SMTP transport-security failures. The policy uses semicolon-separated tag/value fields, with the version tag identifying the policy format and the rua tag listing report destinations. The record is queried below _smtp._tls for the policy domain.

TLS-RPT does not negotiate TLS, validate certificates, or make delivery mandatory. Those decisions belong to SMTP transport behavior, MTA-STS, DANE, and receiver policy. TLS-RPT adds visibility by giving compatible sending MTAs a destination for aggregate failure data.

Rule Core:

TLS-RPT validation rule core
Rule	Pass condition	Why it matters
TLS-RPT TXT record published	At least one TXT answer at `_smtp._tls.<domain>` begins with `v=TLSRPTv1`.	Senders will not discover reporting instructions if the policy is absent or published at the wrong owner name.
Single TLS-RPT record	Exactly one TLS-RPT candidate value is visible.	Multiple candidate policies make publication ambiguous and complicate DNS handoffs.
Version is `TLSRPTv1`	The parsed `v` value matches version 1 of the TLS-RPT format.	Other version strings are not recognized as the current TLS-RPT policy format.
Version tag is first	The first parsed tag is `v`.	Version-first records are the expected interoperable shape for policy discovery.
`rua` present	The parsed `rua` value contains at least one destination.	A policy without a destination gives compatible senders nowhere useful to submit aggregate reports.
`rua` URIs valid	Each destination is a `mailto:` value with an address or a parseable `https:` URI.	Unsupported schemes, empty values, and malformed destinations prevent reliable report delivery.
No duplicate tags	Each parsed tag appears once in the selected record.	Duplicate tags force humans and senders to decide which value should win.
Unknown tags review	Only `v` and `rua` appear in the parsed policy.	Unknown fields may be harmless extensions, but they deserve review in a live mail-security record.

TXT answers can contain unrelated values beside the TLS-RPT policy, and long TXT values can be returned in quoted fragments. A reliable review first reconstructs readable TXT values, then selects values that begin with v=TLSRPTv1 and applies TLS-RPT-specific tag checks.

TLS-RPT lookup and parsing path
Stage	Mechanism	Common failure
Domain cleanup	Obvious URL, mailbox, path, leading-dot, and trailing-dot noise is reduced to a host name, and internationalized names are converted to ASCII form when possible.	Convenience cleanup can still point at the wrong policy domain when the pasted address belongs to another service.
Owner name assembly	The TXT question is built as `_smtp._tls.<domain>`.	Publishing the value on the bare domain, an MX host, or a similar reporting subdomain will not satisfy the standard lookup.
Resolver answer	A public DNS-over-HTTPS resolver returns status, TXT answers, TTL when supplied, and elapsed lookup time.	Stale cache, DNS propagation, or resolver errors can make a valid edit appear missing from one vantage point.
Candidate selection	TXT values beginning with `v=TLSRPTv1` are treated as TLS-RPT candidates, and the longest candidate is parsed when several are present.	Extra candidate records should still be removed, because the publication itself remains ambiguous.
Destination review	The `rua` list is split on commas, then each destination is checked for accepted scheme, host extraction, and external authorization status.	A syntactically valid destination can still fail operationally if the mailbox is unmonitored or the HTTPS collector is not prepared for TLS-RPT submissions.

External report destinations are a trust boundary. A destination inside the policy domain namespace passes the local ownership check. A destination outside that namespace needs a separate authorization TXT signal at the owner name shown in Report Destinations. If that signal is absent, the destination is reported as a warning rather than hidden behind URI syntax success.

The builder output keeps to the standard core fields: v=TLSRPTv1, a rua list, and a DNS zone snippet with a sample TTL of 3600 seconds. If both a comma-separated destination list and an HTTPS destination are supplied, the destinations are merged and duplicates are removed before the snippet is displayed.

Limitations and Privacy Notes:

TLS-RPT validation depends on live DNS visibility and the selected public DNS-over-HTTPS resolver. Read the result as a DNS and syntax review, not as an end-to-end report-delivery test.

The checked domain names and DNS query types are sent to the selected resolver.
No sample TLS-RPT report is sent to the mailbox or HTTPS destination.
Related policy checks only look for nearby MTA-STS and DMARC presence signals. They do not validate an MTA-STS policy file, MX certificate chain, DNSSEC status, DANE TLSA records, or DMARC tag semantics.
TTL, resolver choice, and cache timing can make a recent DNS edit appear inconsistent until old answers expire.

Worked Examples:

Publishing a first mailbox destination:

A domain owner enters example.com and leaves the builder list blank. TLS-RPT Record Builder uses mailto:tlsrpt@example.com, and DNS Zone Snippet produces a TXT record under _smtp._tls.example.com. After publication, Validation Findings should show TLS-RPT TXT record published, Version is TLSRPTv1, and rua URIs valid as passes.

Reviewing a third-party report service:

A security team validates example.com and sees rua=mailto:reports@monitoring.example.net. Report Destinations marks the target host as outside the policy domain and reports Report destinations authorized as a warning when the authorization TXT signal is not visible. The syntax may be usable, but the handoff should include the shown authorization owner name.

Finding a wrong DNS owner name:

An operator publishes v=TLSRPTv1; rua=mailto:reports@example.com on example.com. The lookup returns No TLS-RPT record found., while DNS Record Evidence shows the lookup host as _smtp._tls.example.com. Moving the same TXT value to that owner name is the corrective path.

Separating cache delay from a bad edit:

After a replacement record is published, Cloudflare returns one TXT answer with the new rua destination while Google still shows the old value. Resolver, TTL, and Primary record make the difference visible. If the old answer still has cache life left and the new answer passes elsewhere, waiting is usually safer than making another DNS edit.

FAQ:

Does a passing result mean TLS reporting is working end to end?

No. A passing result means the DNS record and parsed destinations satisfied the checks shown in Validation Findings. It does not prove that a mailbox is monitored or that an HTTPS collector accepts TLS-RPT submissions.

Where should I publish the TXT record?

Publish it below _smtp._tls for the policy domain. For example.com, the owner name is _smtp._tls.example.com.

Which report destination formats are accepted?

The destination parser accepts mailto: values that contain an email address with @ and parseable https: URIs. Other schemes are reported as unsupported.

Why does destination authorization matter?

It appears when a report target is outside the policy domain and the expected authorization TXT signal was not found. Review the authorization owner name in Report Destinations with the owner of that destination.

Why can related policy checks warn when TLS-RPT passes?

Those rows are companion presence checks. They can warn about missing MTA-STS or DMARC signals while the TLS-RPT TXT record itself still parses correctly.

What information leaves my browser during validation?

The DNS names being checked, such as _smtp._tls.<domain> and optional related policy names, are sent to the selected public DNS-over-HTTPS resolver.

Glossary:

TLS-RPT: SMTP TLS Reporting, the DNS-published reporting policy that tells compatible sending mail servers where to submit aggregate TLS delivery reports.
STARTTLS: The SMTP extension that lets a mail connection upgrade to TLS during delivery.
Policy domain: The mail domain whose TLS-RPT, MTA-STS, or DANE policy is being evaluated.
rua: The aggregate report URI tag inside the TLS-RPT TXT record.
MTA-STS: SMTP MTA Strict Transport Security, a policy mechanism for telling senders when to require authenticated TLS for MX delivery.
DANE: A DNSSEC-based way to publish TLS authentication information for SMTP delivery.
TTL: Time to live, the number of seconds a DNS answer may remain cached when the resolver supplies that value.

References:

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