TLS-RPT is one of those email infrastructure features that produces useful data but is widely ignored. The reports describe TLS connection issues between mail servers. They reveal misconfiguration, certificate problems, downgrade attacks, and network issues that affect mail delivery. Most operators have heard of TLS-RPT but few are actively analyzing the reports they receive.

We have been collecting and analyzing TLS-RPT reports across our customer infrastructure for about two years. The data set is now about 100,000 reports. The patterns in the data reveal infrastructure issues that senders rarely diagnose through other means.

This post is what we have learned from parsing 100,000 TLS-RPT reports. The patterns, the surprises, the actionable findings, and how to use the data operationally.

What TLS-RPT actually is

TLS-RPT (TLS Reporting) is specified in RFC 8460. The mechanism allows mail domains to publish a DNS record declaring where to send aggregate TLS reports. Other mail servers that have TLS issues delivering mail to the publishing domain send reports describing what went wrong.

The reports cover scenarios like:

TLS certificate validation failures
Downgrade from TLS to plain text
MTA-STS policy validation failures
DANE validation failures (where applicable)
Connection timeouts and failures during TLS negotiation

The reports are aggregated by day rather than per-message. Each report covers a 24-hour window for one specific sending-receiving pair.

The TLS-RPT DNS record looks like:

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

The rua parameter specifies where reports should be sent. The receiving mail server uses this to know where to deliver aggregate reports.

Why most operators ignore TLS-RPT

Despite being available for years, TLS-RPT adoption among senders is low. Several reasons:

The reports are not actionable for senders. TLS-RPT describes problems that other mail servers had when sending TO the publishing domain. The publishing domain is a receiver, not a sender. Most operators are senders worried about delivery TO others rather than receivers worried about acceptance FROM others.

The reports are in machine-readable format that requires parsing. The JSON-formatted reports do not produce immediate human-readable insight without processing.

The reports describe edge cases. Most TLS connections succeed without issues. The reports document the small percentage of connections that fail. Without volume, the failures look like noise rather than patterns.

The benefit is unclear. Even with reports, the actions to take are not obvious. TLS issues at the connection level seem like they should be the other party’s responsibility.

Despite these factors, TLS-RPT data is operationally valuable for several specific purposes that emerge when you actually analyze the reports at scale.

The customer infrastructure we monitor

Our analysis covers TLS-RPT reports for approximately 60 customer domains that publish TLS-RPT records. The domains span:

ESP customer brands serving end-customer email Self-hosted mail customers with personal/family domains Enterprise customers with corporate mail infrastructure Privacy-focused customers with sensitive operational requirements

The aggregate volume is about 100,000 reports analyzed over two years. The data includes all major TLS failure categories.

What we have learned: the headline findings

Finding 1: TLS adoption is high but not universal

The reports document that approximately 92-95% of all SMTP connections to our customer domains use TLS. The remaining 5-8% are either explicit downgrades or connections from older mail servers without TLS support.

The 95% adoption rate is much higher than industry estimates often suggest. It reflects the fact that major mailbox providers (Gmail, Microsoft, Yahoo, Apple) have been requiring TLS for outbound mail since the late 2010s. Older operators without TLS are now a minority.

The 5-8% without TLS includes:

Older corporate mail servers (typically smaller organizations not running modern infrastructure)
Legacy mail systems running outdated software
Some specific edge cases (forwarding chains, certain monitoring systems)

For senders, this means: TLS issues affect a small but real percentage of mail. The 5-8% is not negligible at scale.

Finding 2: Certificate validation failures are the most common issue

The most frequent failure category in our reports is certificate validation. Approximately 45-55% of all failure reports relate to certificate issues.

Specific patterns:

Expired certificates: about 20% of certificate failures
Hostname mismatch: about 35% of certificate failures
Untrusted certificate authority: about 15% of certificate failures
Self-signed certificates: about 25% of certificate failures
Various other validation issues: about 5%

The implication: many mail servers in the wild have certificate misconfigurations that prevent successful TLS connections. The senders running those servers may not realize they have the issues because the connections appear to be working from their side (the connection succeeds but with degraded or rejected TLS).

Finding 3: MTA-STS validation failures reveal specific patterns

