Guidance

Set up government email services securely

Configure email services securely using encryption and anti-spoofing to pass your assessment.

Government email administrators should follow this implementation guide to configure email services securely. It describes how to implement encryption and anti-spoofing, and how to pass an assessment to ensure your email service is configured and run in a secure way. Doing these three things will add your domain to a whitelist, which organisations can use to filter inbound and outbound email.

This is a generic guide: if you need specific information about an email provider or application complete this form or contact the vendor for advice.

If your technology currently prevents you from implementing this guidance, you should consider upgrading to a compatible service as soon as it becomes practical. Buy your chosen cloud-based email service from the Digital Marketplace.

Prepare to secure your email service

‘An email service’ describes any system sending emails on behalf of an organisation. This includes:

  • the service providing users with mailbox access
  • internal relays and gateways
  • email filtering services
  • third party services that send email on your behalf, like transactional email services

To implement this guidance you need an email service that can be configured to:

You’ll also need:

  • to be able to make administrative changes throughout the email service
  • a public domain name system (DNS) record you can edit for each email domain

GDS has built a domain information tool to help email administrators and information security officers check they have secured their email services correctly. It also provides access to a domain whitelist - a list of domains that currently meet the secure email guidance.

The tool is in alpha but already provides the information needed to implement the guidance. Request access to the tool using this form.

Configure cloud or internet-based email services

Encryption

Follow these steps to encrypt email services:

  1. Use TLS version 1.2 or later and preferred cryptographic profiles for secure email transport between UK government departments.
  2. Create rules to use mandatory TLS when exchanging emails with government organisations. These domains include:
    • *.gsi.gov.uk
    • *.gsx.gov.uk
    • *.gse.gov.uk
    • *.gcsx.gov.uk
    • those on the whitelist
    • any other contacts that support TLS, such as commercial partners or suppliers
  3. Do not create a rule to enforce TLS to *.gov.uk as several domains aren’t yet able to support it.
  4. Follow NCSC guidance on TLS to ensure you use a strong TLS cipher suite and choose an appropriate certificate authority (CA). Your certificates must use a common name (CN) or subject alternative name (SAN) that matches the relay hostnames. Cloud-based email services include managed TLS certificates. If you operate an internet-facing email service you must buy and manage appropriate TLS certificates from the Digital Marketplace.
  5. Enable opportunistic TLS by default for domains not included in the mandatory TLS rules created above. You can use self-signed certificates for opportunistic TLS.
  6. Show you have outbound TLS available and are DKIM signing email by either:
    1. Creating an email address (for example emailsecurity@yourdomain.gov.uk) for each of your email domains. Create a rule or filter for this address so that if it receives an email from emailsecurity@domaininformation.service.gov.uk it will reply automatically. The content of the reply doesn’t matter, but it must come from the domain to which the original email was sent. Auto-replies should only be sent to this address. Tell us the email address you have created for each domain using this form.
    2. Sending an email to emailsecurity@domaininformation.service.gov.uk on a schedule (for example using a cron or Windows Scheduled Task) every day from each domain you’re responsible for. The email must have the correct sender information to make sure it is processed correctly.

Anti-spoofing

To prevent email spoofing you must put technical and business policies in place to check inbound and outbound government email using DMARC.

  1. Implement DMARC by:
    • publishing a DMARC record starting at p=none rising to p=quarantine during implementation
    • enabling inbound checking on your email service - this is usually the default setting
  2. Implement Sender Policy Framework (SPF) by publishing public DNS records for SPF, including all systems that send email, using a minimum soft fail (~all) qualifier.
  3. Implement DKIM by:
    • publishing DKIM selector and policy records
    • signing outgoing email in accordance with the DKIM standard
    • disabling outbound email footers if you have an outbound email filtering service
  4. Have matching forward and reverse (A and PTR) DNS records for the sending hostname.

Assessment

The domain information tool checks that you have encryption and anti-spoofing configured. You must get assurance that your email service is configured to ensure your email service is configured and run in a secure way. The assessment checks your domains and aspects of your infrastructure such as end user device management and your user authentication. Complete the assessment form.

Use this form to ask us questions about the assessment process.

Configure PSN-based email services

Encryption

Organisations with email services connected to the Public Services Network (PSN) use it to mitigate threats to email security. The PSN email gateway uses a TLS connection over the internet with other organisations that support it. Providers of PSN-based email services should:

  • use opportunistic TLS for secure email transport within the PSN - this does not require CA signed certificates
  • publish mail exchanger (MX) records in their public DNS for all email domains classified Official, so people outside the PSN can email them securely

