TLS-RPT Checker

🛡 Deliverability & security

Check whether a domain publishes SMTP TLS Reporting, and where those reports are sent.

No sign-up required Runs on our own infrastructure Also available via API

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

When another server tries to deliver mail to you and the TLS handshake goes wrong — an expired certificate, a stripped STARTTLS, a downgrade attempt, a broken DANE record — you normally never hear about it. The sender either quietly falls back to cleartext or defers the message, and nothing lands in your logs. TLS-RPT fixes that blind spot. It’s a small DNS record that asks the world’s mail servers to send you a daily summary of how their TLS connections to you went, successes and failures alike. If you run MTA-STS or DANE, it’s the feedback loop that tells you whether your policy is protecting mail or quietly bouncing it.

What the record looks like

TLS-RPT, defined in RFC 8460, is a single TXT record at _smtp._tls.yourdomain. A minimal one looks like:

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
  • v=TLSRPTv1 — the version tag; it must come first.
  • rua= — where reports go. Two endpoint types are allowed: a mailto: address, or an https: URL that receives the report via HTTP POST. You can list more than one, comma-separated.

That’s the whole record. It doesn’t change how mail is delivered or encrypted — it only turns on reporting.

What the reports tell you

Reports arrive as JSON (gzipped), once a day per sending organisation, aggregated — not per message. Each one breaks down connection attempts by result, so you can see things like a spike in certificate-expired failures the day your cert lapsed, starttls-not-supported from a misconfigured MX, or validation-failure tied to a bad TLSA record. The value is entirely operational: it surfaces TLS problems that are otherwise invisible because the sending side absorbs them. For a domain enforcing a TLS policy, that’s the difference between catching a misconfiguration in a day and discovering it weeks later from a customer complaint.

Where it fits

TLS-RPT is the monitoring half of inbound TLS hardening; MTA-STS and DANE are the enforcement half. The sensible order is to publish TLS-RPT first, in mode: testing on MTA-STS, watch the reports until they’re clean, and only then move MTA-STS to enforce. Confirm the underlying handshake with the SMTP Test, and see the whole inbound picture in the Email Health Check.

Frequently asked questions

Does TLS-RPT change how my mail is encrypted?
No — it’s reporting only. It asks senders for daily summaries of their TLS connections to you but changes nothing about delivery. Enforcement comes from MTA-STS or DANE.
What can the rua endpoint be?
A mailto: address or an https: URL (or several, comma-separated). Reports arrive as gzipped JSON, aggregated per sender, about once a day.
Should I publish TLS-RPT before or after MTA-STS?
First — publish TLS-RPT, keep MTA-STS in testing, and read the reports until they’re clean before switching to enforce.
How often do TLS-RPT reports arrive?
About once a day from each sender that supports it, aggregated over 24 hours rather than per message — so low-traffic domains see fewer reports.