Who Sends TLS-RPT Reports?

Why don’t most email senders see TLS-RPT reports?

You’re sending secure email, your TLS connections are working, and your messages are reaching inboxes. But have you ever wondered if Gmail, Microsoft, or other major providers are quietly sending you reports about those connections?

Most senders don’t see TLS-RPT reports—not because they’re not being sent, but because they’re not set up to receive them. These reports aren’t public or broadcast. They’re delivered only to a specific email address configured by a domain owner through a DNS TXT record. Without it, you’re blind to connection-level security feedback.

Key takeaways

TLS-RPT reports are sent only to domains that publish a TLS-Reporting TXT record in DNS.
Providers like Gmail and Microsoft deliver TLS-RPT reports to the designated email address, not to all senders.
Most senders don’t monitor reports because parsing them requires technical setup and provides delayed, non-immediate feedback.

Who sends TLS-RPT reports in 2026 — Gmail, Microsoft, and others?

Gmail, Microsoft (Outlook, Hotmail, Live), Yahoo Mail, Apple Mail (iCloud), and AWS SES send TLS-RPT reports for authenticated outbound emails sent through their infrastructure. Smaller or older email services often don’t implement TLS-RPT at all, leaving gaps in visibility. You can use tools like MailTester’s inbox placement tests to validate your domain’s email delivery posture.

Gmail and Microsoft: Leaders in TLS-RPT Reporting

Gmail, powered by Google, sends TLS-RPT reports for all outbound messages from domains it authenticates via SPF, DKIM, or DMARC. This includes email sent through Google Workspace, Gmail user accounts, and any third-party service that routes through Google’s infrastructure. Microsoft, through Outlook.com and its cloud email services like Office 365 and Exchange Online, also generates TLS-RPT reports for authenticated outbound mail. If you’re setting up domain-level authentication, these reports give you clear insight into whether TLS connections were successfully established.

Other Providers and the Fragmented Reality

Yahoo Mail and Apple’s iCloud mail services send TLS-RPT reports under certain configurations, especially when sending through their official APIs or managed services. AWS SES also supports TLS-RPT, but only for domains configured with proper authentication records (SPF/DKIM) and TLS enabled in the sending configuration. These reports are typically delivered weekly or after specific failure events, and they’re often used for compliance and performance monitoring. However, the adoption rate drops sharply among smaller ISPs, legacy email platforms, or internal corporate setups that still rely on older SMTP configurations — meaning they may not send any TLS-RPT data at all.

Let’s be clear: the presence of TLS-RPT doesn’t guarantee that every message was delivered — it only confirms that the TLS handshake occurred. You’ll still need tools like MailTester’s inbox placement test to know whether your messages actually arrived in the inbox, not the spam folder.

Why This Matters for Your Deliverability

These reports help you confirm that your emails are being secured in transit, but they’re not a full measure of deliverability. A failed TLS connection can still allow delivery, which is why you need both reports and active testing. Tools like MailTester’s bulk verification and real-time API help you validate your email list before sending, reducing the chance of rejection or misdelivery. For teams managing large volumes, integrating with MailTester via Mailchimp, HubSpot, Klaviyo, or SendGrid automates verification without breaking flow.

How does a domain receive a TLS-RPT report?

You receive a TLS-RPT report when your domain publishes a valid _tlsrpt TXT record in DNS, and a reporting domain like Gmail or Microsoft sends a daily, compressed JSON report to the address listed there. These reports arrive once per 24 hours, usually between 3–6 AM UTC, and must be automatically processed by a dedicated mail handler or parser. Without proper setup, you’ll miss visibility into TLS handshake failures across your sending infrastructure.

Step-by-step: How the reporting process works

