There has been a huge focus on encryption on the web recently, with lots of that centred around HTTP with things like HTTPS and HSTS. Now we're taking the same concept and extending it to email with MTA-STS, or Mail Transfer Agent Strict Transport Security.


MTA-STS

You can read about MTA-STS in RFC 8461 but I'm going to cover all of the important parts here. Much like HSTS makes TLS mandatory when using HTTP, MTA-STS makes encryption mandatory in SMTP, where it is currently optional.


Setting up MTA-STS

The first step to setting up MTA-STS is to publish your policy and for that, we're going to use the familiar 'well-known' directory that we've seen things like security.txt and the Let's Encrypt Acme challenge placed in. Here is my policy that I will be getting started with:


version: STSv1
mode: testing
mx: in1-smtp.messagingengine.com
mx: in2-smtp.messagingengine.com
max_age: 86400


The version value can only be STSv1 right now, so that's prerty easy, and the mode value can only be one of testing, enforce or none.

testing - deliver the email whether MTA-STS passes or fails, but also send a report if it would have failed.

enforce  - do not deliver the email if the mx record does not match or if a secure connection cannot be established.

none - effectively disables MTA-STS and clears the policy.

The max_age value is the number of seconds that another party should remember this policy for, just like the max_age in HSTS, so that can be set fairly low during testing. The final values are the mx values that you expect to be presented for your domain, so in my case I have my 2 mx records listed. With those values set you're good to go and create your txt file.

You can see my policy here and note that it must be created on the mta-sts subdomain of your site:


https://mta-sts.scotthelme.co.uk/.well-known/mta-sts.txt


The last thing to do is to activate the policy and that's done by creating a DNS TXT record.


_mta-sts.scotthelme.co.uk. 299 IN TXT "v=STSv1; id=1565808194"


The v value can only be set to STSv1 and the id value has to be a unique id that represents this policy and changed when you change your policy. I'm just using the timestamp of when I created the policy but you could also use a guid if you wanted to.

Now that we have MTA-STS setup, you of course want to know what impact it will have. As we saw above, the policy was in test mode and there was mention of sending reports. Starting in test mode and monitoring your reports is a necessity. You don't want to negatively impact the deliver of your emails and if there's an issue, reporting allows you to find out about it without causing any harm.


SMTP TLS Reporting

Known as TLS-RPT for short, this is the mechanism that will allow us to find out if we have any issues before we enforce our MTA-STS policy. Once the policy is enforced, ongoing reporting will let us know if any errors develop. Setting up TLS-RPT is easy and requires the creation of a single DNS TXT record.


_smtp._tls.scotthelme.co.uk. 300	IN	TXT "v=TLSRPTv1;rua=mailto:{subdomain}-d@tlsrpt.report-uri.com"


The v value should be set to TLSRPTv1 which is the only valid value right now and rua contains the locations you'd like to send reports to. The spec does allow for reports to be sent via HTTPS or SMTP and for now I'm using SMTP and so is Report URI. You can specify mailto: followed by an email address of your choosing, a HTTPS endpoint like https://example.com/tlsrpt or a comma separated list of these values.

Now you're all setup for reports it's just a case of monitoring them for any problems. Report URI will soon have support for TLS-RPT so keep an eye out for that and you can get started for free without any hassle! Also, if you might be interested in taking part in the beta, drop me a comment below.