Anti-spoofing

  1. Implement DMARC by:
    • publishing a DMARC record in your public DNS record, starting at p=none rising to p=quarantine during implementation
    • enabling inbound DMARC checking in the PSN email filtering portal
  2. Implement Sender Policy Framework (SPF) by:
    • publishing an SPF record in your public DNS record, including all systems that send email, using a minimum soft fail (~all) qualifier
    • enabling inbound SPF checking in the PSN email filtering portal
    • including the MessageLabs email filtering service in your SPF records so that internet-based recipients can see the origin of incoming emails - to do this, add include:spf.messagelabs.com to your SPF record
  3. Implement DKIM by:
    • publishing DKIM selector and policy records
    • signing outgoing email in accordance with the DKIM standard on all systems that send email
    • disabling outbound email footers in the PSN email filtering portal - this is usually the default setting
  4. Have matching forward and reverse (A and PTR) public DNS records for your sending hostname.

Assessment

Pass a PSN Code of Connection assessment to ensure your email service is configured and run in a secure way.

Configure a PSN-based email service that connects directly to the internet

Follow the guidance in this section if you have chosen to change your PSN-based email service to send email directly to the internet rather than using a PSN-based email relay and gateway.

Encryption

Follow these steps to encrypt email services:

  1. Use TLS version 1.2 or later and preferred cryptographic profiles for secure email transport between UK government departments.
  2. Create rules to use mandatory TLS when exchanging emails with government organisations. These domains include:
    • *.gsi.gov.uk
    • *.gsx.gov.uk
    • *.gse.gov.uk
    • *.gcsx.gov.uk
    • those included on the whitelist
    • any other contacts that support TLS, such as commercial partners or suppliers
  3. Do not create a rule to enforce TLS to *.gov.uk as several domains aren’t yet able to support it.
  4. Follow NCSC guidance on TLS to ensure you use a strong TLS cipher suite and choose an appropriate certificate authority (CA). Your certificates must use a common name (CN) or subject alternative name (SAN) that matches the relay hostnames. Buy and manage appropriate TLS certificates from the Digital Marketplace.
  5. Enable opportunistic TLS by default for domains not included in the mandatory TLS rules created above. You can use self-signed certificates for opportunistic TLS.
  6. Show you have outbound TLS available and are DKIM signing email by either:
    1. Creating an email address (for example emailsecurity@yourdomain.gov.uk) for each of your email domains. Create a rule or filter for this address so that if it receives an email from emailsecurity@domaininformation.service.gov.uk it will reply automatically. The content of the reply doesn’t matter, but it must come from the domain to which the original email was sent. Auto-replies should only be sent to this address. Tell us the email address you have created for each domain by using this form.
    2. Sending an email to emailsecurity@domaininformation.service.gov.uk on a schedule (for example using a cron or Windows Scheduled Task) every day from each domain you’re responsible for. The email must have the correct sender information to make sure it is processed correctly.

If you’re using a cloud-based email filtering service you must:

  1. Use TLS version 1.2 or later and preferred cryptographic profiles between your email servers and the email filtering service.
  2. Configure the above rules for mandatory TLS in the email filtering service.

If you haven’t already you must also publish mail exchanger (MX) records in your public DNS for all your email domains classified Official.

Anti-spoofing

To prevent email spoofing you must put technical and business policies in place to check inbound and outbound government email using DMARC.

  1. Implement DMARC by:
    • publishing a DMARC record in your public DNS record, starting at p=none rising to p=quarantine during implementation
    • enabling inbound DMARC checking in the PSN email filtering portal
  2. Implement Sender Policy Framework (SPF) by:
    • publishing an SPF record in your public DNS record, including all systems that send email, using a minimum soft fail (~all) qualifier
    • enabling inbound SPF checking in the PSN email filtering portal
    • including the MessageLabs email filtering service in your SPF records so that internet-based recipients can see the origin of incoming emails - to do this, add include:spf.messagelabs.com to your SPF record
  3. Implement DKIM by:
    • publishing DKIM selector and policy records
    • signing outgoing email in accordance with the DKIM standard on all systems that send email
    • disabling outbound email footers in the PSN email filtering portal - this is usually the default setting
  4. Have matching forward and reverse (A and PTR) public DNS records for your sending hostname.

Assessment

