What is the difference between validator and record check for TLS-RPT?

The validator analyses a record you paste, before DNS publication, without any network call. The record check queries DNS live to inspect the record published at _smtp._tls.domain. Use the validator upstream, the record check downstream.

Why validate TLS-RPT syntax offline?

An invalid record is silently ignored by sending servers: you receive no report and only find out when an incident occurs. Offline validation catches issues before they impact your TLS failure visibility.

What are the most common TLS-RPT syntax errors?

Typical errors include: missing or wrong version (TLSRPT1 instead of TLSRPTv1), missing rua tag, missing mailto: or https: scheme before the endpoint, malformed email address, and missing cross-domain authorization for external endpoints.

Does the validator check cross-domain authorization?

Yes, when you fill in the domain field (record_and_domain mode). The validator inspects each external endpoint (mailto or https pointing to another domain) and verifies that the recipient has published a TLSRPT authorization record.

What is the difference between mailto and https endpoints?

mailto endpoints receive reports as email attachments (gzip-compressed JSON). https endpoints receive reports via HTTP POST on a webhook. mailto is simpler to deploy, https enables automated processing.

How do I fix an 'invalid version' error?

The version must be exactly v=TLSRPTv1 (case sensitive), at the beginning of the record. Check the case, the spaces and the absence of stray characters. v=TLSRPT1 and v=tlsrptv1 are rejected.

Should I also deploy MTA-STS with TLS-RPT?

Yes, strongly recommended. MTA-STS enforces TLS encryption, TLS-RPT tells you when enforcement fails. Without TLS-RPT, you will not know if external servers are failing to connect to your domain over TLS.

How do I validate TLS-RPT syntax for Microsoft 365 and Google Workspace?

Paste your TLS-RPT record into the validator. The syntax is identical regardless of provider. For Microsoft 365 or Google Workspace, the record must be published at _smtp._tls.captaindns.com once validated. Combine with MTA-STS to enforce encryption.

Free TLS-RPT Validator - Offline Syntax Check

Why use an offline validator

A TLS-RPT syntax validator analyses your record without publishing or querying DNS. This offline approach covers three key use cases that a live audit cannot handle.

Typical use cases:

Before deployment → validate a draft before DNS publication, to avoid a record being silently ignored by MTAs.
Draft validation → verify the syntax of a record copied from a generator, internal wiki or shared template.
Offline debugging → reproduce and fix an error without touching public DNS, for instance in an isolated or pre-production environment.
Configuration review → inspect a record received from a partner or exported from a third-party tool before applying it.

The validator enforces the RFC 8460 specification: TLSRPTv1 version, rua tag, mailto: and https: endpoint formats, cross-domain authorization and absence of unknown tags. No DNS query is made. Your data stays in your browser.

How to use this validator in 3 steps

Step 1: paste the record

Copy your TLS-RPT record value into the dedicated field:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

You can paste a draft, an existing record or the output of a generator. The validator makes no network call at this step.

Step 2: add a domain (optional)

Entering a domain enables cross-domain authorization checks. The validator switches to record_and_domain mode and inspects each external endpoint to verify that a TLSRPT authorization record exists on the recipient side.

Without a domain, only pure syntax is validated (record_only mode).

Step 3: review the verdict

Results are classified by severity:

Error → blocking issue, the record will be ignored or rejected by sending servers
Warning → functional but improvement recommended
Valid → syntax is RFC 8460 compliant

Fix every alert before publishing the record to public DNS.

Validator vs record check: when to use each tool

The two tools are complementary. They do not replace each other: they operate at different points of a TLS-RPT record lifecycle.

Dimension	Validator (this tool)	Record check
When to use	Before deployment	After deployment
DNS lookup	None	Live `_smtp._tls` resolution
Record source	Manual (pasted)	Public DNS
Cross-domain check	Optional (via domain)	Systematic
Published value detection	Static	Real state
Data sent to server	None	Domain being analysed

Recommended workflow:

Design the record → validator to check syntax
Publish the TXT record in DNS → wait for propagation
Record check to confirm the live state

The validator catches input mistakes before publication. The record check detects drift and confirms that the record served by DNS matches the intended design.

Validation modes

The validator supports two modes depending on which fields you fill.

Mode record_only

You paste only the TLS-RPT record. Pure syntax validation:

exact TLSRPTv1 version, in first position
presence of the rua= tag
endpoint format (mailto: or https:)
well-formed email addresses in mailto: endpoints
unknown tags raised as warnings

No network call. Ideal for validating a draft before publication.

Mode record_and_domain

You paste the record and a domain. In addition to syntax validation, the validator performs a cross-domain authorization check for external endpoints:

detects each endpoint whose domain differs from the analysed domain
looks up the TLSRPT authorization record on the recipient side
flags external endpoints that lack authorization

This mode helps detect configurations where you point to a third-party provider (managed report analysis) without them having published the recipient-side authorization.

Syntax rules enforced

The validator applies RFC 8460 §3 rules on the TXT record at _smtp._tls.domain:

Field	Rule
v	must be exactly `TLSRPTv1` (case sensitive), in first position
rua	required, contains one or more endpoints separated by `,`
Global format	`key=value` pairs separated by `;`
Unknown tags	tolerated but raised as warnings
Whitespace	tolerated around `;` and after `=`

