Ultimate Guide To TLS-RPT And SMTP TLS Reporting

As organizations increasingly rely on email as a primary means of communication, the importance of fortifying these channels against potential threats cannot be overstated. Transport Layer Security (TLS) ensures the confidentiality and integrity of data transmitted across networks.

SMTP TLS Reporting (TLS-RPT) is a critical protocol that works alongside MTA-STS to ensure your emails are delivered securely. By providing detailed feedback on email delivery issues, TLS-RPT helps domain owners maintain the integrity and confidentiality of their communications. In this comprehensive guide, we’ll explore what SMTP TLS Reporting is, how it works, and why it’s essential for your email security strategy.”

Several protocols help encrypt SMTP message channels to prevent cyber attackers from intercepting email communications. This includes STARTTLS, DANE, and MTA-STS. However, when encryption attempts fail while using these protocols, your email may fail to get delivered. TLS-RPT (as described under RFC 8460) provides a feedback mechanism to report on these deliverability failures.

We highly recommend using TLS-RPT in conjunction with the MTA-STS protocol. Let’s understand how these protocols work together to bolster email security.

Key Takeaways

Email security can be significantly enhanced by implementing protocols like TLS-RPT and MTA-STS.
TLS-RPT provides essential feedback on email delivery issues related to TLS encryption, helping domain owners monitor their email channels effectively.
STARTTLS, DANE, and MTA-STS protocols work together to ensure secure email communication, reducing the risk of cyberattacks.
Setting up a TLS-RPT record involves publishing a TXT record in your DNS settings at a specific subdomain.
Recognizing and addressing TLS encryption failures is critical for maintaining email deliverability and security.

What is TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) is a standard for reporting email delivery issues when an email isn’t encrypted with TLS. Its importance in email authentication goes hand in hand with the reason for enabling TLS encryption for emails.

TLS encryption ensures that every email sent to you gets delivered securely. In case the connection is not secure, many times emails may fail to get delivered. TLS-RPT makes it possible for domain owners to monitor email delivery and connection failures. The reports may contain information on:

MTA-STS policy handling issues
Delivery failure reason and type
IP address of email sending and receiving mail transfer agents
Total count of successful and unsuccessful TLS connection sessions

This provides visibility on your email channels, and the ability to counter deliverability challenges faster.

Simplify SMTP TLS Reporting with PowerDMARC!

Start 15-day trial Book a demo

How Does TLS Reporting Work?

In SMTP email communication, TLS encryption is “opportunistic”. This means that if an encrypted channel cannot be negotiated the email is still sent in an unencrypted (plain text) format. In fact, almost 4 decades ago, ‌SMTP email protocols did not support TLS encryption. It had to be retrofitted later in the form of the STARTTLS command.

The STARTTLS command is only issued in SMTP communications if both sides support TLS encryption. Else, the email will still be sent in plain text.

To get rid of opportunistic encryption in SMTP, MTA-STS was introduced (RFC 8461). The MTA-STS protocol ensures emails are encrypted before being delivered. Your email server or Mail Transfer Agent (MTA) negotiates with the receiving server to see if it supports the STARTTLS command. If it does, the email gets encrypted with TLS and gets delivered. Else, delivery fails.

Step-by-Step Explanation of How TLS-RPT Works

1. Understanding the TLS Handshake Process

Transport Layer Security handshake (TLS handshake) is the process of establishing a secure connection between two communicating Mail Transfer Agents (MTAs). This process involves the following steps:

The email-sending MTA sends a “Client Hello” message to the receiving MTA. This message contains useful parameters such as TLS versions and cipher suites.
The email-receiving MTA receives this message and responds with a “Server Hello” message. This contains the selected TLS version and cipher suite.
After initiation of the TLS handshake, the receiving MTA sends its SSL/TLS certificate which is issued by a trusted CA (Certificate Authority). This certificate contains the public key.
Both communicating MTAs securely exchange their cryptographic keys and establish a TLS-encrypted connection. This ensures a secure email communication between both parties.

2. Failed TLS Handshake Scenarios

TLS Handshakes may fail due to a variety of reasons:

Certification Errors: Expired certificates or certificates issued by untrusted Certificate Authorities can lead to TLS handshake failures.
Version Mismatches: If there is a mismatch between the TLS versions supported by the sending and receiving MTAs, it can lead to handshake failure.
STARTTLS Failures: If the STARTTLS command is not correctly implemented it can again lead to TLS encryption failure.
MTA-STS Enforcement: In case the email receiver has set his MTA-STS policy mode to “enforce”, a failed TLS handshake can lead to message rejection.

