Email security and anti-spoofing

This guidance is intended to help you secure your organisation’s email in two distinct ways.

Firstly, we want to protect the emails you send and receive, ensuring that the content of your communications arrives in its intended state. We recommend you use TLS to do this. The second goal is to make it difficult for fake emails to be sent from your organisation’s domains. This we achieve by showing you how to configure effective anti-spoofing controls on your domains.

In the sections which follow, Recommendations will be useful to technology leaders and IT managers. While Implementation details will help administrators implement the recommendations.

High level summary

All organisations should:

1. Ensure your email service is capable of sending and receiving email using Transport Layer Security (TLS). For a more specific set of recommendations, see the section below on configuring TLS to protect email in transit.

2. Configure these anti-spoofing controls on your domain: 

There is a section below on configuring anti-spoofing controls which provides advice on the steps you should take.

Configuring Transport Layer Security to protect email in transit

Where email is transferred over un-trusted networks, such as the Internet, its integrity and confidentially should be protected.

Recommendations:

• Configure all your email servers to support TLS, regardless of whether they are accessible from the internet or private networks 

• Ensure your email servers present a certificate with suitable cryptographic properties and that it is signed by a well-known Certificate Authority

• Ensure your email servers prefer to use a good cryptographic profile, but that lesser cryptographic profiles are supported too (and indeed support for not using TLS at all if you want to be confident you can receive emails from anyentity)

• Where possible, consider configuring your email service to force TLS between you and the organisations you regularly communicate with

Implementation details

Whilst it is possible to encrypt individual emails using protocols like PGP or S/MIME, this requires the sender and recipient to have the necessary trust infrastructure in place. This is not likely to be possible for all the parties you communicate with. So, we recommend that your email servers be configured to support encryption of the communications channel that the email is sent over, regardless of whether individual email messages sent over the channel are encrypted or not.

How TLS works with email transmission

SMTP is the protocol used by email servers to communicate – specifically, email servers performing the Mail Transfer Agent (MTA) function. The SMTP connection between two MTAs can be secured when the connecting party issues the ‘STARTTLS’ command. When the servers of both parties are well configured, the STARTTLS command will convert an insecure SMTP connection into a secure one, and the TLS protocol will protect subsequent SMTP commands and responses sent between them.

When to force TLS

STARTTLS is not a flawless technique – it is susceptible to a downgrade attack by a ‘man in the middle’ sitting between the two communicating parties. However, if your email service allows, it may be possible to force TLS to be used for communications with destinations you know are able to support it.

Selecting protocol versions, cryptographic algorithms and parameters

We recommend configuring mail servers to prefer our Preferred TLS Profile. However, it’s likely that other mail servers may not be configured to support the same profile, or may not support the use of TLS at all. So, you will need the ability to receive email without TLS if you want to receive email from unknown parties.

With parties that you contact regularly by email (eg partner organisations), it is possible to configure connections so that TLS will always be used and that the certificates presented by both mail servers are authenticated, verifying the identities of both parties.

Mail server certificates

In order for TLS connections to be established, the application connecting to your service will need to validate the identity of your server using the X.509v3 certificate which it presents.

This means your service will need a certificate which is signed by an authority that the party connecting to your service recognises and trusts. If you are using a cloud-based email provider this is likely to be done for you, and can be easily tested. However, if you operate your own MTA, you should follow our advice on generating a private key and requesting a certificate from a Certificate Authority. 

Configuring anti-spoofing controls

To avoid your domains being used fraudulently (eg for spam or spear-phishing), you should configure:

• Sender Policy Framework (SPF)
• DomainKeys Identified Mail (DKIM)
• Domain-based Message Authentication, Reporting & Conformance (DMARC) records

Correct configuration of these features will help other mail servers authenticate the email they receive from your domains.

Recommendations:

• All of your domains should have SPF and DMARC records in place, regardless of whether the domain is used for email or not
• A DMARC policy of ‘none’ is useful when setting up your anti-spoofing controls, but you should move to a policy of either ‘quarantine’ or ‘reject’ as quickly as possible, as only then will spoof email be hampered
• You should configure DKIM on domains you send email from, as it’s a stronger authentication mechanism than SPF. It will help recipients validate the legitimacy of email which has passed through an email relay en-route
• You can use a number of open source or commercial tools to help understand DMARC reports for your domains. 

Implementation details

We recommend you apply DMARC gradually, iterating your DMARC configuration over two or more steps. The sections below cover the process you should follow to create an initial DMARC record, and improve the policy by iteration.

Creating a DMARC record 

Check existing DNS

It is useful to know which DNS records already exist before making changes or creating more. You can do this using a service like mxtoolbox. 

If you have DKIM records, you need to know the DKIM selector to find the record. You can find the selector in the header of any email you send.

Create a DMARC record

Your DMARC record name is:

_dmarc

It should be configured as a TXT record, with an initial value similar to this:

v=DMARC1;p=none;rua=mailto:[email protected]

Replace yourdomain.gov.uk with your actual domain, and make sure you have created an email address called ‘dmarc’ (or something else appropriate) to receive the reports.

The ‘p=none’ part of the record above specifies the requested policy that mail receivers should apply. A policy of ‘none’ means this DMARC record won’t affect the delivery of your email, but it will provide you with reports on where your outboud email appears to be coming from. 

Within 48 hours of publishing your records you’ll start receiving email reports from major email recipient domains. The information in the reports will show you where your outgoing email originates and how it’s being handled by the major recipients.

