Set up government email services securely
Configure email services securely using encryption and anti-spoofing.
Government email administrators should follow this guidance to implement encryption and anti-spoofing. This will help to make sure your email service is configured securely and follows the guidance on securing government email.
To follow this guidance you’ll need:
-
to be able to make administrative changes throughout the email service
-
a public domain name system (DNS) record you can edit for each email domain
-
a web hosting service to publish your Mail Transfer Agent Strict Transport Security (MTA-STS) policy
Prepare to secure your email service
An email service describes any system sending emails on behalf of an organisation. This includes:
-
the service providing users with mailbox access
-
internal relays and gateways
-
email filtering services
-
third party services that send email on your behalf, like transactional email services
Configure your primary email services
Encrypt email in transit
TLS is an encryption protocol used to protect data in transit between computers. To encrypt email services use TLS version 1.2 or later, and preferred cryptographic profiles for secure email transport between UK government departments.
1. Set up TLS
Create rules to require TLS for sending to *.gov.uk. A small number of .gov.uk domains do not yet support TLS. Create an exceptions list for those domains if you need to.
If you operate a .gov.uk domain that does not support TLS you should ask any government organisations you work closely with to add you to their exceptions list.
You can choose to require valid certificates for domains you exchange email with, although not all domains have implemented this yet.
Avoid creating rules to require TLS on inbound email, unless you have a specific use case, as this can lead to messages from legacy systems being rejected. Ask the sending organisation to set up rules if you require it.
Follow NCSC guidance on TLS to make sure you are using a strong TLS cipher suite and an appropriate certificate authority (CA). Your certificates must use a common name (CN) or subject alternative name (SAN) that matches the relay hostnames.
Cloud-based email services include managed TLS certificates. If you operate an internet-facing email service, you must buy and manage appropriate TLS certificates from the Digital Marketplace.
You must enable opportunistic TLS by default for domains not included in the mandatory TLS rules. You can use self-signed certificates for opportunistic TLS.
2. Set up TLS-RPT
TLS-RPT sends you a report if someone tries to connect using TLS but fails. You can direct the reports to the NCSC Mail Check service at [email protected]. This will verify the syntax of your TLS-RPT record, and show you if any TLS failures have been reported for your domain.
Follow the guidance on setting up Email security standards MTA-STS and TLS-RPT
3. Set up MTA-STS
MTA-STS tells sending services your domain supports the use of TLS v1.2 or later.
Follow the guidance on setting up Email security standards MTA-STS and TLS-RPT.
Authenticate email
To prevent email spoofing you must put policies in place to check inbound and outbound government email using Domain-based Message Authentication, Reporting and Conformance (DMARC).
Implement DMARC by:
-
publishing a DMARC record starting at p=none rising to p=quarantine or reject during implementation
-
enabling inbound checking on your email service - this is usually the default setting
Implement Sender Policy Framework (SPF) by:
- publishing public DNS records for SPF, including all systems that send email, using a minimum soft fail (~all) qualifier
Implement DomainKeys Identified Mail (DKIM) by:
-
publishing DKIM selector and policy records
-
signing outgoing email following the DKIM standard
-
disabling outbound email footers if you have an outbound email filtering service
Have matching forward and reverse (A and PTR) DNS records for all email sending hostnames.
Configure other email sending services
Other email sending services may sit inside or outside your network, and use the same domain name as your users, or a subdomain. These email sending services include:
-
email filtering services
-
applications or scripts developed by or for your organisation
-
cloud-based applications that send email like Salesforce or MailChimp
-
line-of-business applications that send email like an HR or finance system
Encrypt email in transit
Use TLS version 1.2 or later, and present valid certificates to enable secure email transport between UK government departments. This is a requirement when purchasing any new email service for central government to comply with the Government Cyber Security Policy.
Authenticate email
To authenticate email from other sending services do the following.
-
Include additional email sending services in your DMARC and SPF records.
-
Use DKIM signing. Cloud-based applications or email filtering services will provide their own DKIM signature. You will need to create an additional DKIM DNS record. For other services you may be able to use the same signature as your other email if you send them from the same domain.
-
Ask your service provider for information about applying DKIM signatures and including email sending services in your SPF record.
-
Consider using a separate subdomain for third party email services to simplify SPF and DKIM implementation.
-
Have matching forward and reverse (A and PTR) DNS records for all email sending hostnames.
Configure your DNS records
DMARC, DKIM, SPF, TLS-RPT and MTA-STS require you to make changes to the DNS records for your domains. Contact your registrar or DNS provider to make changes to .gov.uk or other domains.
Use the WHOIS search at the .gov.uk registry to find your registrar or DNS provider.
When requesting changes you must include specific information for each record. If given the option, set a short time to live (TTL) in DNS records so you can see changes quickly and fix issues.
Create and manage DMARC records
Read the DMARC guide for more details on what it is and how it works.
Read NCSC on implementing DMARC for more information.
You must also make sure digital services have a DMARC record.
Example DMARC record:
Record type: TXT
Host or record name: _dmarc
Record value: v=DMARC1;p=none;rua=mailto:[email protected],mailto:dmarc@<yourdomain.gov.uk>
Create the email address and put your domain in place of <yourdomain.gov.uk>.
Create and manage DKIM
Read the DKIM guide for more details on what it is and how it works.
Read the NCSC guidance on implementing DKIM for more information.
It may be difficult to implement DKIM on legacy email services. In this case, you should upgrade to a compatible cloud-based service and email filtering service to apply DKIM instead of adding cost and complexity to your existing environment.
Example DKIM record:
Record type: TXT
Host or record name: selector._domainkey
Put your selector, or the selector provider by your service provider, in place of selector in the host or record name.
Record value: v=DKIM1; k=rsa; p=<your DKIM key>
Paste your DKIM key from your key generator in place of <your DKIM key>
Some providers will use a CNAME record instead of a TXT record. Follow the guidance from your provider.
Create and manage a TLS-RPT record
Read the TLS-RPT guide for more details on what it is and how it works.
Example TLS-RPT record:
Record type: TXT
Host or record name: _smtp._tls
Record value: v=TLSRPTv1;rua=[mailto:[email protected]](mailto:[email protected])
Create and iterate a MTA-STS records
Read the MTA-STS guide for more details on what it is and how it works.
Create a policy file and host it at:
https://mta-sts.yourdomain.gov.uk/well-known/mta-sts.txt
You can use your existing web host or a new provider. You must serve the policy file on HTTPS with a valid certificate.
The file must initially contain:
version: STSv1
mode: testing
mx: <your email host>
max_age: <86401> - suggested value of one day
Once you are sure you have correctly configured your mail servers and policy, move to a policy of enforce to protect your inbound email:
version: STSv1
mode: enforce
mx: <your email host>
max_age: <315576000> - suggested maximum value of one year
You can use the ‘testing’ mode initially but move to ‘enforce’ quickly or the policy will have no effect.
The max_age is the maximum time you can use a cached policy. You should check this every time the policy id in the DNS record changes.
It is important for this value to be enough to mitigate long term denial of service attacks or hosting availability problems.
List each host in your MX record on a new line beginning with mx:. You can use wildcards if applicable.
Example MTA-STS record:
Record type: TXT
Host or record name: _mta-sts
Record value: v=STSv1; id=id-value
Replace ‘id-value’ with a string for the version of your policy. We recommend you use the date and time in YYYYMMDDHHMM as the id value. Update the id value if you update the policy so sending email services will detect the change.
Check your email services are secure
Check your email certificates are valid and renewed
You must make sure your email certificates are valid and renewed, otherwise your organisation may not be able to receive emails securely.
Software as a Service email providers should manage your email certificates on your behalf. If you have issues with your certificates you should:
-
Check if you still need the domain.
-
Delete the domain if you do not use it anymore.
-
If you still use the domain, ask your certificate authority to replace your email certificates.
-
Register your domain with NCSC’s Mail Check service and make sure you set up notifications to receive security alerts.
There’s more guidance about email certificates on the NCSC website.
Check your email is authenticating
Your email may not work properly, be treated as spam or be susceptible to hijack if you have:
-
a missing SPF record
-
misconfigured or poorly configured SPF record
-
a missing Domain-based Message Authentication, Reporting and Conformance (DMARC) record
-
not configured a quarantine or reject DMARC policy
To check your email is authenticating, you should:
-
Implement the guidance on securing government email - including domains which do not send email.
-
Register your domain with NCSC’s Mail Check service, and make sure you set up notifications to receive security alerts.
Sign up to NCSC services
Use the NCSC email checking service and register your domains with MyNCSC to get security alerts.
Replace legacy PSN-based email services
You should follow guidance on moving to modern network solutions which are more flexible, current, cheaper and quicker to deploy than using bespoke services over dedicated networks.
Gsi-family domain names (gsi.gov.uk, gse.gov.uk, gcsx.gov.uk or gsx.gov.uk) are no longer being issued. Existing domains must now be replaced with a government domain like gov.uk, gov.scot, llyw.cymru or gov.wales.
If you need specific information about a Public Services Network (PSN) email provider or application email [email protected] or contact the vendor for advice.
Communicate changes to your organisation
You should communicate email security changes to anyone in your organisation who is running:
-
email filtering services
-
applications or scripts developed by or for your organisation
-
cloud-based applications that send email like Salesforce or MailChimp
-
line-of-business applications that send email like an HR or finance system
You can also communicate these changes more widely across your organisation. It may be important to explain this is a standard agreed across central government.
Updates to this page
Published 24 August 2016Last updated 4 March 2024 + show all updates
-
We have removed some instructions as the NCSC tools will now check MX records and tell you if there are any issues. We have also updated to replace the Minimum Cyber Security Policy with the Government Cyber Security Policy
-
Updates to structure and adding in information about MTA-STS and TLS-RPT
-
Added information about checking email services and restructured document to make it clearer
-
Clarifying information about encrypting email in transit and DNS changes.
-
Added information to reflect updated guidance from NCSC and restructured content to increase clarity
-
The approach to email security is changing and we have removed the need to pass an assessment.
-
Updated to reflect that GDS is no longer performing the whitelist check as email assurance is being handed over the NCSC, which uses the MailCheck tool.
-
Updated to reflect changes to PSN.
-
In this update, CTS has: * changed and removed wording throughout the document to make it easier to understand * added steps to make it clearer what you need to do to implement the guidance * added technical detail previously included in 'securing government email' * changed the document title in line with GDS style * restructured the document around the three aspects of encryption, anti-spoofing, and assessment * removed references to ADSP as it is no longer used widely enough to be valuable Aside from ADSP these updates have not changed the guidance, only the presentation.
-
First published.