Detailed guide: Common Technology Services (CTS) secure email blueprint

Read this guide to:

• understand government policy for email security
• know how to implement that policy and how it will be checked
• know what to do with legacy email domain names

1. Understand government policy

With the arrival of cloud email solutions and the new government security classification, there has been a change in government policy on email transmission, which now requires that:

• email communications between central government organisations external to the PSN must be encrypted in transit
• central government organisations must have technical and business policy in place to ensure the sender or recipient of government email can be verified

Whether an in-house team is providing your email solution or you’re buying a solution from a commercial provider, following this blueprint will ensure your email solution meets government policy, including:

• the assurance of secure email transport and sender identity outside of a trusted network
• a better understanding of the email communication from your domain
• an increase in public trust when receiving email from government organisations

Choose an email service which meets your users’ needs. Your chosen service must also meet the cloud security principles and be managed securely.

Following implementation, you 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.

2. Follow our technical specification

This guidance is provided for two groups:

• those with or moving to a cloud-based or internet connected email service
• those using the PSN email gateway to route email to and from the internet

Some government organisations may have more than one type of email service and will fall into both groups (eg dfid.gsi.gov.uk and dfid.gov.uk). The implementation of this design will look like this:

2.1. Organisations with or moving to cloud-based or internet connected email services

Email solution providers must:

• use Transport Layer Security (TLS) version 1.2 or later for secure email transport between UK government departments
• use Domain-based Message Authentication, Reporting and Conformance (DMARC) to verify the sending domain

Sending domains must force the TLS connection, do not rely on the recipient domain to do this. In support of this, solution providers must also:

• create rules to use mandatory TLS when exchanging emails with government organisations
• use a strong TLS cipher suite as described in CESG’s TLS guidance document
• use a certificate for TLS signed by an appropriate Certificate Authority (CA) as described in CESG’s TLS guidance document with a Common Name (CN) or Subject Alternative Name (SAN) that matches the relay hostname(s)
• publish supporting public DNS records for Sender Policy Framework (SPF), including all systems that send email, using a minimum soft fail (~all) qualifier
• sign outgoing email in accordance with the DomainKeys Identified Mail (DKIM) standard on all systems that send email
• publish supporting public DNS records for DKIM including selector and policy records and an Author Domain Signing Practices (ADSP) record
• publish supporting public DNS records for DMARC, starting at ‘p=none’ rising to ‘p=quarantine’ during implementation.
• have matching forward and reverse (A and PTR) DNS records for the sending hostname
• use opportunistic TLS when exchanging emails with non-government organisations
• publish DMARC reject records and ADSP ‘dkim=discardable’ records for domains that do not send email to prevent them from being hijacked
• create a policy to filter inbound messages from other UK government domains that have not implemented the guidance in this blueprint (email contact.cts@digital.cabinet-office.gov.uk for a current list)
• create an email rule to auto-reply to a message sent by CTS so we can confirm outbound TLS is enabled (email contact.cts@digital.cabinet-office.gov.uk to arrange this)
• use DMARC to verify and process inbound email

If your technology currently prevents you from implementing these steps, you should look to upgrade to a compatible service as soon as it becomes practical.

Cloud-based services will manage the cipher suite and TLS certificates on your behalf.

Cloud-based email services should include suitable anti-spam and anti-malware protection in addition to the security protection described above.

2.2. Organisations using PSN-based email services

Organisations with email services connected to the PSN use it to mitigate the threats addressed in section 2.1. The PSN email gateway will force a TLS connection over the internet with other government organisations that support it. We recommend that service providers with PSN-based email services also consider:

• using opportunistic TLS for secure email transport within the PSN
• publishing mail exchanger (MX) records in their public Domain Name System (DNS) for all OFFICIAL email domain(s) so people outside the PSN can email them
• implementing the guidance in section 2.1, in particular the publishing of DMARC, DKIM, ADSP, and SPF records

3. Change email domain names as required

PSN-based email services currently 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 the technical specification in section 2.1
• meet the assurance process covered in section 5
• use legacy domain names as an email alias for a limited period where the service meets the standards set out in this document and the Email Assurance Standard
• advise 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

4. Use appropriate encryption methods

TLS is required, but this doesn’t prevent the use of additional methods of encryption such as Secure/Multipurpose Internet Mail Extensions (S/MIME) or OpenPGP.

5. Get CTS’ assurance

To help organisations implement this blueprint CTS will:

1 - create an automated service to check:

• domains meet the technical and assurance requirements
• TLS is available in both directions, is the right version, and uses an appropriate cryptographic profile
• certificates are enabled, current, and of the right type
• public DNS records exist
• SPF, DKIM, and DMARC records exist in public DNS

2 - include cloud-based email services in the information assurance process to check:

• the service is managed securely according to CESG guidelines and the Email Assurance Standard
• the implementation of this blueprint

3 - use the information gathered by this process to:

• provide lists to subscribing organisations to support their mail filtering policies
• publish a monitoring dashboard for all domains showing where connections are encrypted, verified, and have evidenced a secure email service
• provide end users with information to support their decision on where it is appropriate to securely send OFFICIAL information

4 - share information on email domains not implementing the guidance in this blueprint with:

• organisations concerned to support implementation
• other government organisations to support email filtering policies

Assurance checks will include:

• all gov.uk domains with the option to include non-gov.uk domains
• running a secure email service as well as secure email delivery

6. Maintain your documentation and end user policies

Email system administrators must understand this policy, the technology concerned, and the specifics of its implementation in their organisation.

We won’t need to change acceptable use policies. End users shouldn’t need documentation or training following the implementation of this solution.

Individuals or departments using gsi.gov.uk as a designation of security should expand that to include gov.uk email domains implementing this blueprint.

7. Buy the solution

Use the Digital Marketplace buyer’s guide and follow government procurement policies for technology. If you’re a central government department, a non-departmental body or an arm’s length body, you’ll come through the Cabinet Office Spend Controls process.

You may need to purchase Transport Layer Security (TLS) certificates from the Digital Marketplace so that you can implement your new secure email service. CESG has published guidance on selecting an appropriate CA.

You may find a third party provider on the Digital Marketplace to analyse DMARC reports.