TLS-RPT Checker
Validate a domain's SMTP TLS Reporting configuration — look up the _smtp._tls DNS TXT record, validate rua reporting URIs, and get a plain-English security assessment with actionable recommendations.
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting) is an email standard defined in RFC 8460 that instructs sending mail servers to submit daily JSON reports about SMTP TLS connection failures when delivering email to your domain. Without TLS-RPT, certificate errors, MTA-STS policy failures, and other TLS delivery issues are silent — email either fails to arrive with no diagnostic information, or senders silently fall back to less secure delivery paths.
TLS-RPT is a reporting-only standard. Publishing a TLS-RPT record has no effect on whether email is delivered or rejected. It only causes supporting senders to send you reports. This makes it safe to deploy at any time, without risk to email delivery.
For email admins and MSPs: TLS-RPT is an essential companion to MTA-STS. When you deploy MTA-STS in testing mode, TLS-RPT reports reveal whether any senders encounter TLS certificate errors before you switch to enforce mode. Without TLS-RPT, switching to MTA-STS enforce mode carries the risk of silently blocking email delivery from senders that cannot establish authenticated TLS connections to your mail servers.
How TLS-RPT works
TLS-RPT requires a single DNS TXT record. When a sending mail server prepares to deliver email to your domain, it looks up the TLS-RPT record to determine where to send any failure reports. At the end of each reporting period, senders aggregate all TLS failures and send a JSON report to your designated address.
The TLS-RPT record
Add a TXT record at _smtp._tls.yourdomain.com. The record contains two fields: v=TLSRPTv1 (the protocol version) and rua= (one or more reporting URIs separated by commas). The rua field supports mailto: and https: URI schemes.
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Reporting URI types
mailto: — The report is emailed as a JSON attachment (gzip-compressed). The simplest option — no infrastructure required.
https: — The report is HTTP POSTed to a URL. Used by report aggregation services (Report URI, Postmark, DMARC Analyzer) that parse and visualise reports. Both types can be combined for redundancy.
v=TLSRPTv1; rua=mailto:[email protected], https://report.example.com/tls
What TLS-RPT reports contain
TLS-RPT reports are JSON documents following the schema in RFC 8460. Each daily report from a sending organisation covers the previous 24-hour period and includes both successful and failed TLS sessions.
Report structure
- Organisation name — the sending mail provider submitting the report
- Date range — the reporting period (typically one calendar day)
- Policy — the TLS policy type evaluated (MTA-STS, DANE-TLSA, or STARTTLS)
- Summary — total successful and failed sessions for the period
- Failure details — the type of failure, affected MX hosts, and session count
Common failure types
- certificate-expired — MX server's TLS certificate has expired
- certificate-not-trusted — certificate is not issued by a public CA
- starttls-not-supported — MX server does not offer STARTTLS
- mx-mismatch — MX hostname doesn't match MTA-STS policy patterns
- sts-policy-fetch-error — MTA-STS policy file could not be retrieved
- validation-failure — general TLS validation error
TLS-RPT and MTA-STS: companion standards
TLS-RPT and MTA-STS are designed to be deployed together. MTA-STS (RFC 8461) defines a policy requiring senders to authenticate TLS when delivering email to your domain. TLS-RPT provides the reporting channel that gives you visibility into whether that policy is working correctly before and after enforcement.
| Standard | Purpose | Effect on delivery | Deployment order |
|---|---|---|---|
| TLS-RPT | Reports TLS failures to a designated address | None — reporting only | Deploy first to establish a baseline |
| MTA-STS (testing) | Publishes a TLS policy; senders report but don't reject | No impact — senders still deliver | Deploy second, alongside TLS-RPT |
| MTA-STS (enforce) | Requires senders to authenticate TLS or refuse delivery | Can block mail if TLS fails | Deploy last, after validating with TLS-RPT |
Recommended approach: Publish TLS-RPT first with a
mailto: address you monitor. Then publish MTA-STS
in testing mode. Wait 2–4 weeks and review the TLS-RPT reports — any failures will appear
here before they can block mail. Once you confirm zero failures, switch MTA-STS to
enforce mode. Use the
MTA-STS Checker
to validate your MTA-STS configuration.
Where TLS-RPT fits in the email security stack
A fully hardened email configuration uses multiple standards that protect different parts of the email delivery process. TLS-RPT is the visibility layer — it tells you when other standards are encountering problems.
Outbound email authentication
- SPF — Specifies which servers are authorised to send on behalf of your domain.
- DKIM — Cryptographically signs messages so receivers can verify authenticity.
- DMARC — Ties SPF and DKIM together; specifies what to do with failing messages and where to send aggregate reports.
Inbound delivery channel protection
- MTA-STS — Requires senders to authenticate TLS. Prevents downgrade attacks on SMTP delivery.
- TLS-RPT (this tool) — Collects TLS failure reports from senders. Gives visibility into certificate and MTA-STS issues before they block delivery.
- DNSSEC — Authenticates DNS records. Protects the TLS-RPT and MTA-STS records themselves from DNS spoofing.
Frequently asked questions
What is TLS-RPT and why should I set it up?
TLS-RPT (SMTP TLS Reporting, RFC 8460) instructs sending mail servers to send daily JSON reports about SMTP TLS failures when delivering email to your domain. Without TLS-RPT, certificate errors and TLS policy failures are invisible — you will not know if senders are encountering problems delivering to your mail servers. TLS-RPT is a reporting-only standard with no effect on delivery, making it safe to deploy at any time. It is especially valuable if you plan to deploy MTA-STS, as it provides the reporting channel needed to validate the configuration before enabling enforcement.
How do I set up TLS-RPT?
Add a DNS TXT record at _smtp._tls.yourdomain.com with the value: v=TLSRPTv1; rua=mailto:[email protected] — replacing the email address with one you monitor. For structured reporting with a dashboard, replace or supplement the mailto: address with an https: endpoint from a report aggregation service such as Report URI, Postmark, or DMARC Analyzer. No other changes are needed — TLS-RPT does not require a policy file or subdomain setup.
Will TLS-RPT affect my email delivery?
No — TLS-RPT is a reporting standard only. Publishing a TLS-RPT record has no effect on whether email is delivered to or from your domain. It simply instructs supporting senders to report TLS failures. Unlike MTA-STS enforce mode, TLS-RPT never causes delivery failures or rejections. You can publish a TLS-RPT record at any time without risk to existing email delivery.
What is the difference between rua in TLS-RPT and rua in DMARC?
Both TLS-RPT and DMARC use a rua field (Reporting URI for Aggregate) to specify where reports should be sent, but they are separate standards covering different aspects of email security. DMARC rua receives reports about SPF and DKIM authentication failures (the sending authentication layer). TLS-RPT rua receives reports about SMTP TLS connection failures (the transport security layer). They should be configured at different DNS names: DMARC is at _dmarc.yourdomain.com, TLS-RPT is at _smtp._tls.yourdomain.com. Both are recommended for a complete email security posture.
How often are TLS-RPT reports sent?
TLS-RPT reports are sent once per day, typically covering the previous 24-hour period. The exact timing varies by sending organisation — Google, Microsoft, and Yahoo each have their own reporting schedules. For high-volume domains, reports may arrive from many different sending organisations. For low-volume domains, you may only receive reports from one or two providers. Reports are sent for both successful deliveries (summary statistics) and failures (detailed error information).
Should I use mailto: or https: for the rua endpoint?
For most organisations, starting with a mailto: address is the easiest approach — no infrastructure is needed, and reports arrive as email attachments you can inspect manually. If you prefer a dashboard and structured analysis, use an https: endpoint from a report aggregation service. Using both types together provides the best coverage: if the HTTPS endpoint is temporarily unavailable, reports continue to arrive via email. The combined format is: rua=mailto:[email protected],https://report.example.com/tls.
What is the size limit suffix in a TLS-RPT rua URI?
RFC 8460 allows an optional size limit to be appended to each rua URI using the format !, for example mailto:[email protected]!10m (limit to 10 megabytes) or https://reports.example.com/tls!50m. If a report exceeds the size limit for a particular endpoint, the sender should attempt delivery to the next endpoint in the rua list. This is optional and most implementations omit the size limit.
What does this tool check?
This tool queries the DNS TXT record at _smtp._tls.yourdomain.com via Cloudflare DNS-over-HTTPS. It validates the record syntax — checking that v=TLSRPTv1 is present and correct, that the rua field contains at least one valid URI, and that each URI uses a supported scheme (mailto: or https:). It generates a security score from 0–100, a plain-English summary, PASS/WARN/FAIL findings, and actionable recommendations. TLS-RPT has no HTTPS-served file equivalent to MTA-STS, so this check involves DNS only.