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.

Several protocols help encrypt SMTP message channels to prevent cyberattackers 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.

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 a 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.

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.

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. .With MTA-STS enabled, attackers are rendered unsuccessful in delivering messages in plain text when a connection fails.

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.

Why Do You Need SMTP TLS Reporting?

Domain owners need to stay informed about email d

elivery 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. TLS-RPT

To receive feedback reports that highlights your policy type and
To identify the reason for TLS encryption failures
To gain visibility on email channels
To fix delivery 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: Select a TLS-RPT Record Generator Tool

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 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 “maito:” 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.

TLS Reporting Format

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

}

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 Encryption Failure Reasons and Types

Certificate Issues

Failure Types	Reasons	Possible Troubleshooting Suggestions
certificate_expired	The certificate presented by the remote server has passed its expiry date. This makes it untrustworthy for encryption.	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.	Contact your certificate provider.
certificate_revoked	The certificate presented by the remote server has been revoked by the certificate authority due to security concerns.	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.	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.	Contact your certificate provider.

Hostname and Identity Mismatch

Failure Type	Reason	Possible Troubleshooting Suggestions
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.	Check the MX records in your MTA-STS policy file to make sure they match the MX record for the domain.

Handshake and Protocol Issues

Failure Types	Reasons	Possible Troubleshooting Suggestions
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.

MTA-STS Policy Issues

Failure Types	Reasons	Possible Troubleshooting Suggestions
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. 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. Learn more about the policy modes here.
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.	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.	Check your certificate validity, 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.	Check the MX records in your MTA-STS policy file to make sure they match the MX record for the domain.

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

1. What does TLS stand for?

TLS stands for Transport Layer Security.

2. 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.

3. 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.

4. 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?