Approximately 18-22% of reports document MTA-STS policy validation failures.

MTA-STS (RFC 8461) is a mechanism allowing receiving domains to publish their TLS policy. The policy can be “enforce” (TLS required), “testing” (TLS preferred but not required), or “none” (no specific requirement). Receiving servers indicate their policy and the requirements (specific MX hostnames, specific certificate authorities, etc.).

Failures we observe:

MTA-STS policy fetch failures (about 30% of MTA-STS failures): the policy URL was inaccessible at the time
MX hostname mismatch (about 40%): the receiving MX did not match the published policy
Certificate authority restrictions (about 15%): the server’s certificate was not from an authority specified in the policy
Other policy violations (about 15%): various edge cases

These failures often indicate specific configuration issues that the receiving domain operator should know about. The reports we collect provide actionable feedback to the publishing operator.

Finding 4: Downgrade attacks are rare but detectable

We see approximately 2-4% of reports document apparent TLS downgrade scenarios. The pattern: connection started with TLS, then plain text fallback was negotiated due to some failure.

Some of these are legitimate: certain mail servers retry with plain text after TLS handshake failure, and the report reflects the legitimate fallback. Others may be interception attempts: a network actor between the sending and receiving servers may have manipulated the TLS negotiation to force plain text.

Distinguishing legitimate fallback from attack scenarios is operationally difficult. The patterns we observe suggest most downgrade reports are legitimate fallback. The small percentage that may represent attack scenarios is concentrated in specific network paths (specific source networks, specific destination networks) that warrant investigation.

For privacy-sensitive customers (journalism, legal, opposition political), the downgrade patterns are operationally informative. Sustained downgrade from specific paths warrants security investigation.

Finding 5: DANE validation issues are uncommon but informative

About 1-3% of reports document DANE validation failures. DANE (DNS-based Authentication of Named Entities) is a security mechanism using DNS records to validate TLS certificates.

DANE adoption is limited. Most mail servers do not implement DANE. Our customers who do publish DANE records see reports from the small percentage of mail servers that try to validate against DANE.

The reports are informative because they reveal which sending mail servers have DANE awareness. The senders with DANE-aware infrastructure are the ones most actively monitoring TLS security.

The specific actionable findings

Beyond the aggregate patterns, the TLS-RPT data produces specific actionable findings.

Finding A: Certificate expiration detection

We have used TLS-RPT data to detect customer certificate issues 5 times over the two-year monitoring period. The pattern:

A customer’s mail server has certificate expiring soon (typically 1-2 weeks before expiration). The certificate is still technically valid so no immediate failures occur.

Some sending servers (those with strict TLS implementations) start refusing connections during the certificate’s last few days of validity. The customer’s mail starts producing TLS-RPT reports from these strict senders.

We see the reports, identify the certificate issue, alert the customer. The customer renews the certificate before broader failures occur.

The 5 incidents we caught this way represent meaningful customer impact prevented. Each incident would have produced significant deliverability degradation when the certificate fully expired without intervention.

Finding B: MTA-STS policy errors

We have identified 3 customer MTA-STS misconfigurations through TLS-RPT reports.

Each case involved a customer publishing MTA-STS policy that did not exactly match their actual MX configuration. The mismatch caused validation failures at TLS-RPT-reporting senders. Other senders without TLS-RPT did not produce reports but were likely also affected.

The remediation: align the MTA-STS policy with the actual MX configuration. The work is bounded but requires the customer to verify their actual server configuration matches their published policy.

Finding C: Specific sender network issues

Some patterns of TLS-RPT reports concentrate from specific sender networks. The concentration indicates either issues with that specific network’s TLS infrastructure or potentially issues with how that network handles TLS negotiation.

We have identified 4 specific sending networks that produced systematic TLS issues. The networks were:

One specific corporate network with broken intermediate certificate handling
One specific marketing platform with TLS implementation issues
One specific ISP that was downgrading TLS connections in transit
One specific email security gateway that was breaking TLS chains

The information was useful for understanding why specific customer subsets had delivery issues. In some cases, the customer could contact the sending entity to resolve the issue. In others, the customer accepted the persistent issue as cost of operating with those specific recipients.