Publish the _tlsrpt TXT record in your domain’s DNS zone. The record must include the domain name that will receive reports (e.g., _tlsrpt.example.com). This tells reporting systems where to send TLS failure data.
Ensure the reporting address in the TXT record is valid and deliverable. The email address listed must resolve to a working mailbox or automated handler. If the mailbox doesn’t exist or blocks email, reports will be rejected.
Configure your mail system to accept reports. Set up a dedicated mailbox or script to auto-accept and parse incoming TLS-RPT reports. These are sent as compressed JSON files and not human-readable emails, so manual handling won't work.
Process reports daily. Reports are sent once per day, typically between 3–6 AM UTC. They contain aggregate data on TLS handshake failures from sending domains trying to reach your mail servers.
Analyze failures for configuration issues. Use the report data to identify if mail clients are failing to upgrade connections, if certificates are misaligned, or if a sending service is misconfigured. This directly informs security and deliverability improvements.

What to expect from the reports

Each report is formatted as a gzip-compressed JSON file sent via SMTP to the address specified in your DNS TXT record. It includes information on failed TLS connections, the sending IP, the destination domain, and timestamp data. The reporting frequency is strict: one per day, no exceptions.

The 5 steps described in “Step-by-step: How the reporting process works”, in order.

Industry standards for these reports are defined in RFC 8460, which outlines the format and purpose. Large providers like Google and Microsoft follow this specification when sending TLS-RPTs. You can’t force a report to arrive early or trigger one manually — it’s fully automated and based on observed delivery outcomes.

For teams running high-volume outbound email, monitoring these reports is essential. Misconfigured TLS settings can lead to rejected messages or poor reputation, especially in email systems that prioritize encrypted delivery. You can use MailTester’s inbox placement testing to validate whether TLS issues affect inbox delivery in real-world environments.

Keep in mind: a report won’t tell you if your own domain’s mail server is misconfigured. It only tells you what other domains experienced when sending to your server. To verify your own SMTP setup, check with a service like real-time verification API or test your outbound flow with bulk verification.

What information does a TLS-RPT report contain?

TLS-RPT reports tell you whether a TLS connection was successfully established between your server and a recipient's mail server during message delivery. They include the date range, recipient domain, sender IP, TLS version, cipher suite used, and the handshake result—success, failure, or renegotiation. These reports do not reveal message content, sender identity, or final delivery status beyond transport-layer security.

Key elements in a TLS-RPT report

The report provides a detailed log of the TLS negotiation process. It documents the sender’s IP address and the receiving domain, which helps identify misconfigurations or policy issues. You’ll see the TLS version (e.g., TLS 1.2 or 1.3) and the cipher suite negotiated, both of which affect overall security. The outcome—success, failure, or renegotiation—shows whether encryption was properly established.

Failures often point to concrete issues: an outdated server policy, a missing or expired certificate, or an intermediate certificate chain that’s not trusted. These are usually fixable with a simple certificate update or configuration adjustment. A reported failure doesn’t mean your message didn’t arrive—it only indicates the transport layer encryption failed during handshaking.

What TLS-RPT does not include

It’s important to understand what these reports don’t expose. They don’t contain the message body, sender email address, or subject line. They also don’t confirm whether a message was successfully delivered to the recipient’s inbox—only whether the encrypted transport layer was established.

This distinction matters for diagnostics. If you’re relying on TLS-RPT to troubleshoot delivery issues, you’re looking at one layer of the chain. A failure here means encryption wasn’t achieved, but the message might still have been delivered via plain SMTP or through a different relay. For full visibility, combine TLS-RPT analysis with delivery tracking, bounce reports, and inbox placement tests.

Understanding TLS-RPT data helps harden your outbound mail stack. You can use such reports to identify servers with weak or absent TLS configurations—common vulnerabilities in third-party senders or outdated systems. For teams managing high-volume email, checking TLS configuration across all domains in your list can prevent future blocklists or poor reputation.

For a deeper check on your sender setup, test how your messages are received across different providers. MailTester’s inbox placement tester simulates delivery to Gmail, Microsoft, and other providers, showing whether your email lands in the inbox, spam, or is blocked. You can also verify your list for invalid or risky addresses with bulk verification, reducing bounce rates and improving sender reputation.

