SMTP TLS Reporting
What is SMTP TLS Reporting?
Simple Mail Transfer Protocol (SMTP) Transport Layer Security (TLS) reporting is about receiving reports from the internet regarding possible connection security issues that servers experience when connecting to your inbound email systems.
Due to the open structure of the SMTP protocol, the connections between SMTP servers are susceptible to SMTP TLS downgrade attacks. The benefit of SMTP TLS reports is that it enables organizations to gain visibility and start enforcing TLS connection security via additional security standards like DNS-Based Authentication of Named Entities (DANE) and Mail Transfer Agent Strict Transport Security (MTA-STS).
What are the benefits of SMTP TLS Reporting?
With SMTP TLS Reporting, you gain visibility into the following:
- Successful and unsuccessful TLS connections
- Man in The Middle (MiTM) attacks (certificate mismatch)
- Expired certificates
- Servers not answering
- Certificates not validating against Certificate Authorities (CA)
In addition, you also have the ability to implement next-generation SMTP transport security protocols DANE for SMTP and SMTP MTA-STS.
How to set up SMTP TLS Reporting
Every dmarcian account has a unique SMTP TLS reporting address for sending reports. To find the reporting email address, login to your account, click on Settings (gear icon) in the top right, and go to the Preferences page. You’ll see the TLS JSON Reporting Address under Account Details.
Now you can publish a DNS TXT record on every domain that receives messages (i.e., has a DNS MX record) that you would like to set up monitoring. The following is an example:
NAME: _smtp._tls.example.org
TYPE: TXT
CONTENT: v=TLSRPTv1; rua=mailto:[email protected]
Note: Your DNS Provider may only need you to specify _smtp._tls as they may provide the the example.org for you; check with your DNS provider.
How to view SMTP TLS Reporting
Our TLS Reporting interface is designed like our Detail Viewer. It allows you to filter your mail flow to a specific problem area to access the data you need to make policy implementation decisions.
To use the TLS Reporting feature, log in to your dmarcian account and click on Tools (wrench icon) located in the top right. From the drop-down menu under the TLS column, click TLS Reporting.
dmarcian provides reporting and tooling as shown below to help you maintain visibility on your journey to improving the security of your email. We have reporting to accept TLS reports and inspector tools to be sure you have your records set up properly.
SMTP TLS Reporting Failure Result Types
SMTP TLS Reporting helps identify and address issues in secure email delivery by providing feedback on TLS handshake problems. The failure reports detail various types of issues encountered, enabling email administrators to address them effectively. Below are the different result types found in these reports, each indicating a specific failure during TLS negotiation and policy checks.
Negotiation Failures
- starttls-not-supported: The receiving MTA doesn’t support the STARTTLS command, which is essential for initiating a secure TLS connection.
- certificate-host-mismatch: The certificate presented by the receiving MTA does not match the expected hostname. Occurs if the certificate’s Common Name (CN) or Subject Alternative Name (SAN) fields do not include the domain name of the receiving MTA.
- This means the certificate did not match the hostname. For example, if the MTA’s hostname is “mail.example.com,” but the certificate lists “smtp.example.com,” this mismatch will trigger the error.
- This means the certificate did not match the hostname. For example, if the MTA’s hostname is “mail.example.com,” but the certificate lists “smtp.example.com,” this mismatch will trigger the error.
- certificate-expired: The certificate presented by the receiving MTA has expired.
- certificate-not-trusted: The certificate presented by the receiving MTA isn’t trusted by the sending MTA. This can occur if the certificate is self-signed or issued by an untrusted Certificate Authority (CA).
- validation-failure: This indicates a general failure for reasons not covered by other categories. When using this declaration, the reporting MTA should use the “failure-reason-code” to provide additional details to the receiving entity.
MTA-STS-specific policy failures
- sts-policy-fetch-error: The sending MTA was unable to fetch the MTA-STS policy from the server due to network issues, DNS problems, or issues with the server hosting the policy.
- sts-policy-invalid: The fetched MTA-STS policy is invalid. An invalid policy may have syntax errors or not conform to the required format.
- sts-webpki-invalid: The MTA-STS Policy couldn’t be authenticated using PKIX validation.
- This message means there was a problem checking the MTA-STS security policy using the PKIX standard. The email server couldn’t confirm the destination server’s security policy is trustworthy.
DANE-specific policy failures
- tlsa-invalid: The TLSA record, which is used in DANE to identify the server’s certificate, is invalid due to incorrect formatting or data.
- dnssec-invalid: The Domain Name System Security Extensions (DNSSEC) validation process has failed.
- dane-required: DANE is required by the sending MTA for the connection, but the necessary TLSA records are missing or invalid.
- This error indicates that the Mail Transfer Agent (MTA) tried to establish a secure connection using DANE, but couldn’t find valid TLSA records for the recipient’s domain.
We’re Here to Help
With a team of email security experts and a mission of making email and the internet more trustworthy through domain security, dmarcian is here to help assess an organization’s domain catalog and implement and manage DMARC for the long haul.
Want to continue the conversation? Head over to the dmarcian Forum.