Valid example:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Reporting endpoint formats

Each endpoint in rua= must use a recognised scheme:

Scheme	Format	Usage
`mailto:`	`mailto:address@domain`	reports received as email attachments
`https:`	`https://host/path`	reports posted to a webhook endpoint

Multiple endpoints are allowed, separated by ,:

v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com,https://api.captaindns.com/tlsrpt

Each endpoint receives the same aggregated reports (one per 24 hours per sender).

rua endpoints: mailto vs https

The choice between mailto: and https: impacts deployment complexity and how reports are processed.

mailto endpoints

rua=mailto:tls-reports@captaindns.com

Properties:

reports received as email attachments (gzip-compressed JSON)
simple setup, no development required
often a dedicated address (tlsrpt@, reports@)
no cross-domain authorization required if the email is on the same domain as the record

https endpoints

rua=https://tlsrpt.captaindns.com/v1/report

Properties:

reports sent via HTTP POST to a webhook
enables real-time automated processing
requires a valid HTTPS endpoint (recognised certificate)
no cross-domain authorization required if the host is on the same domain as the record

Cross-domain authorization

When an endpoint points to a different domain than the analysed one (for instance a third-party report collector), RFC 8460 §3.3 requires recipient-side authorization:

the recipient publishes a TLSRPT record at [source-domain]._report._tls.[recipient-domain]
without this authorization, sending servers will not deliver the reports

The validator flags external endpoints missing this authorization, provided you have filled the domain field.

Invalid examples

- rua=tls-reports@captaindns.com
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto:tlsrpt
+ rua=mailto:tls-reports@captaindns.com

- rua=http://tlsrpt.captaindns.com/report
+ rua=https://tlsrpt.captaindns.com/report

Common syntax errors and fixes

Missing or wrong version

Cause: missing v= tag, or value other than TLSRPTv1.

Fix:

- rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPT1; rua=mailto:tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Missing rua tag

Cause: record contains v=TLSRPTv1 without any rua endpoint.

Fix: add at least one endpoint:

- v=TLSRPTv1
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Invalid mailto endpoint

Cause: missing mailto: scheme, malformed or truncated email address.

Fix:

- v=TLSRPTv1; rua=tls-reports@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

- v=TLSRPTv1; rua=mailto:tlsrpt@
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

Invalid https endpoint

Cause: http: scheme instead of https:, or incomplete URL.

Fix: only HTTPS endpoints are accepted by RFC 8460.

- v=TLSRPTv1; rua=http://tlsrpt.captaindns.com/report
+ v=TLSRPTv1; rua=https://tlsrpt.captaindns.com/report

Cross-domain not authorised

Cause: an external endpoint (different domain than the one analysed) points to a recipient that has not published a TLSRPT authorization record.

Fix: ask the third-party provider to publish the authorization record, or use an endpoint on your own domain:

- rua=mailto:tls-reports@uriports.com
+ rua=mailto:tls-reports@captaindns.com

Unknown tag

Cause: presence of a tag not defined by RFC 8460 (for instance ruf=, which does not exist for TLS-RPT unlike DMARC).

Fix: remove the unknown tag:

- v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com; ruf=mailto:forensic@captaindns.com
+ v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com

TLS-RPT and MTA-STS: combined deployment

TLS-RPT shines with MTA-STS. The two protocols form an inseparable duo for SMTP transport security.

Protocol	Role
MTA-STS	enforces TLS encryption for inbound mail
TLS-RPT	reports TLS connection failures and anomalies

Why deploy them together:

MTA-STS without TLS-RPT → you enforce TLS but do not know if servers fail silently
TLS-RPT without MTA-STS → you receive useful reports but no encryption enforcement
MTA-STS + TLS-RPT → you enforce AND measure, with full visibility

Recommended deployment:

Validate your MTA-STS policy with the MTA-STS Syntax Checker
Validate your TLS-RPT record with this validator
Publish TLS-RPT first (so you collect reports as soon as MTA-STS testing phase starts)
Publish MTA-STS in mode: testing
Monitor TLS-RPT reports for 2 to 4 weeks
Switch MTA-STS to mode: enforce once issues are resolved

Complementary tools and resources

Tool	When to use
TLS-RPT record check	live audit of the record published in DNS
TLS-RPT Monitoring	automatically receive and analyze your TLS-RPT reports
TLS-RPT generator	create an RFC 8460 compliant TLS-RPT record
MTA-STS syntax checker	validate the related MTA-STS policy offline
DMARC record check	round out email authentication security
DNS propagation	confirm propagation after publication

TLS-RPT: the complete guide to monitoring email TLS encryption - understand the protocol and its integration with MTA-STS.
Deploy TLS-RPT on Microsoft 365, Google Workspace and OVHcloud - step by step procedure per provider.
Analysing TLS-RPT reports: practical guide - read and act on received reports.

Specifications

RFC 8460 - SMTP TLS Reporting (official specification)
RFC 8461 - MTA-STS (companion protocol)
TLS-RPT record format (§3)
Cross-domain authorization (§3.3)