TLS Reporting is a reverse feedback mechanism that helps domain owners find email delivery issues with pinpoint accuracy. It works in conjunction with the MTA-STS protocol and provides tracking data on bounced emails that failed to be delivered due to an unsuccessful TLS handshake.

What does TLS Reporting Mean?

TLS Reporting (TLS-RPT) is a standard for reporting email delivery issues that occur when an email isn’t encrypted with TLS. It supports the MTA-STS protocol which is used to guarantee that any email sent to your domain gets TLS encrypted.

TLS encryption ensures that every email sent to you gets delivered securely. However, an attacker might attempt an SMTP downgrade, a type of attack where the email gets sent to you without being encrypted, allowing them to read or tamper with the contents. MTA-STS combats this by making it necessary for all emails to be encrypted before being sent to you. If an attacker tries to perform an SMTP downgrade, the email will not be sent at all.
TLS-RPT makes it possible for you, the domain owner, to receive reports on every email that doesn’t get encrypted and fails to be sent to you. You can then identify the source of the problem and fix your delivery issues.

How Does TLS Reporting Work?

TLS reporting (TLS-RPT) is used to support the MTA-STS protocol, which ensures emails are encrypted before being delivered. Normally, 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 to the receiving MTA.

An attacker might attempt an SMTP downgrade attack at this point, which involves blocking the negotiation between the sending and receiving MTAs. The sending server thinks the receiver doesn’t support the STARTTLS command and sends the email without TLS encryption, allowing the attacker to view or tamper with the email’s contents.

When you implement MTA-STS in your domain, it makes it mandatory for your sending server to encrypt messages before sending them. If an attacker attempts an SMTP downgrade attack, the email will simply not be sent. This ensures TLS encryption on all your emails without fail.

TLS reporting (TLS-RPT) is a protocol that will notify you, the domain owner when emails sent through your domain face issues with delivery. If an email fails to be sent due to an SMTP downgrade or some other issue, you will receive a report in a JSON file format containing the details of the email that failed. This report does not contain the contents of the email.

Why Do You Need SMTP TLS Reporting?

It is essential for domain owners 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.

To Receive feedback reports

If a message fails to be sent, TLS reporting helps you get notified about it

To Gain Total visibility of Email Channels

Gain granular insights on your email flow through TLS reporting

To Eliminate Delivery Issues

TLS reporting helps you Identify the source of the problem and fix it with zero delay

Steps for Activating TLS Reporting

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

TLS-RPT record example

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

Let’s break down the 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 TLS-RPT protocol.

rua=mailto:[email protected]:

This tag indicates the reporting URI for the aggregated reports (RUAs). It specifies where the recipient’s mail server should send aggregated reports about TLS failures. rua stands for “Reporting URI for Aggregated Reports.”

The value “mailto:[email protected]” is a URI that specifies an email address ([email protected]) to which the aggregated reports should be sent via email.

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

The significance of each component:

v=TLSRPTv1:

This indicates the version of the TLS-RPT protocol being used. It helps ensure compatibility between the sender and receiver of the reports.

rua=mailto:[email protected]:

This specifies the destination of aggregated reports for TLS delivery issues. By providing a reporting email address, domain owners can receive information about failed or problematic TLS connections. The reports are valuable for diagnosing potential security or configuration issues related to email communication.

TLS Reporting Format and Report Example

A JSON TLS report follows a specific format that is defined by the TLS-RPT (Transport Layer Security Reporting Policy) specification. This format is used to convey information about email delivery issues related to TLS encryption. Below is an example of what a JSON TLS report might look like:

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

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 (e.g., “policy” for a TLS policy).

policy_string: Specifies the policy string associated with the policy (e.g., “reject” for a strict TLS policy).

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:

certificate_expired: The certificate presented by the remote server has passed its expiration date, making it untrustworthy for encryption.
certificate_not_valid_yet: The certificate presented by the remote server is not yet valid, possibly due to incorrect server time or premature certificate usage.
certificate_revoked: The certificate presented by the remote server has been revoked by the certificate authority due to security concerns.
untrusted_certificate: The certificate chain presented by the remote server is not trusted by the sender’s mail server or client, indicating a potential security risk.
no_valid_signature: The certificate presented by the remote server is not properly signed by a trusted certificate authority, raising concerns about its authenticity.
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.

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, indicating a possible man-in-the-middle attack or configuration issue.

Cipher Suite and Encryption Configuration

insecure_cipher_suite: The cipher suite negotiated between the sender’s and recipient’s mail servers is considered weak or insecure, potentially compromising the confidentiality and integrity of the communication.
protocol_version_mismatch: There is a mismatch in the supported TLS protocol versions between the sender’s and recipient’s mail servers, preventing them from establishing a compatible encrypted connection.
no_shared_cipher_suite: There is no common cipher suite available for both the sender’s and recipient’s mail servers to use for encryption, resulting in a failed connection.

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.
unexpected_message: The sender’s mail server received an unexpected or unsupported message during the TLS handshake process, indicating a potential protocol or implementation mismatch.

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.
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.
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.
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.
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.
mta_sts_policy_upgrade: This failure occurs when the sender’s mail server attempts to upgrade the connection to a secure one using MTA-STS, but the recipient’s server doesn’t support the upgrade.

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

Complex JSON reports for TLS reporting are converted to simplified information you can skim through in seconds or read in detail

Auto-detect issues

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

About
Latest Posts

Ahona Rudra

Digital Marketing & Content Writer Manager at PowerDMARC

Ahona works as a Digital Marketing and Content Writer Manager at PowerDMARC. She is a passionate writer, blogger, and marketing specialist in cybersecurity and information technology.

What is SMTP TLS Reporting?