TLS-RPT checker

Checks whether your domain publishes a TLS-RPT record, so servers that deliver mail to you can report when TLS to your mail servers fails.

Next

Email me this report
Every check, the record to publish and a saved link that stays live for 90 days.
Full report as HTMLRecord, copy-paste readySaved link for 90 days
One email with the report. No sequence, no sales call.
Ken sets up the domains it sends from.
SPF, DKIM and DMARC from day one, checked every day while it warms and sends.
Start free - 1,000 credits, no card

What the TLS-RPT checker does

TLS-RPT, from RFC 8460, is a TXT record at _smtp._tls.yourdomain.com. It tells sending servers where to report problems they hit while setting up TLS to deliver mail to your domain. The record looks like v=TLSRPTv1; rua=mailto:[email protected].

The checker fetches the record, validates the version and the rua addresses, which can be mailto: or https: URIs, and flags a second record, which makes senders ignore both. A record that does not start with v=TLSRPTv1 does not count, so it shows as missing.

What the reports contain

Senders that support TLS-RPT, Google among them, send a JSON report once a day, usually gzipped. It covers a date range and lists, per policy, how many sessions succeeded and failed and why.

Failure types include certificate-expired, certificate-host-mismatch, certificate-not-trusted, starttls-not-supported and sts-policy-fetch-error. Each one points at a specific fix on your MX hosts or your MTA-STS setup.

How to set it up

Pick an address that someone or something reads, or a reporting service. Publish the TXT record and check it here.

If you're adding MTA-STS, publish TLS-RPT first and run MTA-STS in testing mode while reports come in. Switch to enforce only when the reports show no failures.

Why it matters for cold email

Like MTA-STS, TLS-RPT is about mail coming in to your domain, so it doesn't change where your cold email lands.

It matters for replies. If you enforce MTA-STS on a domain that receives replies, a TLS problem on your MX means senders refuse to deliver, and TLS-RPT is how you find out before prospects tell you their replies bounced.

Questions

What is a TLS-RPT record?
A TXT record at _smtp._tls.yourdomain.com, defined in RFC 8460, that asks sending servers to report TLS problems with your mail servers. It's v=TLSRPTv1 followed by rua= and one or more report addresses.
Do I need TLS-RPT without MTA-STS?
It's useful, not essential. Reports still cover problems like an expired certificate on your MX. Its main job is to run alongside MTA-STS or DANE, so you see failures before you enforce.
What does a TLS-RPT report look like?
A JSON file, usually gzipped, sent once a day by each reporting organization. It names the date range and, for each policy, counts successful and failed sessions with a failure type such as certificate-expired or starttls-not-supported.
Who sends TLS-RPT reports?
Large providers that support MTA-STS, Google among them. Many smaller mail servers don't, so a quiet report inbox doesn't prove every sender connected fine.
Can TLS-RPT reports go to an HTTPS endpoint?
Yes. RFC 8460 allows rua=https:// URLs, and reports arrive as POST requests. Most domains use mailto: because it needs no server.

More in Deliverability

30 tools.