3. Report Generation and Delivery

Whenever TLS encryption failures occur, the sending server generates a TLS-RPT report and sends it to the domain owner for further evaluation and troubleshooting.

Report Contents

Sending Server Details: IP address and domain name of the sender.

Receiving Server Details: The recipient domain and email server information.

Error Description: Type and details of the failure (e.g., certificate error, protocol mismatch).

Time of Failure: Timestamp when the issue occurred.

Policy Mode: Whether the domain is in “testing” or “enforce” mode.

Report Delivery

These TLS reports are sent in JSON format to the email address specified in the domain owner’s TLS-RPT DNS TXT record.

Role of Opportunistic Encryption in SMTP

SMTP traditionally uses opportunistic encryption. This means it attempts to use TLS but falls back to unencrypted delivery if the receiving MTA does not support TLS.

However, opportunistic encryption comes with one major limitation. In this type of encryption that sets no mandate, emails can be sent in plaintext or cleartext (in an unencrypted format) if TLS encryption fails. Such unencrypted messages are vulnerable to interception.

How MTA-STS and TLS-RPT Work Together

Mail Transfer Agent Strict Transport Security (MTA-STS) and TLS-RPT are complementary protocols in the email authentication ecosystem. While MTA-STS ensures that sending MTA must use TLS for delivery and reject emails if encryption fails,

TLS-RPT enables domain owners to monitor failed TLS handshakes and troubleshoot issues. When implemented together, they can prevent message interceptions in transit and minimize email deliverability issues.

Relationship between DANE and TLS-RPT

DNS-based Authentication of Named Entities (DANE) is a protocol that allows domain owners to specify TLS certificates verified via DNSSEC to prevent man-in-the-middle attacks. While TLS-RPT monitors TLS failures, DANE ensures that only trusted certificates are used. By doing so, DANE actively prevents attackers from performing TLS downgrade and certificate spoofing attacks, thereby maintaining the integrity of email communications.

Why Do You Need SMTP TLS Reporting?

Domain owners need to stay informed about email delivery issues due to failures in TLS encryption for emails sent from an MTA-STS-enabled domain. TLS reporting makes it possible by providing this information.

Email Security: Highlight the risks of unencrypted email communication (e.g., interception, man-in-the-middle attacks).
Compliance: Mention how TLS-RPT helps organizations meet regulatory requirements for data protection.
Deliverability: Explain how TLS-RPT improves email deliverability by identifying and resolving encryption issues.

Steps to Set Up TLS-RPT

You can enable TLS reporting for your domain by creating a TXT record for TLS-RPT and publishing it on your DNS. This record must be published at the subdomain smtp.tls.yourdomain.com

Step 1: Generate a TLS-RPT Record (Using a TLS-RPT record generator)

You can sign up on PowerDMARC for free and use our TLS-RPT record generator to create your record.

Step 2: Enter Your Reporting Email Address

Enter an email address on which you wish to receive your SMTP TLS Reports.

Step 3: Publish the TLS Record on Your DNS

You can contact your domain registrar to create a new TXT record for TLS-RPT. If you manage your own DNS, edit your DNS settings to include the record.

TLS-RPT Record Syntax and Example

Syntax: v=TLSRPTv1; rua=mailto:[email protected];

Let’s break down the 2 components of the provided TLS reporting record:

v=TLSRPTv1: This tag specifies the version of the TLS-RPT protocol being used. In this case, “TLSRPTv1” indicates the first version of the protocol.
rua=mailto:[email protected]: rua stands for “Reporting URI(s) for Aggregate Data. This tag specifies where the recipient’s mail server should send the aggregated TLS reports.

You can configure more than one destination for receiving your reports. For multiple destinations, separate each entry with a comma (,). You can either use “mailto:” to specify an email address for this step, or instruct the MTA to submit reports via POST to endpoint URLs by using “https:” in the rua= field. If you are using “https:” , make sure the field defines the URL to an HTTPS enabled web server with a valid certificate. Both “mailto:” and “https:” can also be used in a single record, separated by a comma.

Example: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Note: In practice, you would replace “yourdomain.com” with the actual domain name where you want to receive these reports.

Understanding TLS-RPT JSON Reports