If your email service has already passed a PSN Code of Connection assessment you still need to tell us about the changes but the GDS information assurance team will not need to check your environment.

Complete the assessment form.

Use this form to ask us questions about the assessment process.

Configure other email sending services

Automated email sending services include:

  • services that send transactional email, triggered by actions in line-of-business applications or other services
  • email filtering services that send or manage email

These may sit inside or outside your network, and may use the same domain name as your users, or a subdomain.

Encryption

Use TLS version 1.2 or later for secure email transport between UK government departments.

Anti-spoofing

  1. Include additional email sending services in your DMARC and Sender Policy Framework records.
  2. Use DKIM signing. Use the same signature as your other email if you send them from the same domain.
  3. Ask your service provider for information about applying DKIM signatures and including email sending services in your SPF record.

Assessment

Sending services should support this guidance and be appropriately security assessed by your organisation. There is no central assessment process for these services.

Create and iterate DMARC records

Read the DMARC guide for more details on what it is and how it works.

Create a DMARC record

Check existing DNS

Check your current DNS records. Access them directly if you can or use the domain information tool. You can also check records with a service like mxtoolbox. It is useful to know which records exist before making changes or creating more.

If you have DKIM records you need to know the DKIM selector to find the record. Find the selector in the header of any email you send.

Create a DMARC record

Your initial DMARC record name is:

_dmarc

and the record value should be:

v=DMARC1;p=none;sp=none;fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@yourdomain.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk

Replace yourdomain.gov.uk with your actual domain, and make sure you have created an email address called ‘dmarc’ to receive the reports.

The dmarc.service.gov.uk entries are required for a compliant DMARC record.

This record won’t affect the delivery of your email, but it will provide you (and our central reporting service) with reports on where your email is coming from.

If you want to receive the reports in a different domain from the one you’re reporting on, add a TXT record to that domain as well. Name the record:

sending_domain.gov.uk._report._dmarc.recipient_domain.gov.uk

The record content is:

v=DMARC1

About 48 hours after publishing your records you’ll start receiving email reports from major email recipient domains.

The information in the reports show you where your email is coming from and how it is being handled by the major recipients.

Iterate a DMARC record

Once you have a week of reports you should be able to identify where your email is coming from.

The reports are in Extensible Markup Language (XML) and can be difficult to read. You can find service providers on the Digital Marketplace to help turn the reports into a meaningful dashboard, and to help with the implementation of DMARC.

This may require remedial action. You may have unauthorised internal services sending email inappropriately, or you may have discovered a third party spoofing your domain.

Use the information gathered to create and update your SPF record and add DKIM signing.

You should understand how subdomains are being used to send email, and update your record accordingly.

Once you’re confident you have an accurate SPF record and are DKIM signing outbound email, update your record to:

v=DMARC1;p=quarantine;sp=quarantine;fo=1;pct=10;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@yourdomain.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk

This instructs recipients to quarantine 10% of email from you that doesn’t pass DMARC checks. Start at 10% to ensure any mistakes don’t affect all email delivery. Gradually increase the percentage to 100 as you confirm genuine email is passing all checks.

It will also quarantine email from any subdomain (subdomain.yourdomain.gov.uk). This is important. If spammers see your primary domain is protected they may use subdomains instead.

Digital services must also have a DMARC record.

Create and manage DKIM

Read the guide on DKIM for more details on what it is and how it works.

It may be more difficult to implement DKIM on legacy email services. In this case, you should upgrade to a compatible cloud-based service and email filtering service to apply DKIM rather than adding cost and complexity to your existing environment.

Create a DKIM record and signing email

Generate the key

Creating and implementing a DKIM key varies from service to service. If you use a cloud-based email service your DKIM configuration will be automated to some extent. Look for a DKIM option in your administration panel or contact your service provider.

Follow NCSC guidance on TLS when creating a key to use to sign. Use a 1024-bit DKIM key. Any less may get rejected by larger email providers. DKIM may also fail if you use larger 2048-bit keys.

DKIM keys do not expire but you should rotate them periodically. Create a new key with a new selector and follow the same steps as above. Keep the old DNS record live for a few days after making changes to give the DNS time to update.

Create an entry in the public DNS record

Add the DKIM signature to a TXT record in your DNS record. This is made up of a selector (the name of your record), the version, the key type, and the public key itself. This allows the recipient to check the key on emails they receive from you against the key in your DNS. If they match this proves the message hasn’t been tampered with in transit.

