The SMTP TLS reporting is a tool to identify probable misconfigurations. SMTP is a communication channel for sending electronic mail. For a better understanding let’s go through the SMTP TLS reporting method step by step

WHAT IS SMTP TLS REPORTING?

SMTP TLS Reporting is a way to improve the security of your email communications by requiring all email servers that you communicate with to use Transport Layer Security (TLS) when sending emails to your domain. This helps to protect your email communications from being intercepted and read by third parties.

The SMTP TLS genesis

The SMTP TLS (Transport Layer Security) extension was originally defined in RFC 3207. The extension is used to secure SMTP communication using TLS encryption. The SMTP TLS extension is supported by most modern SMTP servers and clients. However, it is not required for SMTP operation.

SMTP TLS-RPT: WHY DO YOU NEED IT?

TLS-RPT is a standard that enables an SMTP server to report back to a sender whether its messages were successfully delivered using transport layer security (TLS). This standard is important for a number of reasons, including:

• It helps ensure that messages are delivered securely.
• It helps senders identify potential problems with their TLS configuration.
• It helps recipient organizations identify potential problems with their TLS configuration.
• It provides a way for senders and recipients to share information about their TLS configurations.
• It helps sender and recipient organizations improve the security of their email communications.

HOW DOES TLS-RPT WORK?

TLS-RPT uses a simple, standard format to report back on the TLS status of messages.
When an SMTP server receives a message, it checks to see if the message was delivered using TLS. If the message was not delivered using TLS, the SMTP server reports back to the sender with a “fail” status. If the message was delivered using TLS, the SMTP server reports back to the sender with a “success” status. TLS-RPT is designed to work with any SMTP server. It does not require any special configuration or software.

How is SMTP TLS reporting enabled?

If users want to enable TLS-RPT, they must add a DNS record of the TXT type to the subdomain _smtp. tls.[domain]. _smtp. tls.sampledomain.com, as an illustration.

Before delivering the email to the recipient’s domain, the MTA supporting SMTP TLS reporting will determine whether this DNS record is present. If the DNS record is present, it will periodically inform the domain owner if the email was successfully delivered or whether there was a delivery failure.

An example of an SMTP TLS-RPT DNS record might be:

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

The equal “=” character divides the key and values in the TLS-RPT record, which is a key-value string. The semicolon “;” that separates the key-value pairs is also used, and any whitespace is ignored. There are two derivatives:
The primary key-value pair in the record is

• “v”; it serves as the version indicator.
• “rua” identifies the location where the reports must be sent. Multiple values may be entered and are separated by commas.

The “rua” value, which for TLS-RPT can be either https: or mailto:, defines the employed protocol. An HTTPS-capable server with a domain-specific certificate is required for the https: scheme. The mailto: scheme, which defines the address that will receive the reports, is similar to the one used in DMARC.

The “rua” value may contain one or more delivery endpoints, separated by commas. A user has the option to combine the two delivery methods. Here is an example of an illustration of a mixed “rua” scheme.

v=TLSRPTv1; rua=mailto:[email protected],https://tlsrpt.sampledomain2.com/v1

What Format does TLS Report use?

The TLS Report is formatted like an HTML web page that can be viewed in any browser.

How Do I Get The TLS Report?

The TLS Report is delivered via e-mail as an HTML attachment. Simply use our tool to view your report.

What Are The Various SMTP Reporting Failure Types?

There are several different types of failures that can occur when using SMTP TLS reporting. These include TLS negotiation failures, MTA-STS related failures, and DNS related failures.

TLS negotiation failures

• starttls-not-supported: The STARTTLS instruction is not supported by the receiving MTA.
• certificate-host-mismatch: The hostname and certificate for the receiving MTA do not match.
• certificate-not-trusted: The recipient MTA’s provided certificate is not trusted by the sender.
• certificate-expired: The recipient MTA’s certificate has run out of validity.
• validation-failure: Other generic validation errors aside from those listed above constitute to this failure.

MTA-STS related failures

• sts-policy-fetch-error: The sender was unable to successfully retrieve the MTA-STS policy over HTTPS.
• sts-policy-invalid: It indicates a syntactic mistake in the policy which prevents the MTA-STS policy from being validated.
• sts-webpki-invalid: It denotes the inability to retrieve the MTA-STS policy as a result of PKI validation problems.

DNS related failures

• tlsa-invalid: A TLSA record validation error is what it denotes.
• dnssec-invalid:  It demonstrates the recursive resolver’s failure to deliver a reliable record.
• dane-required: It recommends that the sender domain requires DANE TLSA records of the destination domain (MX hosts), but it could not discover any DNSSEC-validated TLSA records.

How To View SMTP TLS Reporting

Skysnag’s TLS Reporting checker allows you to acquire the information you need to decide how to apply a policy, you can filter your mail flow to a certain area of concern.

Skysnag offers TLS reporting and tools to help you improve the security of your email. Our reporting accepts TLS reports and our inspector tools help you ensure your records are configured properly. Get started with Skysnag by signing up using this link for a free trial.