TLS-RPT Record Checker

What is TLS-RPT?

SMTP TLS Reporting (TLS-RPT) is a standard defined in RFC 8460 that enables domain owners to receive reports about TLS connectivity problems experienced by sending mail servers. When a remote server attempts to deliver email to your domain and encounters a TLS negotiation failure -- such as an expired certificate, hostname mismatch, or missing STARTTLS support -- it can send a structured JSON report to the endpoints you specify in your TLS-RPT DNS record. This gives you visibility into delivery problems that would otherwise be invisible.

TLS-RPT DNS Record Format

A TLS-RPT record is published as a TXT record at the subdomain _smtp._tls.<domain>. It uses a simple semicolon-delimited tag-value format with two tags.

Tag	Required	Description	Example
v	Yes	Version identifier. Must be TLSRPTv1.	v=TLSRPTv1
rua	Yes	Comma-separated list of report destination URIs. Supports mailto: and https: schemes.	rua=mailto:[email protected],https://report.example.com/tls

Example full record at _smtp._tls.example.com:
v=TLSRPTv1; rua=mailto:[email protected]

Report Destinations

TLS-RPT supports two types of report endpoints, each with distinct trade-offs:

Scheme	Format	Pros	Cons
mailto:	mailto:[email protected]	Simple to set up; works with any email address	Reports arrive as email attachments; harder to automate processing
https:	https://example.com/tls-report	Machine-readable; easy to integrate with monitoring pipelines	Requires running an HTTPS endpoint that accepts POST requests

For maximum reliability, configure both a mailto: and an https: endpoint so reports are not lost if one destination is temporarily unavailable.

TLS-RPT Result Types

RFC 8460 and the IANA registry define 11 result types that can appear in TLS-RPT reports, organized by category:

Result Type	Category	Description
starttls-not-supported	STARTTLS	The receiving MX does not support the STARTTLS extension.
certificate-host-mismatch	Certificate	The certificate presented does not match the expected hostname.
certificate-expired	Certificate	The server's TLS certificate has expired.
certificate-not-trusted	Certificate	The certificate chain is not trusted by the sender's CA store.
tlsa-invalid	DANE	The TLSA record is invalid or does not match the certificate.
dnssec-invalid	DANE	DNSSEC validation failed when resolving TLSA or MX records.
dane-required	DANE	DANE is required but could not be validated (e.g. missing TLSA record).
sts-policy-fetch-error	MTA-STS	The MTA-STS policy could not be fetched over HTTPS.
sts-policy-invalid	MTA-STS	The fetched MTA-STS policy has syntax errors or is invalid.
sts-webpki-invalid	MTA-STS	The MX server's certificate does not match the MTA-STS policy.
validation-failure	General	A generic TLS validation failure not covered by other types.

TLS-RPT and MTA-STS

TLS-RPT and MTA-STS (RFC 8461) are complementary standards designed to work together. MTA-STS tells sending servers to enforce TLS when delivering mail to your domain, while TLS-RPT provides the feedback loop for when that enforcement fails.

Without TLS-RPT, a domain running MTA-STS has no visibility into whether senders encounter policy enforcement problems. Without MTA-STS, TLS-RPT can only report on opportunistic STARTTLS failures -- it cannot enforce TLS. Deploying both together gives you the strongest protection: mandatory TLS enforcement with full reporting on any failures.

Further Reading

• RFC 8460 -- SMTP TLS Reporting (TLS-RPT)
• RFC 8461 -- SMTP MTA Strict Transport Security (MTA-STS)
• DMARCguard App -- Continuous DMARC, TLS-RPT and MTA-STS monitoring