Finding D: Geographic patterns

TLS issues correlate with sender geographic regions. Some patterns:

Higher TLS issue rates from specific countries with older infrastructure Higher MTA-STS validation failures from senders behind specific national firewalls Lower TLS adoption from specific small business categories

The geographic patterns inform customer expectations. A customer with B2B operations in specific regions may experience more TLS issues than equivalent customers in other regions. The pattern is operational baseline rather than fixable issue.

How we collect and process the reports

The infrastructure for collecting and processing TLS-RPT reports is bounded.

Receiving the reports

The customer publishes a TLS-RPT DNS record pointing to an email address we operate. The address receives the aggregate reports from senders.

The volume per customer is typically low: 1-10 reports per day for moderate-volume customers. Higher-volume customers receive more reports.

Parsing the reports

TLS-RPT reports are JSON-formatted. We parse the JSON into a structured database with fields for:

Reporting domain (the sender experiencing the issue) Receiving domain (the customer publishing TLS-RPT) Reporting time range Total connection attempts Successful connections Failed connections with categorization Failure-specific details (certificate info, policy info, etc.)

Aggregation and analysis

Daily aggregation produces summary statistics per customer. Weekly aggregation produces trend analysis. Monthly aggregation produces comparative analysis across customers.

The analysis runs as scheduled jobs producing dashboard data and alert triggers. The alerting threshold: more than 10x baseline failure rate for any customer triggers immediate investigation.

Customer-facing presentation

Customers receive monthly summaries of TLS-RPT data for their domains. The summary includes:

Overall TLS adoption rate Failure category breakdown Significant senders producing failures Any actionable findings

Most customers do not actively review the summaries but the data is available for those who do. The summaries support the documentation of customer infrastructure health over time.

What TLS-RPT does not catch

Several issue categories are not captured by TLS-RPT.

Sender-side TLS issues for the customer’s outbound mail

TLS-RPT reports describe issues senders had connecting TO the customer’s domain. It does not describe issues the customer’s mail servers have connecting OUT to other domains. Outbound TLS issues require different mechanisms (sender-side logging, receiver-side monitoring at the destinations).

Mail that did not attempt TLS

Older mail servers that connect without attempting TLS produce no TLS-RPT reports. The connection succeeds in plain text and the receiver decides whether to accept. TLS-RPT only documents connections that attempted TLS and had issues.

Encrypted content within TLS

TLS-RPT addresses the transport layer encryption. End-to-end content encryption (PGP, S/MIME) is separate. TLS-RPT does not indicate whether messages are content-encrypted.

Mail server availability issues

Connection failures unrelated to TLS (TCP failures, mail server downtime) do not generate TLS-RPT reports. The reports specifically address TLS negotiation problems.

Based on our analysis experience:

Publish TLS-RPT records

The cost of publishing TLS-RPT is minimal: one DNS record. The benefit is meaningful: visibility into TLS issues at your domain.

For customer mail domains, we recommend publishing TLS-RPT records as part of standard mail infrastructure setup.

Set up basic monitoring

Even without sophisticated analysis, monitoring TLS-RPT reports for unusual volumes or patterns catches issues that would otherwise go undiagnosed.

A simple monitoring approach: alert on report volume above baseline. The alerts indicate something unusual is happening that warrants investigation.

Certificate-related TLS-RPT findings are typically actionable. Either the customer’s certificate has issues (renewal needed, configuration update needed) or specific sending parties have issues (informational for understanding patterns).

The investigation cost is bounded; the prevention benefit is meaningful.

Investigate MTA-STS findings if you publish MTA-STS

For customers publishing MTA-STS, monitoring the policy validation failures is important. Misconfigured policies degrade deliverability without producing obvious symptoms.

Use the data for compliance documentation

For customers with security compliance requirements, TLS-RPT data documents the TLS security posture of the mail infrastructure. The documentation supports audit and compliance activities.

Aggregate across customer base if you operate one

For ESPs and operators running multiple customer domains, aggregating TLS-RPT data across customers produces broader pattern visibility. The aggregate data informs infrastructure decisions that benefit all customers.

Several practices we have seen that are counterproductive.

Ignoring TLS-RPT entirely