Various commercial or open sourced tools are available to help you more easily visualise the DMARC reports you receive.

Iterating a DMARC record

Your DMARC record will only start affecting the delivery of spoofed emails once you have a record of p=quarantine or p=reject. The goal for this section is to help you get to that point.

Once you have a week or two of DMARC reports you should be able to identify where your outgoing email is being sent from. What you discover may require remedial action. There may be legitimate services sending email for you that you didn’t know about, or you may have discovered illegitimate use of your domain. Use the information gathered to create and update your SPF record and add DKIM signing.

You should understand how sub-domains are being used to send email, and update your record accordingly, if you need to.

Once you’re confident you have an accurate SPF record and are DKIM signing outbound email, update your record to have a policy of p=quarantine and apply it to a percentage of your email. This will instruct recipients to quarantine some of the email that doesn’t pass DMARC checks. Starting with a small percentage will help ensure any mistakes don’t affect all email delivery. Gradually increase the percentage to 100 as you confirm genuine email is passing all checks.

An example record with these modifications applied is:

v=DMARC1;p=quarantine;sp=quarantine;fo=1;pct=10;rua=mailto:[email protected]

Note the above record also includes the instruction sp=quarantine, which applies to subdomains of your domain. This is important as if spammers see your primary domain is protected they may use subdomains instead.

The DMARC protocol is very flexible, presenting a broad range of options. For full details you will need to read the RFC.

External reporting authorisation records

If you want to receive the reports in a different domain from the one you’re reporting on, you need to add a special TXT record to the domain you want to send the reports to as well. For example dmarc.service.gov.uk can receive reports from several other domains, like gsi.gov.uk. To allow this we created a DNS record called:

gsi.gov.uk._report._dmarc.dmarc.service.gov.uk

with the value:

v=DMARC1

Creating and iterating an SPF record

Read this guide on SPF for more details on what it is and how it works.

Create an SPF record

Create an SPF record in your public DNS using all the IP addresses or address ranges from which you send email. You can use both IPv4 and IPv6 addresses. A basic SPF record should look like:

v=spf1 include:_spf.google.com ~all

This record will allow email if it’s sent from google.com.

If you have other email sending services, you need to add their domain or IP range to this record. This SPF record includes another sending service with an IP:

v=spf1 include:_spf.google.com ip4:80.88.21.0/20 ~all

When choosing services, look for ones that can provide a sending domain or a stable IP range to make it easier to maintain your SPF record.

Creating and managing a DKIM record

Read this guide on DKIM for more details on what it is and how it works.

Creating a DKIM record and signing email

Generate the key

Creating and implementing a DKIM key varies from service to service. If you use a cloud-based email service your DKIM configuration will be automated to some extent. Look for a DKIM option in your administration panel or contact your service provider.

If you are configuring DKIM on your email servers directly, then you will need to generate an RSA public/private key pair. We recommend you use a 2048-bit key. There are several good guides on how to generate RSA key pairs for Windows or Linux.

DKIM keys do not expire but you should rotate them periodically (we suggest every 12 months). Create a new key with a new selector and follow the same steps as above. Keep the old DNS record live for a few days after making changes to give the DNS time to update.

Create an entry in the public DNS record

Add the DKIM signature to a TXT record in your DNS record. This is made up of a selector (the name of your record), the version, the key type, and the public key itself. This allows the recipient to check the key on emails which claim to be from you, against the key in your DNS. If they match, this proves the message hasn’t been tampered with in transit.

Your DNS record should have the host or record name of:

selector._domainkey.yourdomain.gov.uk

and the value:

v=DKIM1, k-rsa, <your public key>

You can check this has been applied using a DKIM lookup service and your selector. The result should look like:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCG26OM/bk0vNm/TM2DnOQjPZNLIWspF4xtIX12LGHHjfushjsaudfysuf+DUigzM6h2oJMEdNt1S/CWVXW0pUBqfU0fzdw90+jyqOduh4cCnEk0z0w1w1j4xOYy0FLHhKoeoZJwWQFtwrlhrjxD6jM+sGeeRnbn2rQIDAQAB

Apply DKIM signatures to outbound email

This will vary depending on your email service. DKIM signatures may be applied by your filtering service rather than your email server. Ask your service provider for information specific to your service.

A DKIM signature should be the last addition to a message before it is released by an email server. Since modifying the email or its headers will change its cryptographic hash, it is necessary for any signatures or standard disclaimers to be applied before it is signed with DKIM. Read more information on how certain providers handle DKIM signatures. When using email scanning services on outbound email, ensure they are configured in a way that does not break the DKIM signature (e.g. through adding a disclaimer line to the bottom of the email body).  

NCSC’s Mail Check service for the public sector

Mail Check is a service the NCSC is developing to help public sector organisations measure and improve the security of their email services. 

What the service will do

When Mail Check is released it will help public sector organisations:

• Understand whether mail servers or email services behind their domains support the secure exchange of email using TLS, and what steps to take if they don’t
• Understand whether anti-spoofing controls are correctly configured, and advise on steps that could be taken to improve them
• Understand the extent of fake email being sent from their domains, and whether it is being delivered

Additionally, Mail Check will help the NCSC:

• Understand the security of email services across the public sector
• Identify and help tackle abuse spanning multiple public sector organisations

Register your interest

If you would like to be notified when Mail Check is available to you, please let us know by filling in this form.

Source: NCSC