Securing government email
Understand government secure email policy, improve email security and pass a service assessment for secure cloud-based email services.
Read this guidance if you manage government IT.
Central government organisations must follow this guidance for their email service to be considered secure by the rest of government. Local government should follow it. It’s useful for the wider public sector.
Whether your email service is provided in-house or by a commercial provider, read this guidance to:
- find out why and how to set up secure email services for a government organisation
- understand our secure email assessment process
- better understand what email traffic is being sent from your domain
- deal with legacy email domain names
Following implementation, your users will only be able to send email using your designated email services. Email sent from other services is likely to be marked as spam by the recipient service.
This guide describes how to configure your existing email service so it’s secure. You may not have to buy anything, or it may help you move to a cloud-based email service. Make sure your supplier can configure email services securely. If you do need to buy a solution, visit the Digital Marketplace.
Improve email security
To improve email security and comply with government network policy use:
- Encryption: encrypt email in transit over the internet between government organisations using Transport Layer Security (TLS) version 1.2 or later.
- Anti-spoofing: put technical and business policies in place to check inbound and outbound government email using Domain-based Message Authentication, Reporting and Conformance (DMARC).
- Assessment: pass an assessment and commit to ensuring your email service is configured and run securely.
Organisations using cloud-based or internet connected email services must follow this configuration guidance. Organisations using Public Services Network (PSN)-based email services are strongly recommended to follow this configuration guidance.
The diagram below shows cloud-based and PSN-based email services using TLS. They do this internally within PSN and via the cloud-based email filtering service connected to the PSN email gateway. Services look up information in public domain name system (DNS) records to route and verify email.
Choose your email domain name
Many PSN-based email services use the identifiers .gsi, .gse, .gcsx, and .gsx in their email domains. In the long term, these no longer make sense if the service isn’t hosted on a government network. However, they are impractical to remove in the short term. Organisations moving to cloud-based email services should:
- create a new domain name in line with the existing domain naming guidance
- use legacy domain names, including .gsi, gse, gcsx, and .gsx, as an email alias
- tell all users to communicate their new email address to contacts
- update relevant internal and external systems to use the new domain name
- ensure the selected service has the capability to support alias domains, which may be added by government at a future date to signpost email usage
Use appropriate encryption methods
Organisations should use TLS because it:
- is a widely used open standard
- doesn’t add significant cost
- is invisible to the end user
Although TLS is preferred you can use other methods of encryption. For example, Secure/Multipurpose Internet Mail Extensions (S/MIME) or OpenPGP.
Pass an assessment
Pass an assessment to get your domain added to the whitelist of secure government domains.
The assessment will check you have implemented this guidance. To pass the assessment, you must commit to running your email service in a secure way.
All internet-facing government email domains must pass an assessment. PSN-facing domains don’t need to pass an assessment, but must still follow the guidance. Domains moving from the PSN to the internet need to pass before we approve email routing changes.
If you pass, your domain will appear on the whitelist for 2 years. An automated service will check your encryption and anti-spoofing every day. We’ll tell you if there’s a problem and we may remove your domain from the whitelist if you don’t manage to fix it. You can request access to the automated service to help you implement the guidance.
The whitelist will be made public soon to help organisations decide where to securely send information classified as OFFICIAL.
Maintain your documentation and end user policies
Email administrators must understand:
- the technology concerned
- this policy
- its implementation in their organisation
You won’t need to change acceptable use policies. End users shouldn’t need documentation or training following the implementation of this solution. Allow email to and from all organisations on the whitelist. You can also request the whitelist using this form.
Read more about government email security
- Configure email services securely
- Sensible email security (blog post)
- NCSC guidance on TLS
- Government policy on email security
- Cloud security principles
- Email security standards
Email any questions about this guidance to firstname.lastname@example.org.
Published: 24 August 2016
Updated: 25 August 2016
- 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.