The cost of publishing TLS-RPT is minimal. Not publishing means accepting blind spots in TLS issue visibility. The blind spots may not matter for many domains but they accumulate as the infrastructure becomes more security-conscious over time.

Acting on individual reports without aggregation

A single TLS-RPT report may reflect a transient issue rather than a persistent problem. Acting on every individual report produces operational thrash without meaningful improvement.

The aggregation matters. Patterns across multiple reports are actionable; individual reports are typically noise.

Treating TLS-RPT as outbound-relevant

TLS-RPT is about how senders connect TO you. It does not directly inform how you connect to others. Treating it as a comprehensive TLS picture misses the outbound dimension.

For outbound TLS monitoring, other mechanisms (sender-side logging, destination-side reports, manual testing) are needed.

Over-investing in TLS-RPT relative to other infrastructure

TLS-RPT is one element of mail infrastructure. The bigger issues for most operations are authentication (SPF, DKIM, DMARC), reputation management, content quality. TLS-RPT optimization should not crowd out these higher-impact concerns.

The right framing: TLS-RPT is a small but valuable tool. Use it appropriately for its scope. Do not over-invest in it.

What we see going forward

Looking at TLS-RPT and related mechanisms over the coming years:

Adoption will continue increasing. As more domains publish TLS-RPT records, more data is available for the ecosystem to learn from.

Tooling will improve. Currently, TLS-RPT analysis requires custom tooling. Vendors are starting to offer TLS-RPT analytics as part of broader email security products.

The data will become standard for security audits. As regulatory and compliance frameworks tighten, TLS-RPT data becomes documentation that supports compliance claims.

The mechanism may evolve. RFC 8460 is the current standard but improvements are possible: more granular reporting, faster reporting frequency, additional failure categories.

The overall trend is toward more telemetry about email infrastructure security. TLS-RPT is one element of this trend. Operators investing in the infrastructure to handle this telemetry are positioned well for the trend.

What we built for our customers

Based on the analysis experience, we offer specific TLS-RPT services to customers.

Standard TLS-RPT collection

Customers publishing TLS-RPT records can use our endpoint as the reporting destination. We collect the reports and provide monthly summaries.

The service is included in our standard managed services for customers who want it. No additional cost.

Active monitoring with alerting

For customers who want proactive notification of TLS issues, we provide active monitoring with email/Telegram alerts when patterns indicate issues.

The service is appropriate for customers running their own mail servers (rather than using mainstream ESPs) where they have operational responsibility for TLS configuration.

Quarterly analysis reports

Customers receive quarterly analysis of their TLS-RPT data with comparisons to baseline and other customers (anonymized).

The reports support customer documentation and provide context for infrastructure decisions.

Specific incident response

When customer TLS-RPT data indicates significant issues, we provide incident response assistance. Diagnosis, remediation planning, coordination with affected parties.

The honest assessment

TLS-RPT is operationally useful but bounded. The data tells us things we would not otherwise know. It does not tell us everything we need to know about mail infrastructure.

The 100,000 reports we have analyzed produced approximately 12 specific actionable incidents across the customer base. The incidents would not have been caught through other monitoring. The TLS-RPT data captured them.

The investment in TLS-RPT collection and analysis is bounded: a few hundred hours of engineering to build the infrastructure, ongoing minor operational time for monitoring. The benefit is bounded but real: detection of a class of issues not otherwise visible.

For operators considering whether to implement TLS-RPT: the cost is low, the benefit is real but specific, the implementation is bounded. Worth doing for customer-facing infrastructure. Not worth elaborate over-engineering. Treat it as a small but valuable tool in the larger mail infrastructure operational toolkit.

The data we have collected is genuinely useful. The patterns we have learned are operationally informative. The customer outcomes from TLS-RPT-driven actions are real. The category is mature enough to recommend implementation; the implementation should be appropriate to scale rather than aspirational.

For our customer base, TLS-RPT will continue to be a standard element of our managed mail infrastructure. The data will continue accumulating. The patterns will continue refining. The detection of specific issues will continue paying back the implementation investment over time. The category is here to stay, and operators investing in it now will benefit from years of accumulated infrastructure improvements over the coming years.