Currently, the majority of HTTP traffic uses TLS (HTTPS) [1]. This is in part due to free and easy to manage certificates from Let's Encrypt, but also due to HTTP Strict Transport Security, an HTTP header that will tell browsers to only connect to your site via HTTPS [2].

For email, we typically use TLS to connect from our mail client to our mail server. But for email, the weak link is connections between mail servers as they forward email. Years ago, STARTTLS became a popular feature. It does allow servers to discover that the other server supports TLS, and upgrades can happen "on the fly". The system is very simple and efficient, but suffers a major shortcoming: The initial connection is in the clear without TLS, and an adversary may easily alter the content, removing the TLS header, so users will never know that their server sent the email in the clear [3].

More recently, two new standards emerged: MTA-STS (SMTP MTA Strict Transport Security) which can be used to advertise that your mail server supports STARTTLS [5], and SMTP TLS Reporting which allows other mail servers to send you reports about whether or not your mail server responded properly to TLS.

Implementing these standards for your domain is a bit tricky. In this post, I will talk about implementing MTA-STS and TLS Reporting for your domain. I will not talk about how to tell your mail server to verify MTA-STS as it sends email, or how to send TLS reports.

There are two parts to these standards: DNS TXT records that advertise that you are supporting them, and a policy file with details that is served via HTTPS.

Step 1:

First of all, make sure your systems are configured correctly and are using proper TLS certificates. In particular mail servers often use bad certificates as you can get away with it. But once you have MTA STS enabled, all these checks need to pass. As a quick check, I recommend hardenize.com (I found the cache doesn't always get cleared if you re-test, so you may wait a while or do some manual checks after the initial check with hardenize). Hardenize was created by Ivan Ristic who also created the famous ssllabs test. But unlike ssllabs, hardenize goes beyond just https and beyond just basic TLS issues.

After you pass all the tests, it is time to get started on MTA-STS

Step 2: 

Setup a virtual host at "mta-sts.example.com". The hostname has to be "mta-sts". You could add this host name to your existing web server, but it may be cleaner to set up a distinct server (virtual host) for this hostname. It has to support TLS, so make sure to setup TLS and probably a Let's Encrypt certificate with it.

Step 3:

Create the policy file. The policy file has to live in mta-sts.example.com/.well-known/mta-sts.txt . The file is a simple text file. For example:

version: STSv1
mode: testing
mx: isc.sans.edu
mx: mail.dshield.org
max_age: 600

The version should always be "STSv1". The mode can be "testing" (do not enforce the policy), "enforce" or "none". Starting with "testing" is recommended. Next, you list your mail servers. The max_age indicates how many seconds the policy is cashed. Start with something short like 10 minutes until you got it all right.

Test that the policy can be retrieved and it should be returned with a Content-Type of "text/plain".

Step 4:

Next, you need to add two DNS entries. One for MTA-STS and one for SMTP TLS Reporting:

_mta-sts.example.com TXT "v=STSv1; id=201904131609"

Again, the version is always STSv1. The ID can be any string. It is used to detect if the policy changed.

_smtp._tls.example.com TXT "v=TLSRPTv1; rua=mailto:postmaster@example.com"

The version is again fixed. the "rua" part indicates where to send the reports. you may list multiple email addresses separated by a comma. It is also possible to specify an http(s) URI to receive the reports. The reports are small JSON files like (thanks to "S J" for sharing this report received from Google):

{"organization-name":"Google Inc.","date-range":{"start-datetime":"2019-04-12T00:00:00Z","end-datetime":"2019-04-12T23:59:59Z"},"contact-info":"smtp-tls-reporting@google.com","report-id":"2019-04-12T00:00:00Z_domain.com","policies":[{"policy":{"policy-type":"no-policy-found"},"summary":{"total-successful-session-count":1}}]}

And that should be it. Let me know how it goes or add a comment with any additional tips you have. Check Hardenize.com after you are done to make sure all of this works nicely.

[1] https://letsencrypt.org/stats/
[2] https://tools.ietf.org/html/rfc6797
[3] https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
[4] https://tools.ietf.org/html/rfc8561
[5] https://tools.ietf.org/html/rfc8560

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|