Guidance for Securing UK Government Email

Document created by user.3AEuBpAOr2 Expert on Nov 16, 2016Last modified by user.oxriBaJeN4 on Jan 11, 2018
Version 8Show 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.


Applies To...


  • Administrators of Mimecast accounts who communicate by email with any UK government organisation.




The panel below gives a brief overview of what is required to be in compliance with the secure email policy. The full secure email policy can be found on the GOV.UK website

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. 


Improve Email Security


To improve email security and comply with government network policy use:

  1. Encryption: encrypt email in transit over the internet between government organizations using Transport Layer Security (TLS) version 1.2 or later.
  2. 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).
  3. Assessment: pass an assessment and commit to ensuring your email service is configured and run securely.


Organizations 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 Configuring Secure Receipt Policies and Secure Delivery 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.


Both of 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).
Secure Delivery policies should be configured to "Enforce TLS" and to use the "Strict" encryption mode, so that self-signed certificates are not accepted. Read the SSL certificates page for further information regarding the certificates that Mimecast supports. 
If you don't want to reject a connection due to a TLS handshake failure, you can use Mimecast Secure Messaging to send messages securely. This can be configured using Secure Delivery Policies.See the Secure Messaging page for more information.

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.


Whilst the government guidance only requires the implementation of inbound DMARC checks, it is recommended that you consider implementing inbound SPF and DKIM checks. This ensures you are protected against senders who are yet to implement DMARC, or have configured relaxed DMARC policies.


Inbound DNS Authentication Policies


DNS Authentication: Inbound Check policies allow administrators 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 within Inbound DNS Authentication policies:

  • SPF
  • DKIM


SPF (Sender Policy Framework)


SPF (Sender Policy Framework) helps ensure that any messages sent using a particular domain come from permitted sources.


Click image to enlarge


SPF checks work by taking the domain from the 'from address' of an inbound message, and confirming if the originating IP address is listed in the domain's SPF record. If the IP address is not listed, a failed result is returned.

It is very important to include the Mimecast IP ranges in the SPF records for your domains. This ensures you do not experience email delivery disruption due to SPF failures for outbound mail flow.


An example of 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 should look like for messages being sent outbound via Mimecast.


DKIM (Domain Keys Identified Mail)


DKIM (Domain Keys Identified Mail) allows domain owners to sign outbound messages using private / public key signing techniques. This ensures outbound messages have not been altered after leaving the sending organization's mail server.


Click image to enlarge


The implementation of DKIM 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 (Domain Based Message Authentication, Reporting & Conformance)


DMARC (Domain Based Message Authentication, Reporting & Conformance) ensures that messages are correctly authenticated using the SPF and DKIM email authentication standards. Should an inbound message fail these checks, an action is applied which is defined in the sending domain's DMARC DNS record. DMARC also allows domain owners to enable DMARC reports. These allow them to determine if their domain is being used without permission, or if action needs to be taken if messages are being rejected / quarantined unexpectedly.


Click image to enlarge


DMARC is implemented by creating a TXT record in the DNS record for a particular domain by the domain owner. 

DMARC reporting is currently not offered by Mimecast but will be included in the near future, and while highly desirable it doesn't stop you from successfully implementing the government's secure email guidance.
An example of a very basic DMARC DNS Record. This example is set to not 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 should be configured to Reject any messages that result in a DMARC failure.

View the DNS Authentication (Inbound / Outbound) Definitions and Policies page for further information on the configuration of DNS authentication.


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.

An example of a DKIM DNS Record

Mimecast-DKIM.example        86400    IN    TXT    "v=DKIM1\; k=rsa\; p=MIGg0TJUCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMh5eyPRU0FRElhlG0S3PycQhKT7240KgVG/6Cs5cItlujmSfVJLjKz31b8gZhgbyrycVCgGeUgtkxaO7aCZJevl8I/rpbUciVHtZTarHwJ+LnGTH6r0sDf9yddnvYQypltKzmIzg+/nTR6/wtgTjJWJ19V3uyUTSdiL18ceKwlQIDAQAB"

See the Configuring DNS Authentication Definitions and Policies page for further information regarding the configuration of Outbound Message Signing.

It is recommended that outbound message signing using DKIM should be 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.
4 people found this helpful