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.
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.
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).
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 include:_netblocks.mimecast.com ~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; rua=mailto:firstname.lastname@example.orgInbound DMARC checks must be configured to Reject any messages that result in a DMARC failure.
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"
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.
In order to enforce compliance with the guidance outlined by the NCSC, the following steps must be taken:
- Change your MX records to use the "eu-smtp-inbound-psc-1.mimecast.com" and "eu-smtp-inbound-psc-2.mimecast.com" domains rather than the default inbound Mimecast hostnames of "eu-smtp-inbound-1.mimecast.com" and "eu-smtp-inbound-2.mimecast.com". These domains enforce the updated restrictions.
- 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.