How do ISPs react when TLS-RPT reports show failures?

ISPs like Gmail and Microsoft use TLS-RPT reports to flag repeated handshake failures as indicators of misconfigured or insecure infrastructure. Consistent issues can lower sender trust scores, trigger throttling, or lead to temporary restrictions on message volume—especially if paired with other red flags like high bounce rates or spam complaints.

Failures signal infrastructure risk

When TLS-RPT reports show repeated handshake failures, it’s a red flag to Gmail, Microsoft, and other major providers. They interpret this not just as a technical hiccup but as evidence of underinvestment in email security or misconfigured servers. You’re not just failing to encrypt—the underlying system may be vulnerable or unstable.

These reports are part of a layered reputation score. They don’t alone block mail, but they contribute to how ISPs assess sender health. If you’re seeing regular TLS-RPT failure reports, even a single one over time can impact your ability to reach inboxes, especially if you're sending at scale.

Reputation is cumulative

Think of TLS-RPT data as one input in a larger machine learning model used by ISPs to assess sender integrity. Consistent handshake issues—especially when combined with high spam complaints, poor deliverability, or poor list hygiene—can push your sender score into a risk zone.

Mailchimp, SendGrid, and Microsoft’s own transactional systems are known to reduce throughput or delay message delivery when they detect sustained TLS issues. This isn’t arbitrary: RFC 8460, which governs TLS-RPT, was built precisely to help ISPs identify and address misconfigurations before they become a security problem [IETF, TLS-RPT specification].

Let’s be clear: one failed handshake isn’t enough to get blocked. But patterns matter. If TLS-RPT reports show failures across tens or hundreds of transactions daily, ISPs treat that as a persistent risk. They may reduce your sending limits, delay inbox placement, or apply stricter filtering over time.

Proactive verification helps catch this early. You can use tools like MailTester’s inbox placement tester to spot TLS issues before you send. The same tools can validate that your domain’s security records—SPF, DKIM, and DMARC—are correctly configured to support TLS encryption.

For teams managing large lists, real-time verification via the verification API or bulk checks through bulk verification can surface risky addresses before they cause delivery issues. A clean list means fewer errors, better sender reputation, and more consistent delivery—especially for time-sensitive campaigns.

How can you use TLS-RPT data to improve deliverability?

You can use TLS-RPT reports from Gmail, Microsoft, and other providers to detect and fix encryption issues in your outbound email flow. By analyzing daily reports, you can spot consistent TLS handshake failures across domains, uncover misconfigured mail servers—especially in legacy systems—and prioritize replacing outdated cipher suites or disabling TLS 1.0/1.1. Automated parsing helps you catch these issues early, before they impact inbox placement or trigger spam filtering.

Monitor for consistent TLS handshake failures

Review TLS-RPT reports daily to identify patterns of handshake failures across multiple recipient domains.
Look for repeated failures with specific domains or subnets—this often points to a misconfigured sender infrastructure.
Use tools like the MailTester inbox placement tester to simulate outbound delivery and validate whether fixes resolve the issue.

Identify and fix misconfigurations in outbound systems

Check your mail transfer agents (MTAs), especially legacy or third-party systems, for incorrect TLS certificates or expired keys.
Confirm that your outbound servers support modern TLS versions—TLS 1.2 or higher is required by most major providers.
Disable outdated protocols like TLS 1.0 and 1.1, which many providers now block entirely—see RFC 8996 for deprecation guidance.
Use a script to parse raw TLS-RPT data and generate alerts for any spike in failure rates over a rolling 24-hour period.

Let’s be clear: TLS-RPT reports are not just passive logs. They’re a diagnostic tool. When you get consistent failures from multiple domains, it isn’t about one recipient—it’s about your server’s ability to negotiate a secure connection. If your system can’t do that reliably, even well-formed messages may be delayed, rejected, or flagged as suspicious.

