TLS Reporting (TLS-RPT) Explained
TLS Reporting is a mechanism that allows domain owners to receive automated feedback about issues with email delivery concerning TLS encryption. TLS (Transport Layer Security) is crucial for securing email in transit by encrypting the connection between mail servers. TLS-RPT is particularly valuable in identifying and troubleshooting TLS-related problems that could compromise email security.
Relationship with MTA-STS
TLS-RPT is often used in conjunction with Mail Transfer Agent Strict Transport Security (MTA-STS). MTA-STS is a policy framework that allows a domain to publish a policy defining how its mail servers should behave when sending emails to other domains that support TLS. Essentially, MTA-STS tells sending servers what to do (like reject or accept a message) when a TLS connection cannot be established as expected.
Analogies with DMARC:
- TLS-RPT is akin to the DMARC's RUA (Report URI Aggregate) tag. DMARC RUA tag is for receiving reports about DMARC authentication, while TLS-RPT is for receiving reports about TLS encryption
- MTA-STS parallels the DMARC policy tag, which defines how an email should be treated if it fails DMARC checks. Similarly, MTA-STS specifies actions when an email can't be delivered over a secure TLS connection
Analyzing the TLS Report dashboard:
1. Reporter: This is the name of the organization that generated the TLS report. In this case, it's "Microsoft Corporation
2. Policy mode: The domain to which this policy applies, which is "easydmarc.com" in this case, and the policy is set to "enforce"
3 & 4. Result Type / Session Count: The total number of successful email sessions that complied with the TLS policy during the reporting period. Here, it's 4791.
5. Receiving MX: The mail exchange (MX) hostname that was the target of the session. In the above case, it's N/A, since the transaction was successful.
6. Receiving IP: The destination IP address that was used when creating the outbound session. In most of the cases, this will be empty as it is not yet supported by the reporters.
7. Sending MTA IP: The IP address of the Sending MTA that attempted the STARTTLS connection. In many cases, this field will be left empty or marked as N/A.
8. Date: Specifies the time period the report covers.
Types of Failures
TLS Negotiation Failures
- starttls-not-supported: This error occurs when the receiving MTA does not support the STARTTLS command, indicating a lack of TLS negotiation capability.
- certificate-host-mismatch: This failure happens when there's a discrepancy between the receiving MTA's certificate and its hostname.
- certificate-not-trusted: This error is reported when the sending party does not trust the certificate provided by the receiving MTA.
- certificate-expired: This indicates that the receiving MTA is using an expired certificate.
validation-failure: This category encompasses various general validation issues not specifically covered by the other types.
MTA-STS Related Failures
- sts-policy-fetch-error: This error occurs when the sender is unable to fetch the MTA-STS policy over HTTPS.
- sts-policy-invalid: This indicates a syntax error within the MTA-STS policy that prevents its validation.
- sts-webpki-invalid: This failure is due to an issue with PKI validation when fetching the MTA-STS policy.
DNS Related Failures
- tlsa-invalid: This error signals a validation issue with the TLSA record.
- dnssec-invalid: This indicates a failure by the recursive resolver to return a valid DNSSEC-signed record.
- dane-required: This suggests that the sending domain's requirement for DANE TLSA records was not met due to the absence of DNSSEC-validated TLSA records for the destination domain's MX hosts.
Investigating Failures
- Review TLS Reports Regularly: Domain owners should set up a process for regularly reviewing TLS-RPT reports. These reports provide valuable insights into the nature of any TLS-related issues encountered during email delivery.
- Analyze Failure Types: By understanding the types of failures (e.g., starttls-not-supported, certificate-host-mismatch, certificate-not-trusted, etc.), administrators can pinpoint specific problems. Each failure type suggests a different issue, whether it's a configuration error, a certificate issue, or a protocol incompatibility.
- Verify MTA-STS Policies: For MTA-STS related failures, ensure that the MTA-STS policy is correctly published and free of syntax errors. Use online validators to check your MTA-STS policy syntax and correct any issues found.
- Check DNS and TLSA Records: For DNS-related failures, verify the correctness and validity of DNSSEC and DANE TLSA records. Incorrect DNS configurations can lead to failures in email delivery security mechanisms.
Enforcing the MTA-STS Policy
- Start in Testing Mode: Before fully enforcing MTA-STS policies, it's crucial to start in testing mode. This approach allows domain owners to collect data on potential delivery issues without impacting email delivery. Testing mode helps in understanding how often and under what circumstances emails might fail to be delivered securely.
- Transition to Enforce Mode: Once you're confident in the stability and correctness of your TLS and MTA-STS configurations, transition your policy to enforce mode. This change signals to sending servers that emails should be delivered over TLS-encrypted connections or not at all, according to your MTA-STS policy.
- Monitor and Adjust: Even after moving to enforce mode, continuous monitoring is necessary. New issues might arise as email infrastructure changes, or as external servers update their configurations. Be prepared to revisit TLS-RPT and MTA-STS settings and make adjustments as needed.