Problem:
How do I setup TLS-RPT?
Solution:
In this knowledge article it is assumed you already have the following working:
- A email server solution
- Already receiving inbound emails for your domain/s.
- Enabled TLS/SSL for SMTP on the email server.
TLS-RPT is Transport Layer Security RePorTing, and is a protocol designed to improve the security of email communication by providing feedback to domain owners about issues encountered during the establishment of TLS-encrypted connections between email servers.
TLS-RPT in a few steps
Create a mailbox
In order to receive the TLS-RPT reports you will need a dedicated mailbox or access to a TLS-RPT analysing service.
If you choose to use a mailbox on your domain, then we suggested a dedicated mailbox as the email address needs to be published in the DNS TXT record.
Add a DNS TXT to your domain
You will need to create a DNS TXT record called _smtp._tls.mydomain.com.
Review TLS reports
Analyse and review the received TLS reports.
Setting up TLS-RPT
Let's look in more detail in the setting up of TLS-RPT
Step 1 - Create a mailbox
It is recommend you create a dedicated mailbox to receive the reports as this is a published email address in DNS.
Create a mailbox with the email address tls-rpt@example.com
Ensure that mailbox can receive emails from other Internet domains.
Step 2 - Adding a TXT DNS record
You will need access to your DNS zone records in order to create a new TXT record called _smtp_tls.example.com an example of the record is below.
_smtp._tls TXT "v=TLSRPTv1;rua=mailto:tls-rpt@example.com"
The record is a TXT DNS record and the breakdown is as follows:
| Field & Value | Description |
|---|---|
| v=TLSRPTv1 | TLSRPT version 1 |
| rua=mailto:tls-rpt@example.com |
Aggregate Report URI (rua), A comma-separated list of locations where the report is to be submitted. TLSRPT supports reports to go via email (mailto:) or https submission |
What would trigger a TLSRPT report?
To establish a secure SMTP connection there are several protocols that can be used. For example, DANE TLSA, STARTTLS, and MTA-STS. Any one of these protocols could cause a message to be undelivered or the message to be delivered by an unsecured method. When this happens the sending server will generate a TLS report and submit it to the published "rua" value in the DNS TXT record.
Below is a list of possible failures that could cause a TLE report to be generated.
TLS negotiation failures
| starttls-not-supported | The receiving MTA does not support the STARTTLS command. Check your receiving server has a valid certificate installed and the Mail Transport Agent (MTA) is configured for TLS / SSL. |
| certificate-host-mismatch | The receiving MTA’s certificate does not match the hostname. Check your receiving server has a valid certificate that includes the mail server hostname. Wildcard SSL certificates are also acceptable. |
| certificate-not-trusted | The sender does not trust the certificate. Check your receiving mail servers SSL certificate. |
| certificate-expired | The receiving MTA’s certificate is expired. Check your receiving mail servers SSL certificate and if necessary renew / update the SSL certificate. |
| validation-failure | This is a catch-all error, i.e. if it's not one of the above errors then it will report as a general validation failure. |
MTA-STS failures
| sts-policy-fetch-error | The sender could not fetch the MTA-STS policy over HTTPS. The web server that is hosting the .well-known/mta-sts.txt file must support HTTPS communications. |
| sts-policy-invalid | The published mta-sts.txt file contains a syntax error. Please refer to the knowledgae base article on MTA-STS. |
| sts-webpki-invalid | This indicates that the MTA-STS Policy could not be authenticated using PKIX validation. |
DNS failures
| tlsa-invalid | This indicates a validation error in the TLSA record associated with a DANE policy. |
| dnssec-invalid | This indicates that no valid records were returned from the recursive resolver. |
| dane-required | This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report. |
Additional reading
More information on TLSRPT can be found in the RFC8460.
