Index

SMTP TLS reporting

TL;DR

SMTP TLS Reporting (sometimes abbreviated as TLS-RPT) is a reporting standard for secure email delivery.

SMTP TLS reports contain the sender's perspective on:

SMTP TLS reporting is especially valuable in combination with MTA-STS, as enforced mode in MTA-STS will result in undeliverable email if there is a problem with TLS.

Why SMTP TLS reporting is needed

When the SMTP email protocol was first defined in the early 80's, it did not support encrypted transport of email. Encryption using TLS was later added as the RFC3207 standard, implemented as the STARTTLS SMTP command.

To retain backwards compatibility, the MTAs will negotiate if STARTTLS is supported by both sides before the command is issued. So, the SMTP session always starts in plain text, and only switches to encrypted communication after the STARTTLS command is issued. Because TLS can fail in more ways than plain text connections, most MTAs will fall back to plain text if for some reason the TLS connection does not work.

With the introduction of MTA-STS in RFC8461, it is now possible to enforce the use of TLS when receiving email. The plain-text fallback will no longer be allowed, so if TLS fails the email will not be delivered and returned to its sender.

It is therefore important for the domain owner to be notified when TLS issues occur during email delivery. SMTP TLS reporting makes that monitoring possible.

The SMTP TLS reporting standard is defined in RFC8460.

Enabling SMTP TLS reporting

To enable SMTP TLS reporting, a DNS record of type TXT must be added to subdomain _smtp._tls.[domain] (note the use of underscores). For example: _smtp._tls.mailhardener.com.

Before delivering email to a domain, an MTA that supports SMTP TLS reporting will check for the existence of this DNS record. If found, the MTA will periodically report details on the success or failure to deliver email to the domain over a secured connection. The reports are sent to the address specified in the DNS record.

A typical SMTP TLS reporting (TLSRPT) DNS records looks like this:

v=TLSRPTv1; rua=mailto:tlsrpt@in.mailhardener.com

If you worked with DMARC before, you will be familiar with the syntax of the record.

The SMTP TLS reporting record is a key-value string, where the key and values are separated with an equal (=) character, and the key-value pairs are separated with a semicolon. Any whitespace is ignored.

Only 2 directives are specified:

key value
v The version indicator, this must be the first key-value pair in the record and must be value TLSRPTv1.
rua The address where the reports should be sent to. Multiple values are allowed and should be separated by a comma.

The rua value must specify the used scheme, for SMTP TLS reporting this must either be mailto: or https:. The mailto: scheme is similar to that used in DMARC, it specifies an email address where the reports should be sent to. Using the https: scheme requires a HTTPS enabled web server with a valid certificate for the domain, the reporting MTA will POST the report over HTTPS.

The rua value can contain multiple delivery endpoints by separating them with a comma. Both delivery schemes can be used together. However, a reporter is not obligated to deliver the report to more than one endpoint. A combined rua scheme looks like this:

v=TLSRPTv1; rua=mailto:tlsrpt@in.mailhardener.com,https://tlsrpt.mailhardener.com/v1

Since SMTP TLS reporting is designed to work in conjunction with MTA-STS, the MTA should be able to connect to a web server over HTTPS (port 443), this made the https: scheme viable for TLSRPTv1.

You can use our TLSRPT record validator to check if your domain is correctly configured to receive SMTP TLS reports.

The report format

The SMTP TLS reports are sent in JSON format, a typical report contains the following information:

The policy results may contain one or more of the supported policies, which are currently:

Some reporters only report errors, others may also report successful sessions.

A typical SMTP TLS report may look like this:

{
  "report-id":"2020-01-01T00:00:00Z_mailhardener.com",  
  "date-range":{
    "start-datetime":"2020-01-01T00:00:00Z",
    "end-datetime":"2020-01-07T23:59:59Z"
  },
  "organization-name":"Google Inc.",
  "contact-info":"smtp-tls-reporting@google.com",
  "policies":[
    {
      "policy": {
        "policy-type":"sts",
        "policy-string":[
           "version: STSv1",
           "mode: enforce",
           "mx: demo.mailhardener.com",
           "max_age: 604800"
        ],
        "policy-domain":"mailhardener.com"
      },
      "summary":{
        "total-successful-session-count":23,
        "total-failure-session-count": 1
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "123.123.123.123",
          "receiving-ip": "234.234.234.234",
          "receiving-mx-hostname": "demo.mailhardener.com",
          "failed-session-count": 1
        }
      ]
    }
  ]
}

Depending on the volume of email traffic, and the variety of email services attempting to deliver email, it is typical to receive multiple reports per day.

An aggregator service such as Mailhardener is typically used to combine, enrich and analyse the reports that are received from various MTAs.

Failure types

SMTP TLS reporting is used to report failures for SMTP TLS negotiation, DNS zone signing and MTA-STS.

TLS negotiation failures

value description
starttls-not-supported The receiving MTA did not support the STARTTLS command
certificate-host-mismatch The certificate supplied by the receiving MTA did not match its hostname
certificate-not-trusted The certificate supplied by the receiving MTA was not trusted by the sender
certificate-expired The certificate supplied by the receiving MTA was expired
validation-failure Any general validation failure not matching any category above.
value description
tlsa-invalid This indicates a validation error in the TLSA record associated with a DANE policy.
dnssec-invalid This indicates that the recursive resolver was not returning any valid record
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.
value description
sts-policy-fetch-error The MTA-STS policy could not be fetched over HTTPS by the sender.
sts-policy-invalid The MTA-STS policy could be fetched, but not validated. This usually indicates some syntax error in the policy.
sts-webpki-invalid The MTA-STS policy could not be fetched due to a PKI validation issue. This indicates a problem with the certificate supplied by the web server that hosts the MTA-STS policy file.

SMTP TLS reporting at Mailhardener

Mailhardener offers an SMTP TLS report aggregation service that combines, enriches and analyses SMTP TLS reports. When anomalies are detected, you will automatically be informed.

screenshot showing TLS report breakboard in Mailhardener dashboard
Example of a TLS report breakdown in Mailhardener dashboard

Conclusion

SMTP TLS reporting is a valuable reporting standard which makes strict MTA-STS policies safer to use. It can be used to detect TLS related issues from the sender's perspective.

SMTP TLS reports can be aggregated by services such as Mailhardener.

Tools

Further reading

Share your thoughts!

On last thing: If you have questions, comments or thoughts on this article, don't hesitate to shoot us an email.

You can also follow and reach us on Twitter @Mailhardener.

With Mailhardener you can configure, validate and monitor your domain for all aspects of email security. Mailhardener is free to use for a single domain.
Sign up now