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 negotiation (STARTTLS)
• DNS zone signing (DANE)
• MTA-STS policy

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:

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 an 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:

• a unique identifier for the report
• the date range in which the results were collected
• name and contact information about the reporting party
• the various policy results

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

• SMTP TLS negotiation (STARTTLS)
• DNS zone signing (DNSSEC, DANE)
• MTA-STS policy

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

DNS related failures

MTA-STS related failures

SMTP TLS reporting at Mailhardener

Mailhardener offers an SMTP TLS report aggregation service that combines, enriches and analyses SMTP TLS reports.

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

• TLSRPT record validator

Further reading

• MTA-STS
• DANE
• DMARC