Automated analysis is essential. Manually reviewing daily reports is impractical and error-prone. You can write custom scripts using Python or shell tools, or use a service with parsing support. Integrating with tools like MailTester’s verification API helps validate sender infrastructure health across high-volume lists.

“TLS 1.0 and 1.1 are no longer acceptable for secure email delivery.” — IETF RFC 8996

Finally, keep your security stack audited. Misconfigured MTAs often go unnoticed until delivery metrics degrade. Use TLS-RPT not as a compliance checkbox, but as a proactive safeguard. Every successful handshake matters for reputation and inbox placement.

Why is MailTester not a TLS-RPT reporter?

You don’t send or receive email messages, so you can’t experience TLS handshakes—or report on them. MailTester only verifies email addresses for validity, deliverability risk, and inbox placement. It doesn’t run mail servers, authenticate outbound mail, or participate in transport-layer security events. That means no TLS-Reports are generated, and no reporting records can be published or received from providers like Gmail or Microsoft.

What TLS-RPT actually requires

TL;DR: TLS-RPT reporting happens only at scale, across active, configured mail servers. It’s not something a verification tool can do. The RFC 8460 specification defines TLS-RPT as a mechanism for domain operators—like large senders or email platforms—to receive reports when their outgoing TLS connections fail or are downgraded. These reports come from receivers (like Gmail’s mail servers) and require a published reporting record in DNS, which MailTester cannot host.

MailTester’s real role: pre-send validation

Let’s be clear: MailTester isn’t responsible for how your email gets delivered—only whether the address is actually live and likely to reach the inbox. It evaluates email structure, checks MX records, detects disposable domains, identifies catch-alls, and simulates inbox placement with tools like our inbox tester. But it doesn’t send mail. No sending means no TLS session. No TLS session means no report.

If you're using SendGrid, Mailchimp, or HubSpot, you’re already set up to generate TLS-RPT reports—because they operate mail servers. MailTester doesn’t. It’s a validator, not a sender. You can use it to clean your list before sending via those platforms, reducing bounces and protecting sender reputation.

For insight into how TLS security reporting works in practice, see the IETF’s TLS-RPT specification, which outlines how domains publish reporting URIs and receivers act on failed handshakes. MailTester follows this standard in its own way—by checking whether an email address exists at all, not whether it’s protected by TLS.

Put simply: you don’t report on traffic you don’t generate. That’s why we focus on accuracy (98.9%, no credit expiration), speed, and real-time risk detection—via our verification API and bulk verification tools—instead of reporting on transport-level events you’re not even responsible for.

What’s the difference between TLS-RPT and DMARC reports?

DMARC reports tell you whether emails claiming to come from your domain passed SPF or DKIM checks — they verify sender identity. TLS-RPT reports show whether the email connection used secure TLS encryption and completed the handshake successfully. One is about identity, the other about transport security. Both help you assess sender health, but they measure different layers of the email delivery chain.

DMARC: Identity and Authentication

DMARC reports focus on whether your emails were properly authenticated using SPF and DKIM. Each report includes data on messages that passed or failed these checks, helping you detect spoofing attempts and misconfigured senders. These reports are sent to the address specified in your DMARC record and show how many messages were rejected, quarantined, or delivered based on policy.

For example, if a message from your domain fails SPF but passes DKIM, DMARC will still flag it as a failure if policy requires both. You can use this data to tighten authentication requirements and block unauthorized sources. Tools like MailTester’s integrations help verify sender authentication health at scale.

TLS-RPT: Transport Security and Encryption

TLS-RPT reports track the success of TLS encryption during email transmission. They let you know whether the connection between your server and the recipient’s was encrypted and completed the handshake without error. A failed handshake might mean a man-in-the-middle risk or a misconfigured server.

Unlike DMARC, which cares about the sender’s identity, TLS-RPT focuses on whether the communication channel was secure. You receive these reports only if your domain includes a TLS-RPT policy and the receiving server supports it. The report format is standardized in RFC 8460, the official specification.

