Email security and anti-spoofing

Emails crossing the internet use secure connections encrypted using Transport Layer Security (TLS). However, there remain vulnerabilities in this method of protecting the confidentiality of emails, whereby a person-in-the-middle can trick incoming connections to send to another server and/or send information in the clear. MTA-STS is a standard designed to address these vulnerabilities and is set out in the internet standard IETF RFC 8461.

The objectives of MTA-STS are to:

• make it harder for an attacker to get emails sent to an alternative location
• make sure that TLS encryption is always used; to prevent attackers downgrading email encryption on emails to clear text.

To achieve this, MTA-STS works in the following ways:

• your organisation can advertise the mail server hostname on a separate secure web page, which means an attacker cannot just subvert your DNS entry (specifically your MX record, which is the record that tells the internet where to send your email).
• your organisation can publish an ‘MTA-STS enforce policy’, which tells any server sending you emails to always send with TLS encryption, and to not allow connections to be downgraded. If there is a failure to establish a secure TLS connection, emails will not be delivered. Note that when your organisation sets up MTA-STS, you are securing inbound connections only.

MTA-STS is relatively simple to implement, but organisations must step through their implementation with care; if you switch on controls too quickly then inbound emails won’t be delivered. To mitigate this risk, we always recommend using MTA-STS in ‘testing mode’ first, and to set up TLS-RPT (TLS Reporting) as well, which is a mechanism for getting feedback before you progress.

The goal ultimately is to work towards implementing an MTA-STS policy of ‘enforce’. When a sending email service detects you have an MTA-STS policy of ‘enforce’, they should only send email to your domain if the connection is secure. Note however, that whilst many major email providers have built support for MTA-STS, there is not yet complete support from all vendors. For those that don’t yet support it, emails will continue to be delivered in all cases.

1. Use a tool to guide you

For those organisations that are eligible, the NCSC Mail Check service includes checks and guidance for those implementing MTA-STS and TLS-RPT. If you are not eligible, then commercial alternatives are available. A tool is not essential, but will provide additional confidence that the steps below are being completed correctly, and check for any errors made along the way.

2. Identify all domains and subdomains that you want to protect

Any domain or subdomain that has inbound email (ie every MX record ) should be in scope. Note that each domain and subdomain will require separate configuration.

3. Check all of your mail servers for TLS 1.2 and valid certificates

Use a TLS checking tool (like CheckTLS or the NCSC Check your cyber security tool) to ensure that you have the right TLS configurations in place on your email server. You must ensure that you have TLS 1.2 in place, and that your certificates are valid.

If one of your servers does not support TLS, for example if you have set up a spam trap, then note this down, and make sure that you do not include this server in your MTA-STS policy (in Step 4 later).

You will need to have confidence that you have a process for making sure your certificates are always valid and in date, or inbound emails will be lost. If you are using a cloud email service this will be done for you, otherwise you need to implement a robust process and monitoring to notify you when the certificate is close to expiry or if it has expired so needs immediate attention. If you are managing your own certificates, we would recommend staggering them so not all of your email servers expire on the same day.

4. Create and publish your initial MTA-STS policy – in testing mode

You will need to create an MTA-STS policy file (a .txt file) like the example below, using information from your own organisation. In this example for the domain ‘example.gov.uk’, there are two mail servers mx1.example.gov.uk and mx2.example.gov.uk.

You will need to decide on a suitable method of hosting this MTA-STS policy file online using a URL in the following format (replacing example.gov.uk with your domain)

https://mta-sts.example.gov.uk/.well-known/mta-sts.txt

For a live example, take a look at the ncsc.gov.uk MTA-STS Policy file

Please refer to specific guidance for how to implement MTA-STS on different common providers (Microsoft, Google, AWS etc) from the UK Government Security website. 

5. Create your MTA-STS policy discovery record

You will need to create a DNS entry we call the ‘MTA-STS policy discovery record’. This DNS record signals that your domain has an MTA-STS policy.

You will need to create a DNS entry like the following example:

_mta-sts.example.gov.uk

It is of type TXT, and has the following format:

v=STSv1; id=123456789

In the example above, you can see that the ‘id’ is 123456789. You will need to choose your own value for this id, and this must change every time you update the policy. The id can be any alphanumeric value up to 32 characters long, and must uniquely identify that version of the policy. We recommend you keep it simple: for example you could use a date stamp.

Whenever the MTA-STS policy is changed, the id value in the TXT record must be updated to a new and unique value, which signals that a new policy has been set.

For a live example, take a look at the ncsc.gov.uk MTA Policy Discovery Record

6. Set up TLS Reporting (TLS-RPT) and start monitoring

TLS-RPT will give you feedback on whether your email connections have good TLS connections, and therefore give you confidence to progress to an MTA-STS policy of ‘enforce'.

You will need to create a DNS entry like the following example:

_smtp._tls.example.gov.uk

It is of type TXT, and has the following format:

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

The email address in the above example ([email protected]) is the address associated with the NCSC Mail Check tool. Mail Check no longer processes TLS reporting, so you will need to replace this with another appropriate email address.

To simplify the analysis of TLS Reports, we recommend using a tool to simplify things, rather than trying to view the raw reports. There are lots of commercial options available.

If you are interested in understanding the design of TLS-RPT in more detail, the specification is available in the internet standard IETF RFC 8460.

7. Upgrade your MTA-STS policy to ‘enforce’

Once you have correctly set up MTA-STS in testing mode, we recommend monitoring your email traffic for the period of at least a month in order to check that there are no failures in your TLS connections.

After this point, you can implement an MTA-STS policy of enforce. This policy means that inbound emails will not be delivered if the connection does not support TLS 1.2 or higher, or TLS certificates are invalid.

Here is an example of the policy file, to replace the file you published in Step 4.

At this time, remember that you will also need to update the ‘MTA-STS policy discovery record’ DNS entry from Step 5.