- Applies To...
- Encrypting Email Traffic Using TLS
- Securing Email Domains Using DNS Authentication Policies
This guide shows how you can use Mimecast's services to implement the UK government's secure email guidance.
- 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:
- 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-based Message Authentication, Reporting and Conformance (DMARC).
- 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 Secure Receipt Policies and Secure Delivery Policies.
Secure Receipt policies can be used to apply TLS to connections used to:
Secure Delivery policies are applied to connections used to deliver messages from Mimecast. Specifically to:
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).
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 (Sender Policy Framework)
SPF (Sender Policy Framework) helps ensure that any messages sent using a particular domain come from permitted sources.
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 include:_netblocks.mimecast.com ~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.
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.
DMARC is implemented by creating a TXT record in the DNS record for a particular domain by the domain owner.
v=DMARC1; p=none; rua=mailto:firstname.lastname@example.org
Read the DNS Authentication - Inbound Checks 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 DNS Authentication: Outbound Signing page for further information regarding the configuration of Outbound Message Signing.