Structure of a TLS-RPT JSON Report

TLS reports are sent in JSON format. Below is an example of what a JSON TLS report might look like:

{

“organization-name”: “Organization Inc.”,

“date-range”: {

“start-datetime”: “2020-10-22T00:00:00Z”,

“end-datetime”: “2020-10-22T23:59:59Z”

“contact-info”: “[email protected]”,

“report-id”: “2020-10-22T00:00:00Z_domain.com”,

“policies”: [

{

“policy”: {

“policy-type”: “sts”,

“policy-string”: [

“version: STSv1”,

“mode: testing”,

“mx: mx.domain.com”,

“mx: mx2.domain.com”,

“mx: mx3.domain.com”,

“max_age: 604800”

“policy-domain”: “domain.com”

“summary”: {

“total-successful-session-count”: 15,

“total-failure-session-count”: 0

}

Key Fields and Their Meaning

Here’s the breakdown of the main fields within this JSON TLS report:

Fields	Description
organization	The domain organization that owns the TLS-RPT record.
email	The email address where aggregated reports are sent.
begin_date	The start date of the reporting period.
end_date	The end date of the reporting period.
policies	An array of policy objects that describe the policies applied during the reporting period.
policy	Contains information about the applied policy.
policy_type	Specifies the type of policy
policy_string	Specifies the policy string associated with the policy
mode	Specifies the MTA-STS policy mode (Enforce/Testing)
summary	Contains summary information about the sessions that were attempted.
total_successful_session_count	The total count of successfully established TLS sessions.
total_failure_session_count	The total count of TLS session failures.
failure_details	An array of objects that provide details about specific failures.
reason	A string indicating the reason for the failure (e.g., “certificate_expired”).
count	The count of sessions that failed for a specific reason.

TLS-RPT JSON Report Format and Data Interpretation

Report Metadata

{

“organization-name”: “Sending MTA Organization”,

“date-range”: {

“start-datetime”: “2025-02-25T00:00:00Z”,

“end-datetime”: “2025-02-25T23:59:59Z”

“report-id”: “unique-report-id-12345”

}

This section of your JSON report outlines basic information such as the email sender’s organization name, start date and time, end date and time, and the unique ID for the generated TLS report.

Policy Details

“policy”: {

“policy-type”: “sts”,

“policy-string”: “mode: enforce; mx: mail.example.com; max_age: 604800;”

}

This section outlines the MTA-STS policy mode implemented, which in this case is the Enforce mode, but it can also to set to Testing mode.

Failure Details

“failure-details”: [

{

“result-type”: “certificate-expired”,

“sending-mta”: “smtp.example.org”,

“receiving-mta”: “mail.example.com”,

“failure-reason”: “TLS handshake failed due to expired certificate”

}

]

This section is the most crucial part of your TLS report, detailing the rationale for encryption and potential delivery failures. In this case, the example indicates that an expired certificate is the cause of the TLS handshake failure. This plays a significant role in error detection during failed TLS handshakes and promotes quick troubleshooting for secure TLS communications.

TLS Encryption Failure Reasons and Troubleshooting

There can be several reasons for TLS encryption failures. Other than a lack of support for encryption on either side, more sinister reasons like an SMTP downgrade attack may lead to TLS connection failure. But domain owners would want to know about the failed delivery. TLS reporting (TLS-RPT) is a protocol that will notify you. On delivery failures, you will receive your TLS report in a JSON file format to the email address defined in your TLS-RPT record. Given below are a few common reasons for encryption failures and troubleshooting tips:

1. Certificate Issues

certificate_expired

The certificate presented by the remote server has passed its expiry date. This makes it untrustworthy for encryption. In this case, you need to renew your certificate.

certificate_not_valid_yet

The certificate presented by the remote server is not yet valid. This may be due to incorrect server time or premature certificate usage. In this case, it’s best to contact your certificate provider.

certificate_revoked

The certificate presented by the remote server has been revoked by the certificate authority due to security concerns. In this case, it’s best to contact your certificate provider.

no_valid_signature

The certificate chain presented by the remote server is not trusted by the sender’s mail server or client, indicating a potential security risk. In this case, it’s best to contact your certificate provider.

unsupported_certificate

The certificate presented by the remote server uses encryption algorithms or key lengths that are not supported by the sender’s mail server, preventing a secure connection. In this case, it’s best to contact your certificate provider.

2. Hostname and Identity Mismatch

hostname_mismatch

The hostname specified in the server’s certificate does not match the hostname of the server the sender’s mail server is trying to connect to. It indicates a possible man-in-the-middle attack or a configuration issue.

You can check the MX records in your MTA-STS policy file to make sure they match the MX record for the domain.

3. Handshake and Protocol Issues

handshake_failure

An issue occurred during the initial TLS handshake process between the sender’s mail server and the recipient’s mail server, preventing the secure channel from being established. Double-check if the SMTP STARTTLS connection has been established. There can be several reasons contributing to encryption failures like lack of support for STARTTLS, or a TLS downgrade attack.

4. MTA-STS Policy Issues

mta_sts_policy_not_found

This failure occurs when the sender’s mail server is unable to find an MTA-STS policy for the recipient’s domain. Review your MTA-STS policy file. You should check your MTA-STS record to make sure it was published correctly.

mta_sts_policy_invalid

This failure occurs when the MTA-STS policy found in DNS for the recipient’s domain is invalid, contains errors, or doesn’t adhere to the MTA-STS specification. Review your MTA-STS policy file. Specify an appropriate MTA-STS policy mode. It can be either None, Enforce, or Testing. This instructs sending servers on how to handle emails that undergo MTA-STS policy validation failures.

mta_sts_policy_fetch_error

This failure occurs when the sender’s mail server encounters an error while trying to retrieve the MTA-STS policy from the recipient’s domain’s DNS records. You should validate the MTA-STS records in your DNS to make sure the record syntax is correct.

mta_sts_connection_failure

This failure occurs when the sender’s mail server attempts to establish a secure connection using MTA-STS but fails due to reasons such as untrusted certificates, unsupported cipher suites, or other TLS issues. You should check your certificate validity, and ensure the certificate is up to date with the latest TLS standard.

mta_sts_invalid_hostname

This failure occurs when the hostname of the recipient’s mail server, as specified in the MTA-STS policy, does not match the actual hostname of the server. You should check the MX records in your MTA-STS policy file to make sure they match the MX record for the domain.

Best Practices for TLS-RPT Implementation

Regularly Monitor TLS Reports

TLS reports should be regularly monitored to make sure you don’t miss out on undelivered messages. You can do so by either manually monitoring your mailbox for the JSON reports or using a report analyzer tool like PowerTLS-RPT.

Ensure MTA-STS Policy is Properly Configured

To ensure proper TLS-RPT implementation, your MTA-STS policy should be configured properly, and without syntax errors. You can check your record using our MTA-STS checker for this step.

Address Encryption Failures Promptly

Once you detect encryption failures outlined in your TLS report, it’s important to take action quickly to prevent email deliverability issues in the future.

Use Secure TLS Protocol Versions

Using only the latest and supported TLS protocol versions is essential for avoiding unwanted encryption failures.

Simplified SMTP TLS Reporting with PowerDMARC

PowerDMARC’s SMTP TLS reporting experience is all about improving your security while making your life easier with a hosted service.

Translated TLS Reports

Your complex TLS-RPT JSON reports are converted to simplified information you can skim through in seconds or read in detail.

Auto-detect issues

The PowerDMARC platform pinpoints and highlights the issue you’re facing so you can resolve it without wasting time.

There’s not one thing I like about the PowerDMARC platform, they have an easy to use and understand layout with what I’d call full features allowing for hosted DMARC control, SPF flattening, being able to easily expand the SPF includes to inspect the specifics of the record and even full support for MTA-STS and TLS-RPT!

Dylan B (Business Owner)

Frequently Asked Questions on Transport Layer Security

What does TLS stand for?

TLS stands for Transport Layer Security.

Who issues TLS certificates?

Certificate Authorities (CAs) can issue TLS certificates. The process for issuing the certificate includes verification of the certificate holder’s identity. On successful identification, the certificate is issued.

Why do I need a TLS certificate?

TLS certificates play a pivotal role in securing communications over the internet. They help encrypt sensitive information exchanged between communicating web servers. Some of its most common usages include securing email communications, and HTTPS.

What is the current TLS standard?

TLS 1.3 is the latest version of Transport Layer Security. TLS-RPT can be implemented using any version of TLS. This can include older versions of the protocol or future versions. The version is usually determined by criteria like the capabilities of the communicating servers.

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

What is SMTP TLS Reporting (TLS-RPT)?