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

The validator analyzes a record you paste, before DNS publication, without reading the configuration already in place. 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 URI, malformed email address, and an unknown tag inherited from DMARC such as ruf= which does not exist for TLS-RPT.

Do I need authorization to send reports to another domain?

No. Unlike DMARC, TLS-RPT requires no recipient-side authorization record for an external rua: RFC 8460 dropped that mechanism. A URI pointing to a third-party service is therefore valid as-is, and the validator never rejects a record because of an external rua.

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 Check

Why use an offline validator

A TLS-RPT syntax validator analyzes your record without publishing or querying DNS. This offline approach covers four 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 depending on public DNS, for instance on a pre-production record that is not published yet.
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 on syntax: TLSRPTv1 version, rua tag, mailto: and https: URI formats, and absence of unknown tags. Validation runs on our servers: the record you paste is sent to CaptainDNS to be analyzed. Nothing gets published, though, no DNS query is issued and no rua URI is contacted.

How to use this validator in 2 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 reads no external source: only the text you supply is analyzed.

Step 2: 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 in the lifecycle of a TLS-RPT record.

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
External URI identification	None	Automatic
Published value detection	Static	Real state
Data sent to server	The pasted record	Domain being analyzed

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.

One field, one mode

The form exposes a single input: the TLS-RPT record itself. No domain, no second mode. What gets checked:

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

That bareness comes straight from RFC 8460. DMARC demands a _report._dmarc authorization record on the recipient side as soon as reports leave for another domain; §7 of RFC 8460 deliberately dropped that mechanism for TLS-RPT. So there is nothing to weigh your rua URIs against: an address at a third-party report collector is valid as-is.

To find out which of your already published URIs leave your domain, the record check spots them from the domain it queries.

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 recognized 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 recipient-side authorization required, even for an address on a different domain than 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 (recognized certificate)
no recipient-side authorization required, even for a host on a different domain than the record

External URIs (rua to another domain)

When a URI points to a different domain than the analyzed one (for instance a third-party report collector), TLS-RPT requires no authorization on the recipient side:

Unlike DMARC and its _report._dmarc record, RFC 8460 defines no verification mechanism: its §7 deliberately dropped any cross-domain authorization
An external URI is therefore valid as-is; sending servers deliver the reports with no prior check on the recipient side

The validator never rejects them. It does not single them out either: with no reference domain, it has nothing to compare them against.

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

External URI: this is not an error

Good to know: a rua URI pointing to another domain (third-party collector) is perfectly valid. Unlike DMARC, TLS-RPT mandates no recipient-side authorization record: the validator never rejects a record because of an external rua.

You can therefore point to a third-party provider with confidence:

v=TLSRPTv1; rua=mailto:tls-reports@uriports.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 the 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.
Analyzing 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)
Security considerations - external rua (§7)