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 (,, or must now be replaced with a government domain like,, or

How to secure email

You must:

Central government organisations should already have implemented encryption and authentication in line with the Minimum Cyber Security Standard.

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 Minimum Cyber Security Standard and protect email you must:

The Government Digital Service recommends protecting email by:

  • continue forcing TLS when sending to * until MTA-STS has wide industry support

  • continue forcing TLS when sending to any other domains you know support it if your local risk profile requires it, until MTA-STS has wide industry support

  • making sure you know if a TLS connection fails to partner organisations and your users know what to do if there’s a problem

  • publishing an MTA-STS policy for all of your domains that receive email

  • using a provider that enforces MTA-STS policies when sending outbound email

  • setting up DMARC and TLS reporting (TLS-RPT) and reviewing the data regularly

  • using a provider that sends (TLS-RPT) and DMARC reports

  • forcing TLS to organisations you partner with if you have their agreement

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

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:

Published 24 August 2016
Last updated 15 March 2021 + show all updates
  1. Adding information about MTA-STS and TLS-RPT protocols to the recommendations section. Adding clarity to the make email security invisible to end users.

  2. Updated information about TLS.

  3. Updated information about encryption, authentication and protection of data at rest

  4. The approach to email security is changing and we have removed the need to pass an assessment.

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

  6. First published.