While DMARC tells you if your identity was validated, TLS-RPT tells you if the email was delivered securely. Both are useful, but they reflect different parts of your sender infrastructure.

Use cases overlap: an organization with strict compliance needs (like finance or healthcare) may monitor both. A high rate of TLS handshake failures could indicate a problem with your outbound SMTP setup, even if authentication checks pass. MailTester’s inbox placement tests can help you see how real-world providers handle your messages.

In short: DMARC = identity check. TLS-RPT = encryption check. One confirms who sent it. The other confirms it was sent securely.

Can you verify an email address using TLS-RPT signals?

No — TLS-RPT reports don’t tell you whether an email address is valid. They only track TLS handshake failures between sending and receiving mail servers. A failed handshake might mean poor encryption setup, but it doesn’t confirm if the mailbox exists or is deliverable. You can have a valid address with a failing TLS connection due to a misconfigured downstream server. Conversely, a successful handshake doesn’t guarantee the address is real. TLS-RPT is about transport security, not inbox validity.

What TLS-RPT actually measures

TLS-RPT (TLS Reputation Report) is a standard defined in RFC 8460. It’s sent by receiving servers to report on TLS negotiation failures — not whether a user exists or if an email was delivered. The data shows transport-level security issues, like expired certificates or unsupported cipher suites. It’s not tied to the mailbox itself, so it can't confirm if an address is active, disposable, or even syntactically correct.

For example, a server might reject a connection because it doesn’t trust a certificate, even if the user’s email is perfectly valid. This means a “TLS failure” reported via TLS-RPT might falsely suggest an invalid email, when in reality, it’s the sender’s server that’s misconfigured. That’s why relying on TLS-RPT for validation would lead to false negatives.

How MailTester actually checks email validity

MailTester doesn't use TLS-RPT signals. Instead, we perform real-time SMTP checks — we connect to the receiving server and simulate the email delivery process. This reveals whether the domain exists, if it accepts mail, and whether the specific address is recognized.

We also cross-check DNS records (MX, SPF, TXT), analyze syntax and common patterns (like typos, disposable formats), and leverage a large database of known invalid addresses. This combination gives us 98.9% accuracy, validated through real-world testing and continuous update cycles. Unlike TLS-RPT, our approach directly answers "Is this email address deliverable?" — not "Was encryption negotiated?"

For real-time validation, use our Verification API. If you're cleaning a large list, our bulk verification tool handles thousands of addresses fast. To test inbox placement ahead of campaigns, try our inbox tester. All tools use the same core logic — not transport logs, but direct server communication.

How does list hygiene relate to TLS-RPT data?

Good list hygiene reduces the number of domains your emails connect to, which lowers the risk of TLS handshake failures. Invalid or outdated addresses often belong to domains with weak infrastructure, making them more likely to fail TLS connections. When you clean your list regularly using tools like MailTester, you’re not only reducing bounces but also improving your sender reputation, which indirectly supports stronger TLS performance—especially when TLS-RPT reports show repeated connection issues with certain domains.

Connections to poorly configured domains hurt deliverability

You send to more domains than you think, and not all of them have properly configured TLS. If your list includes outdated or invalid addresses, you might be connecting to domains with expired certificates, misconfigured servers, or outdated protocols. These connections often fail during the TLS handshake, and those failures are logged in TLS-RPT reports. The more such domains you attempt to reach, the higher the chance you’ll appear as unreliable in email provider dashboards.

Let’s say you send to 10,000 addresses, but 30% point to domains with broken TLS. That’s 3,000 unnecessary failed attempts. Over time, email providers like Gmail or Microsoft may treat your sending behavior as risky—even if your own infrastructure is solid. This is why sender reputation depends not just on content or spam score, but on the quality of the mailboxes you’re trying to reach.

Verification tools help break the cycle

Tools like MailTester identify invalid, role-based, or disposable addresses before they cause problems. When you remove these from your list, you reduce the number of connections to domains with poor email infrastructure. This directly lowers the frequency of TLS handshake failures, reducing negative signals in TLS-RPT data.

