Guidance for Securing UK Government Email

Document created by user.3AEuBpAOr2 Employee on Nov 16, 2016Last modified by user.oxriBaJeN4 on May 31, 2019
Version 10Show Document
  • View in full screen mode

This guide shows how you can use Mimecast's services to implement the UK government's secure email guidance. See the Securing Government Email page on the Government's website for further details. Make sure your supplier can configure email services securely.


In summary, to improve email security and comply with government network policy use:

  • Encryption: Encrypt email in transit over the internet between government organizations 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 Message Authentication Reporting and Conformance (DMARC), Sender Policy Framework(SPF), and Domain-Keys Identified Mail (DKIM). This ensures you're protected against senders who are yet to implement DMARC, or have configured relaxed DMARC policies.
  • 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.

Encrypting Email Traffic Using TLS


Mimecast allows administrators to secure the communication channel used to transmit messages over the internet. This is achieved via the creation of the following policies:

  • Secure Receipt Policies can be used to apply TLS to connections used to:
    • Send outbound email from a Mimecast customer.
    • Send inbound email from an external sender.
    • Enforce TLS connections when receiving messages.
  • Secure Delivery Policies are applied to connections used to deliver messages from Mimecast. Specifically to:
    • Send inbound email from Mimecast to your organization.
    • Send outbound email from Mimecast to external recipients.
    • Enforce TLS connections when receiving messages.
Secure Delivery policies must be configured to "Enforce TLS" and use the "Strict" encryption mode. This ensures self-signed certificates are not accepted. See the SSL certificates page for further information regarding the certificates that Mimecast supports.

These policies can be configured to be applied to the following scopes of users:

  • Inbound, outbound, or all connections.
  • Specific domains (either by individual policy or using address groups).
If you don't want to reject a connection due to a TLS handshake failure, you can use Secure Messaging to send messages securely. This can be configured by using the "Enforces TLS - Fallback to Secure Messaging" value in the Select Option field of a Secure Delivery Policy.

Securing Email Domains Using DNS Authentication Policies


DNS Authentication combines three industry standard email authentication technologies: SPF, DKIM, and DMARC. These allow domain owners to control who sends on behalf of their domains, as well as validate the authenticity of inbound messages, thereby minimizing the volume of unwanted messages reaching end users.


Inbound DNS Authentication Policies


DNS Authentication: Inbound check policies allow you to prevent unwanted and potentially harmful messages from reaching users. They also protect the reputation of the domains under your control. When enabled, inbound DNS authentication checks are performed against all messages regardless of any Auto Allow or Permitted Sender entries being present.


The following checks can be enabled in DNS Authentication - Inbound policies:

  • SPF: You must include the Mimecast IP ranges in the SPF records for your domains. This ensures you don't experience email delivery disruption due to SPF failures for outbound mail flow. The example below is a relaxed SPF record:
    "v=spf1 ~all"

    See the Connect Application: Implementing SPF for Outbound Email Delivery page for examples of what an SPF record must look like for messages being sent outbound via Mimecast.

  • DKIM: This requires a public DKIM key to be published in a TXT record in the DNS record for a particular domain by the domain owner.
  • DMARC: This requires a public DKIM key to be published in a TXT record in the DNS record for a particular domain by the domain owner. An example of a basic DMARC DNS Record is below, that is configured not to apply an action when a DMARC check returns a failure result. However failure reports are sent to the listed email recipient for review.
    v=DMARC1; p=none;
    Inbound DMARC checks must be configured to Reject any messages that result in a DMARC failure.
DMARC reporting is currently not offered by Mimecast. While it is highly desirable, it doesn't stop you from successfully implementing the government's secure email guidance.

Outbound DNS Authentication Policies (DKIM Message Signing)


Outbound DKIM message signing is used to secure outbound emails leaving an organisation, via the use of special cryptographic message headers entries. This enables the recipient's mail server to decrypt the header entry to determine if the message has been manipulated during transit. This is achieved by generating a public key entry via a DNS Authentication Outbound Signing Definition. This value is then inserted into the DNS Records of the domain you wish to secure. After which Mimecast will validate the DNS Record to ensure all is correct.


Here's an example of a DKIM DNS Record

Mimecast-DKIM.example        86400    IN    TXT    "v=DKIM1\; k=rsa\; p=MIGg0TJUCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMh5eyPRU0FRElhlG0S3PycQhKT7240KgVG/6Cs5cItlujmSfVJLjKz31b8gZhgbyrycVCgGeUgtkxaO7aCZJevl8I/rpbUciVHtZTarHwJ+LnGTH6r0sDf9yddnvYQypltKzmIzg+/nTR6/wtgTjJWJ19V3uyUTSdiL18ceKwlQIDAQAB"
We recommend that outbound message signing using DKIM is performed by the Mimecast Gateway rather than the sending mail server. This is because changes made to a message (e.g. adding stationery or disclaimers) can cause DKIM checks to fail.

Restricting TLS and Cipher Versions


Legislation mandated by National Cyber Security Centre (NCSC) means all public sector organisations must enforce at least TLS 1.2 or greater, and use a specific set of ciphers for inbound email communication. See the Using TLS to protect data - NCSC Site page on the UK Government's website for more information.


To support the standards outlined by the NCSC, Mimecast offers the ability to restrict the versions of TLS that our MTAs accept during TLS negotiation to TLS 1.2 or greater. If a sender attempts to email a customer that has migrated to these hostnames, and using a TLS version lower than TLS 1.2 or using ciphers that are classed as insecure, the connection attempt is rejected.

Mimecast current only supports TLS 1.2 on the PSC hostnames.

In order to enforce compliance with the guidance outlined by the NCSC, the following steps must be taken:

  1. Change your MX records to use the "" and "" domains rather than the default inbound Mimecast hostnames of "" and "". These domains enforce the updated restrictions.
  2. Update the following policies to use the following configuration:
    • Secure Delivery: Set the SSL Mode in the definition to a value of "NCSC Compliance". This supports compliance of the UK's National Cyber Security Centre (NCSC) standards regarding securing email communication using TLS. See the Configuring Secure Delivery Definitions and Policies page for full details.
    • Secure Receipt: Set the Select Option in the policy to a value of "TLS 1.2 or Greater + NCSC". The connection must be encrypted using TLS 1.2 or greater, and using encryption standards that conforms to the UK's National Cyber Security Centre (NCSC) guidance for securing email. If encryption can't be negotiated, the message is not accepted by Mimecast. See the Configuring Secure Receipt Policies for full information.


See Also...


6 people found this helpful