Your DNS record should have the host or record name of:

selector._domainkey.yourdomain.gov.uk

and the value:

v=DKIM1, k-rsa, <your public key>

You can check this has been applied using a DKIM lookup service and your selector. The result should look like:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCG26OM/bk0vNm/TM2DnOQjPZNLIWspF4xtIX12LGHHjfushjsaudfysuf+DUigzM6h2oJMEdNt1S/CWVXW0pUBqfU0fzdw90+jyqOduh4cCnEk0z0w1w1j4xOYy0FLHhKoeoZJwWQFtwrlhrjxD6jM+sGeeRnbn2rQIDAQAB

Apply DKIM signatures to outbound email

This will vary depending on your email service. DKIM signatures may be applied by your filtering service rather than your email server. Ask your service provider for information specific to your service.

You must add DKIM signatures as the last step. This modifies the body of the email before the email is sent outbound. Add any standard disclaimers to the message before signing with DKIM. Read more information on how certain providers handle DKIM signatures.

PSN-based email users should check their Symantec.Cloud administration portal to ensure they are using the ‘no disclaimer’ option on outbound emails. If any disclaimer or other changes to the message are applied at this point the DKIM signature will be stripped.

Create and iterate SPF records

Read the guide on SPF for more details on what it is and how it works.

Create an SPF record

Create an SPF record in your public DNS using all the IP addresses or address ranges from which you send email. You can use both IPv4 and IPv6 addresses. A basic SPF record should look like:

v=spf1 include:_spf.google.com ~all

This record will allow email if it’s sent from google.com.

If you have other email sending services you need to add their domain or IP range to this record. This SPF record includes another sending service with an IP:

v=spf1 include:_spf.google.com ip4:80.88.21.0/20 ~all

When choosing services look for ones that can provide a sending domain or a stable IP range to make it easier to maintain your SPF record.

Make DNS changes

DMARC, DKIM and SPF require you to make changes to the DNS records for your domains. The table below shows who to contact to make those changes.

Record type Request changes from DNS host
*.gsi.gov.uk, *.gsx.gov.uk, *.gse.gov.uk, *.gcsx.gov.uk, *.x.gsi.gov.uk Contact GDS Contact GDS
*.gov.uk Your IT service provider JANET
any other domains Your IT service provider your DNS host

When requesting changes you must include specific information for each record. If given the option, set a short time to live (TTL) in DNS records so you can see changes quickly and fix issues.

DMARC

Record type: TXT

Host or record name: _dmarc

Record value: v=DMARC1;p=none;sp=none;fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@<yourdomain.gov.uk>;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk

Create the email address and put your domain in place of <yourdomain.gov.uk>.

SPF

Record type: TXT or CNAME (check guidance for your service on which to use)

Host or record name: @ (if required)

Record value: v=spf1 include:<your email server domain>ip4:<your service IP range(s)> ~all

Put your email server domains and/or email sending IP ranges in place of the <> sections.

DKIM

Record type: TXT

Host or record name: selector._domainkey

Put your selector, or the selector provider by your service provider, in place of selector in the host or record name.

Record value: v=DKIM1; k=rsa; p=<your DKIM key>

Paste your DKIM key from your key generator in place of <your DKIM key>

Communicate changes to your organisation

You can choose whether to communicate these changes to people in your organisation. It may be important to explain that this is a standard agreed across central government. Organisations implementing it are considered secure.

Speak to everyone in your organisation who develops or manages a service that sends email. Ensure that they share information about that service with you. Their service must do what is required to send email securely.

Use the whitelist

The domain information tool generates a whitelist of domains that have implemented this guidance. GDS does not require you to use the whitelist to limit in or outbound email. However, other organisations in government, such as data owners, may choose to do so.

The whitelist is available in the domain information tool and can be included in an automated process (for example, to maintain a filtering rule in your email service).

Email any questions about this guidance to secureemailguidance@digital.cabinet-office.gov.uk. ​​

Published 24 August 2016
Last updated 25 August 2016 + show all updates
  1. In this update, CTS has: * changed and removed wording throughout the document to make it easier to understand * added steps to make it clearer what you need to do to implement the guidance * added technical detail previously included in 'securing government email' * changed the document title in line with GDS style * restructured the document around the three aspects of encryption, anti-spoofing, and assessment * removed references to ADSP as it is no longer used widely enough to be valuable Aside from ADSP these updates have not changed the guidance, only the presentation.
  2. First published.