For example, you might see TLS-RPT reports showing multiple failures to domains like example.com—only to later discover those were old, abandoned domains in your list. Removing them early stops the pattern. MailTester’s bulk verification (available at https://mailtester.com/email-list-verify) checks against real-time DNS, MX, and SMTP rules—including TLS readiness—to flag risky domains before you send.

And while you can’t fix a recipient’s configuration, you can avoid sending to them. That’s where list hygiene becomes a form of defensive deliverability. The fewer failed TLS connections, the more consistently your emails reach inboxes.

For real-time enforcement, integrate MailTester’s verification API (https://mailtester.com/api-email-checker) into your onboarding or campaign workflows. If you're testing inbox placement, include TLS-RPT patterns as part of your analysis (https://mailtester.com/inbox-tester). You’ll catch issues even before they show up in reports.

Ultimately, TLS-RPT isn't just about encryption—it’s a signal of sender discipline. Clean lists mean fewer failures, better reputation, and more predictable inbox placement. It’s not a direct fix, but it’s an essential layer in the process.

TL;DR: Who sends TLS-RPT reports and how to use them

Gmail, Microsoft, Yahoo, Apple, and AWS SES send TLS-RPT reports to domains that publish a TLS-Reporting TXT record. These reports contain granular data about TLS handshake outcomes for outgoing mail.

What TLS-RPT reports tell you

They show whether TLS was successfully negotiated during delivery — not whether an email address is valid.
Failure rates highlight misconfigurations in your outbound mail server setup, such as expired certificates or unsupported cipher suites.
They do not validate addresses or diagnose inbox placement issues.

How to use TLS-RPT data

Use the reports to audit your mail server's encryption compliance, not to check if an email exists.

Monitor report frequency and patterns over time. A high failure rate indicates immediate configuration fixes needed.

Correlate TLS-RPT findings with your existing list hygiene and sender reputation checks. No single signal guarantees deliverability — combine them.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
Gmail requires bulk senders to keep user-reported spam rates below 0.3%, warning that rates above 0.1% already hurt inbox delivery — just 3 complaints per 1,000 emails crosses the line. — Google Email Sender Guidelines FAQ (2024)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does Gmail send TLS-RPT reports?

Yes. Gmail sends TLS-RPT reports for outbound mail from domains it authenticates, as long as those domains publish a TLS-Reporting TXT record.

Can I access TLS-RPT reports for my domain?

Yes — if you publish a TLS-Reporting TXT record in your DNS. Reports will be sent daily to the email address listed in the record.

What does a failed TLS handshake in a report mean?

It means the recipient server did not support or properly complete the TLS connection. This may indicate outdated software, misconfiguration, or lack of valid certificates.

Is TLS-RPT the same as DMARC reporting?

No. DMARC reports track SPF/DKIM authentication results and delivery failures. TLS-RPT tracks the success of encrypted connections at the transport layer.

Do all email providers send TLS-RPT reports?

No. Only providers that support the TLS Reporting standard will generate reports. Smaller or legacy services may not.

Can MailTester help me interpret TLS-RPT data?

No — MailTester does not send or receive TLS-RPT reports. It verifies email addresses before sending to reduce bounce and deliverability risks.

How do I set up TLS-RPT for my email domain?

Publish a DNS TXT record with the name _tlsrpt.yourdomain.com, pointing to a valid email address. The receiving domain must be ready to process JSON-formatted daily reports.

Why should I care about TLS-RPT if I’m not a mail server admin?

Because poor TLS performance can hurt your sender reputation. Even if you send via a third-party service, misconfigured infrastructure on your end may result in failed handshakes.

Can TLS-RPT reports cause spam traps?

No — TLS-RPT reports are sent to a designated email, not to an inbox for end-users. They do not impact spam filtering or user engagement.

What happens if I don’t monitor TLS-RPT reports?

You might miss signs of TLS misconfiguration, which could lead to reduced delivery rates or throttling by recipient providers over time.