wiredepth
Run a check

Free tool · Mail transport

TLS-RPT record generator

Generate the TLS-RPT (TLS Reporting) DNS TXT record. Adds one or more mailto: / https: destinations where receiving mail servers send daily aggregate reports of MTA-STS / DANE / STARTTLS failures. Pair with MTA-STS for the full picture.

Multiple destinations are fine. Most domains have one mailto: address - either a dedicated mailbox or an ESP-provided one (EasyDMARC, dmarcian, Postmark all accept TLS-RPT reports for their customers).

DNS TXT record

Name
_smtp._tls.example.com
Type
TXT
Value
v=TLSRPTv1; rua=mailto:[email protected]

What reports look like: daily JSON aggregates with a count of successful + failed TLS connections per sending IP, broken down by failure type (STARTTLS not offered, cert hostname mismatch, MTA-STS policy fetch failed, etc.). Volume is low - a few KB / day even for large senders.

Verify after publishing: the MTA-STS + TLS-RPT checker resolves both records together.

What this tool checks

What TLS-RPT does: publishes one or more reporting URIs so receiving mail servers can tell you when their TLS handshake with your MX hosts failed. Without it, an MTA-STS enforce policy silently drops mail and you only find out when a recipient complains. With it, you get daily aggregates of every handshake failure - sending IP, count, failure type - delivered to your inbox or a collector endpoint.

Report cadence: daily, per sender ASN. Volume is small (a few KB of JSON per day even for high- volume senders). Most ESPs (EasyDMARC, dmarcian, Postmark) accept TLS-RPT reports for their customers and surface them in their UI; the easier path for an SMB is to point therua=mailto: at the ESP-provided address rather than running your own collector.

Always pair with MTA-STS.TLS-RPT alone tells you about handshake failures but doesn't do anything about them. MTA-STS without TLS-RPT means failures happen silently. Both together = published TLS expectations AND visibility when they're violated. Generate the MTA-STS record with /mta-sts-generator and publish them at the same time.

Frequently asked questions

What goes into a TLS-RPT report?

A daily JSON document with one entry per sending policy domain that attempted delivery. Each entry shows successful + failed handshakes, counts per failure type, and (when known) the sending IP and failure detail. RFC 8460 §5 has the schema.

mailto: or https: - which?

mailto: is the right default - reports arrive as email attachments and any ESP or dashboard provider can parse them. Use https: only if you operate your own collector (rare; managed dashboards are usually cheaper than building one).

Can I receive TLS-RPT for someone else's domain?

Only if they publish your address as a destination. Spec requires receivers to verify the reporting address is on the same registrable domain as the policy OR to fetch a DNS TXT record at <reporter-domain>._report._smtp._tls.<your-domain> authorising cross-domain reporting. Most ESPs handle this automatically when you onboard.

Volume?

Low. A few KB per day for typical SMB volume; tens of KB for enterprise. The reports are aggregated per receiver per day, not per message, so volume scales with how many distinct senders ship to your domain, not with how many messages you send.

Related free tools

MTA-STS generator

Pair TLS-RPT with MTA-STS - the two ship together.

MTA-STS + TLS-RPT checker

Verify the published records resolve and parse correctly.

TLS health checker

Check cert + cipher posture - TLS-RPT reports issues with this layer.

Unified domain check

One report covering TLS-RPT, MTA-STS, DMARC, SPF, and more.