What is SMTP TLS Reporting?
Reading Time: 8 min
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.
Secure Your Email
Stop Email Spoofing and Improve Email Deliverability
15-day Free trial!
Latest Blogs
How to Add Your Logo to Gmail Emails: Gmail & Branded Emails
July 2, 2024 - 12:50 am
What Are the Cybersecurity Threats When Allowing Third-Party Cookies on Mac?
June 29, 2024 - 1:38 pm
DMARC: The Missing Link in Your MSP’s Defense Strategy
June 27, 2024 - 11:16 am
GoDaddy SPF, DKIM, and DMARC Record Configuration Guide: Step-By-Step
June 26, 2024 - 1:00 pm
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
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
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:tlsrpt@yourdomain.com;
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:tlsrpt@yourdomain.com: 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:tlsrpt@example.com,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”: “smtp-tls-reporting@organization.com”,
“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
}
| Fields | Description |
|---|---|
| organization | The domain organization that owns the TLS-RPT record. |
| 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 | Reason |
|---|---|---|
| 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. |
