Securing government email
Apply the government secure email policy.
This guidance applies to all email domains that public sector organisations run on the internet. You should follow this guidance if you’re in a role responsible for making sure your organisation exchanges email securely with other public sector organisations.
All gsi-family domain names (gsi.gov.uk, gse.gov.uk, gcsx.gov.uk or gsx.gov.uk) must now be replaced with a government domain like gov.uk, gov.scot, llyw.cymru or gov.wales.
How to secure email
You must:
- encrypt and authenticate email in transit by supporting Transport Layer Security (TLS) and Domain-based Message Authentication, Reporting and Conformance (DMARC) as a minimum
- use extra encryption if your data needs more protection
- make sure the recipient protects the data you send to them
- make email security invisible to end users as far as practically possible
Central government organisations should already have implemented encryption and authentication in line with the Government Cyber Security Policy.
Encrypt and authenticate email in transit
Protecting your email in transit makes it difficult to spoof your domain. Encryption and authentication only work if both the sender and the recipient use them.
To meet the Government Cyber Security Policy and protect email you must:
- support Transport Layer Security Version 1.2 (TLS v1.2) or later for sending and receiving email securely and publish a Mail Transfer Agent Strict Transport Security (MTA-STS) policy for all of your domains that receive email
- have Domain-based Message Authentication Reporting and Conformance (DMARC), DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) records in place to make email spoofing difficult
- implement spam and malware filtering, and enforce DMARC on inbound email
- set up DMARC and TLS reporting (TLS-RPT) and reviewing the data regularly
- ensure all email sending services have valid pointer (PTR) records
The Central Digital and Data Office recommends protecting email by:
-
forcing TLS when sending to *.gov.uk
-
forcing TLS when sending to any other domains you know support it if your local risk profile requires it
-
making sure you know if a TLS connection fails to partner organisations and your users know what to do if there’s a problem
-
using a provider that enforces MTA-STS policies when sending outbound email
-
using a provider that sends (TLS-RPT) and DMARC reports
-
forcing TLS to organisations you partner with if you have their agreement, where they don’t yet support MTA-STS
-
signing up to the NCSC Mail Check service to process and access your DMARC and TLS reports
Read the how to set up government email services securely for detailed information on how to set up TLS, DMARC, SPF and DKIM.
Make email security invisible to end users
Email security should be invisible to the end user as far as possible. Users should have the option to mark sensitive information if needed but not have to make complex technical decisions about sending data.
Do not make security difficult for users as they may find less secure work-arounds. Provide guidance so users:
- can continue to work with minimal disruption
- understand and can act on error or bounce-back messages
- know who to contact if things go wrong
- know if they have permission to send information by an insecure route if a secure route fails
Use extra encryption if your data needs more protection
If you routinely share bulk data with third parties consider using a secure web service or a secure bulk data transfer service. Email should not be used to transfer bulk sensitive data.
Make sure the data you send is appropriately protected by the recipient
As an information owner, you’re responsible for managing your organisation’s security risks. You should consider the protection of your data at rest as well as in transit. There is no standard list of approved, secure email domains for government. Your organisation must decide what assurance you need based on your own data and your own risk profile.
You need to understand possible risks when sharing information with other organisations and take steps to help protect your data. There are a number of approaches you can take to protect data including:
- checking to make sure the recipient has independent accreditation that shows good security practice such as Cyber Essentials Plus or ISO 27001
- asking the recipient organisation about their cyber security practices using the 10 steps to cyber security guidance
- creating a data-sharing agreement between your organisations
- relying on the reasonable expectation that the organisation you send data to will protect the data as required by legal or regulatory requirements like GDPR or the NIS Directive
- using additional encryption methods described above to protect the data in transit and at rest so you do not have to get any security information from the recipient
Further email security guidance
For more information about email security, see:
- Set up government email services securely
- Changing government email: migrating from .gsi
- NCSC guidance on TLS
- Government policy on email security
- Email security standards
- Government Cyber Security Policy
- Sender Policy Framework
- Technology Code of Practice
- Protect domains that don’t send email
- Sending emails from your service domain
Updates to this page
Last updated 4 March 2024 + show all updates
-
1) Updated to replace the Minimum Cyber Security Policy with the Government Cyber Security Policy. 2) Moved MTA-STS and TLS-RPT from ‘recommended’ to ‘must do’. 3) Added reference to PTR records 4) Changed references to Government Digital Service to Central Digital and Data Office.
-
Adding information about MTA-STS and TLS-RPT protocols to the recommendations section. Adding clarity to the make email security invisible to end users.
-
Updated information about TLS.
-
Updated information about encryption, authentication and protection of data at rest
-
The approach to email security is changing and we have removed the need to pass an assessment.
-
In this version of the guidance, CTS has: * changed and removed wording throughout the document to make it easier to understand * moved technical detail into the set up guide * 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
-
First published.