What is MTA-STS?

Mail Transfer Agent Strict Transport Security (MTA-STS) is a security mechanism that enables mail providers to state that they’re able to receive TLS (Transport Layer Security) secured SMTP connections. It also allows recipient mail servers to inform senders to refuse delivery to mail servers that do not offer TLS.

What this means in plain english:

Ensures that all mail delivery is encrypted with TLS (TLS v1.2+)
Prevents downgrade to cleartext with man-in-the-middle (MitM) attacks
Senders are blocked from delivering mail to configured, but unsecured mail servers

How does MTA-STS work?

MTA-STS works by hosting a plain text file that’s accessible to the public internet. This file is the policy that a sending mail server will use to determine if it should communicate over TLS and verify the recipient mail servers noted within.

When sending an email, the sender mail server retrieves and caches this policy, and uses its configuration to verify the recipient mail server (via MX records) matches what is configured.

If the recipient server is set to “enforce” the policy, but the mail server cannot receive TLS connections, the delivery of the email will be blocked.

The setup of MTA-STS is pretty simple, but an incorrectly configured policy can prevent your organisation from receiving inbound emails. When starting off it’s highly recommended to implement a “testing” policy rather than an “enforce” policy.

Enabling TLS reporting (TLS-RPT) can allow your IT team to debug any potential failures of the policy before MTA-STS is switched on fully.

MTA-STS Example Policy Configuration

A sample MTA-STS policy looks like this:

version: STSv1
mode: enforce
mx: mx.example-server.com
max_age: 86400

As of writing the version must be exactly STSv1. There are no alternate versions available.

That policy is set to “enforce” TLS communication only with mx.example-server.com. The options for mode are:

enforce: Block insecure connections
testing: Log interactions
none: This essentially does nothing, and makes the policy a placeholder

With the mail server configuration via mx, you can have a single server (as shown in the example), you can use a wildcard like *.mx.example-server.com, or you can place multiple mail server entries like so:

mx: server1.example-server.com
mx: server2.example-server.com

If you have multiple web servers, and one of them does not support TLS, you should not include it here as it will cause failures for receiving mail.

The max_age value is used to define how long a sending mail server should cache the policy. The example above is set to 1 day (in seconds), so multiple emails per day from a sender wouldn’t need to re-fetch that policy.

One thing to note here is that if you are deploying a change to the MTA-STS policy and you make a mistake whilst having a longer max_age, then this can cause that invalid policy to be cached by senders. When making changes, or if you’re first deploying this, we’d recommend that you use a lower value (e.g. 3600, an hour) until you can validate that the policy is working correctly.

Deploying MTA-STS

To deploy MTA-STS you’ll need to do three things:

Create a policy file and deploy it to a publicly accessible endpoint
Create a new DNS TXT record for your domain
(Optionally) deploy TLS reporting – highly recommended

Where to host the MTA-STS policy

To allow sender mail servers to retrieve your policy it needs to be publicly accessible. There are no methods of altering where this policy can be fetched from, and it must be retrieved under the mta-sts subdomain, with the path /.well-known/mta-sts.txt

https://mta-sts.<domain>/.well-known/mta-sts.txt

Once deployed, the file should be readable and returned as plaintext.

Configuring the MTA-STS DNS record

To deploy the DNS record, which is used by sender mail servers to discover the policy, you’ll need to create a new TXT record for your domain:

_mta-sts.<domain>

With the example above replace the <domain> placeholder, if you’re using Cloudflare or another registrar you’ll only need to insert the subdomain key _mta-sts.

The value within this TXT record contains two things:

The STS record version
A bespoke ID for your policy

An example of this TXT record value looks like this:

v=STSv1; id=abcd1234

The first section must match v=STSv1, separated by a semi-colon, and then the ID parameter can be up to any 32 alpha-numeric characters.

We’d recommend changing the record id each time that the policy itself is updated. Using a timestamp is one option that is a quick way to identify the changes.

Debugging MTA-STS via TLS RPT (TLS Reporting)

If you’re making a change to your MTA-STS policy, or are about to deploy it for the first time, we’d highly recommend also implementing TLS RPT alongside the testing mode for MTA-STS.

TLS reporting provides feedback on the success or failure of inbound emails. These are sent from the mail providers (e.g. Google, Microsoft) as a summary in JSON format. There are a few tools that can be used to parse these, but they can easily be unzipped from the received attachment and viewed in a browser without any difficulty.

To set up TLS RPT you’ll need to deploy another DNS TXT record:

_smtp._tls.<domain>

Here, the DNS TXT key is _smtp._tls under your domain.

The value of this TXT record should look like this:

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

Similar to the DMARC reporting configuration, you can use either mailto to send to an email address, or if you’re using a service to capture these, you can set it as https. Comma-separated URIs can be used here under the rua directive.

Enforcing MTA-STS

After deploying MTA-STS and observing it under testing mode for a while, assuming there have not been any reported failures, it’ll be time to enable the policy under enforce mode.

To do this, you’ll simply need to update the policy as per the example above, and then adjust the id parameter in the DNS TXT record. Make sure to extend the max_age as appropriate for your business requirements – start small and increase it over time if concerned with the policy blocking inbound emails.

Configuring subdomains for MTA-STS

One thing to note is that each subdomain must have its own MTA-STS configuration. As per the RFC, subdomains must have their own individual records – this can be done by configuring an individual DNS TXT record for each subdomain that sends mail (e.g. [email protected]).

Secure your email with MTA-STS