What is TLS-RPT (Transport Layer Security Reporting)?

What is TLS-RPT, and why does it matter?

Simple Mail Transfer Protocol (SMTP) Transport Layer Security Reporting (TLS-RPT) is a standard that allows domain owners to receive feedback about failures during the TLS encryption process. It provides visibility into TLS misconfigurations and email delivery issues.

TLS is the protocol that encrypts email in transit, ensuring that data remains private as it moves between email servers. If TLS isn’t properly enforced, messages can be sent in plain text, exposing them to cybercriminals and other malicious actors.

Why is the protocol important?

  • Visibility: Provides insight into how often encrypted email delivery fails and the causes of those failures
  • Security: Helps detect misconfigurations that weaken email encryption and security
  • Compliance: Supports regulatory and data protection compliance by showing a commitment to securing communications
  • Proactive response: Enables timely detection and solving of encryption issues before they affect operations or compromise data

How does TLS-RPT work?

The protocol enables email servers to send daily reports when issues happen during encrypted email delivery using TLS. These reports help domain owners monitor and improve the security of their email infrastructure.

When a receiving email server faces problems, such as certificate validation errors or delivery failures, it generates a report to send to the location specified in the recipient domain’s DNS record to allow domain owners to address the issue.

The workflow:

  1. If the receiving server faces an issue with TLS, it checks for a report record in the recipient’s DNS
  2. If found, it sends a detailed report (typically in JSON format) to the assigned email address
  3. The report includes:
    • The type of TLS failure
    • IP addresses involved
    • Time of the failure
    • Policy mode (testing or enforce)

This feedback provides domain owners with visibility into encryption-related issues and helps them proactively secure their email environments.

Want to see how the protocol works in action? Book a demo with one of our experts to find out how we monitor and solve email encryption issues.

Benefits of TLS-RPT for email security

  • Enhanced visibility: Monitor TLS-related delivery issues, including misconfigurations and cyberattack attempts
  • Simplified troubleshooting: Identify and solve encryption problems that affect email deliverability and security
  • Downgrade attack detection: Detect attempts to avoid encryption by forcing email transmission over unencrypted channels
  • Improved compliance: Maintain documentation of encryption failures and show a proactive approach to data protection
  • Optimized deliverability: Improve the success of secure email delivery and reduce the risk of message interception

Limitations of TLS-RPT

  • Reporting only: The protocol provides reporting on encryption issues, but doesn’t enforce encryption; this is handled by Mail Transfer Agent Strict Transport Security (MTA-STS) or DNS-based Authentication of Named Entities (DANE)
  • Aggregate reports: Reports are typically generated and sent daily, so they don’t offer real-time alerts
  • Adoption required: Only email servers that support the protocol will send reports, so visibility depends on third-party adoption

TLS-RPT record example

To enable the protocol, publish a DNS TXT record at the subdomain _smtp._tls.yourdomain.com.

Here’s a typical DNS record format:
Host Type Value
_smtp._tls.yourdomain.com TXT v=TLSRPTv1; rua=mailto:[email protected]
  • v: Version indicator (always TLSRPTv1).
  • RUA: The email address where reports are sent. Your organization can include multiple addresses separated by commas, for example:
Host Type Value
_smtp._tls.yourdomain.com TXT v=TLSRPTv1; rua=mailto:[email protected],rua=mailto:[email protected]

How to create a TLS-RPT record (step-by-step)

Step 1: Choose the reporting email address

Decide where reports should be sent – either to a monitored email address or a dedicated reporting platform.

Tip: Use a management platform that provides data consolidation and enrichment.

Step 2: Publish the DNS TXT record

Add a TXT record to the DNS:

HostTypeValue
_smtp._tls.yourdomain.comTXTv=TLSRPTv1; rua=mailto:[email protected]

This can include multiple endpoints:

HostTypeValue
_smtp._tls.yourdomain.comTXTv=TLSRPTv1; rua=mailto:[email protected],rua=mailto:[email protected]

Step 3: Validate and monitor reports

Use tools like Sendmarc’s TLS-RPT lookup to confirm that the DNS record is correctly published. Regularly review the reports to identify encryption failures, misconfigurations, and attempted downgrade attacks.

Reviewing reports

Once reports begin arriving, it’s essential to have a plan for understanding and acting on the data. These reports typically arrive in JSON format.

Below, we’ve explained how to make the most of this data:

  • Trend analysis: Look for patterns over time, such as continuous failures from specific addresses
  • Misconfiguration identification: Use failure codes to spot improper configuration within your business’s email infrastructure
  • Internal communication: Send insights to the appropriate teams – whether it be IT operations or cybersecurity – for correction

If manually handling reports isn’t practical, consider integrating them into a management platform or using a specialized email security monitoring solution. At Sendmarc, we simplify cybersecurity management.

TLS-RPT, MTA-STS, & DANE: How they work together

These three protocols each play a role in securing email in transit. While TLS-RPT provides visibility, MTA-STS and DANE enforce encryption and certificate validation.
Protocol Purpose Enforces encryption? Provides reporting?
TLS-RPT Reports on TLS failures and issues No Yes
MTA-STS Enforces TLS for SMTP connections Yes No
DANE Authenticates certificates via Domain Name System Security Extensions (DNSSEC) Yes No
  • TLS-RPT offers feedback and visibility into TLS-related delivery problems
  • MTA-STS and DANE ensure email is delivered securely by enforcing encryption and validating certificates
Implementing all three creates a strong framework for secure, reliable, and monitored email delivery.

TLS-RPT in a layered email security strategy

While the protocol is a valuable reporting mechanism, it’s most effective as part of a layered email security strategy. In combination with other technologies like Domain-based Message Authentication, Reporting, and Conformance (DMARC), Sender Policy Framework (SPF), and DomainKeys Identified Mail (DKIM), the protocol strengthens visibility and overall security.

Each protocol addresses a different aspect of email risk:

  • TLS-RPT helps detect and diagnose failures in encrypted transmission
  • DMARC protects against spoofing and domain impersonation
  • SPF verifies that sending servers are authorized to send on behalf of your company’s domain
  • DKIM ensures email integrity by validating messages with digital signatures

Together, these security measures create a multi-layered defense that safeguards both outbound and inbound email. For domain owners, implementing the protocol supports the goal of full domain security.

TLS-RPT: FAQs

What is a TLS-RPT record?
A TLS-RPT record is a DNS TXT record that tells receiving email servers where to send reports about TLS encryption issues seen when receiving emails from your organization’s domain.
Transport Layer Security (TLS) is a cryptographic protocol that encrypts data during transmission, protecting email content from tampering or interception in transit.
TLS-RPT improves email security by providing visibility into encryption failures, allowing domain owners to detect, investigate, and fix issues that might compromise secure email delivery.

Yes. TLS-RPT is still necessary even if your business uses MTA-STS or DANE, because while those protocols enforce encryption, TLS-RPT provides the reporting required to monitor and troubleshoot encryption issues.

No. Your company shouldn’t publish multiple TLS-RPT records for a domain. Keep in mind, your organization can include multiple reporting addresses or endpoints within a single record by separating them with commas.

A TLS-RPT failure report means a sending server had a problem creating a secure TLS connection to your business’s domain, which might result from misconfigurations or expired certificates.

Your company can check its TLS-RPT record setup by using tools like Sendmarc’s TLS-RPT lookup. Once published, monitor the specified inbox or endpoint to confirm that reports are being received. 

Ready to secure your organization’s email?

Get started by exploring our DMARC management platform with one of our cybersecurity experts and gain full visibility into your business’s email.