Email security and anti-spoofing

Created:  15 Sep 2017
Updated:  29 Oct 2018
A guide for IT managers and systems administrators

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.

Public sector organisations can also:

Follow the additional recommendations in the GDS guidance on securing government email.

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.


  • 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 any entity)
  • 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.

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. You should select the best profile that is supported by the connecting mail server. You will need to be able to receive email without TLS if you want to be confident you can receive email from any party.

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.

With parties that you contact regularly by email (e.g. 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 (e.g. 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.


  • 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 soon as you are confident DKIM and SPF are working correctly, 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:


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


Replace 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 outbound 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.


Additional DMARC reporting addresses for public sector users

Public sector organisations can share a copy of their DMARC reports with the NCSC by adding an additional email address to their DMARC record. For example:



Adding the entry to your DMARC records means your reports will be available for you to view in the NCSC's Mail Check tool, access Mail Check or learn more.  

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:


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 can receive reports from several other domains, like To allow this we created a DNS record called:

with the value:


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:


This record will allow email if it’s sent from

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 ~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.

DKIM is not universally supported

Whilst the major cloud-based email service providers now make it easy for you to configure DKIM, some providers and some email servers that you might be using do not currently support DKIM. Where this is the case, you will not be able to DKIM-sign email you send. Notably, Microsoft Exchange Server is one prevalent technology which doesn't support native DKIM, although Microsoft’s Office 365 service does.

If your email service or email servers cannot support DKIM, you might still be able to DKIM-sign some of the email you send if it is sent via a service which can apply a DKIM signature for you.

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:

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:


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

The NCSC’s Mail Check is a freely available service to help public sector email administrators improve and maintain the security of their email domains. It does this by assessing a domain’s email configuration against the recommendations above and through processing DMARC reports to help organisations understand the sending of legitimate and spoofed email from their domain.

Sign up

If you have a public-sector email address you can sign up for an NCSC account and access the service.

If you do not have an email address accepted by the service but believe you should have access, get in touch with us at 

Mail Check is a service intended to support organisations in making their own decisions about how to configure their email security. Whilst it also helps users understand the security posture of other domains, organisations must make their own risk management decisions about who they are comfortable to exchange email with.

Was this guidance helpful?

We need your feedback to improve this content.

Yes No