Set up government email services securely

Configure email services securely using encryption and anti-spoofing.

Government email administrators should follow this implementation guide to configure email services securely. It describes how to implement encryption and anti-spoofing to ensure your email service is configured and run in a secure way.

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.

Important: If you currently use a gsi-family domain name (, or you must replace it with a government domain like,, or by March 2019.

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

Configure cloud or internet-based email services

Encryption using Transport Layer Security (TLS)

TLS is an encryption protocol used to protect data in transit between computers. To encrypt email services use TLS version 1.2 or later, and preferred cryptographic profiles for secure email transport between UK government departments.

Create rules to use mandatory TLS when exchanging emails with government organisations. These domains include:

  • *
  • *
  • *
  • *
  • gsi-family email domains that have migrated to GOV.UK email domains any other contacts that support TLS, such as commercial partners or suppliers

Do not create a rule to enforce TLS to * as several domains don’t support it yet.

Follow NCSC guidance on TLS to make sure you are using a strong TLS cipher suite and 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.

You must enable opportunistic TLS by default for domains not included in the mandatory TLS rules. You can use self-signed certificates for opportunistic TLS. Show that you have outbound TLS available and are DKIM signing email by creating an email address (for example for each of your email domains.

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

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 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

Implement DKIM by:

  • publishing DKIM selector and policy records
  • signing outgoing email following the DKIM standard
  • disabling outbound email footers if you have an outbound email filtering service

Have matching forward and reverse (A and PTR) DNS records for the sending hostname.


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


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 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 to your SPF record

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

Have matching forward and reverse (A and PTR) public DNS records for your sending hostname.

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.


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


  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.

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. 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:


and the record value should be:


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

The entries are required for a valid 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:

The record content is:


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:


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 ( 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:

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 ~all

This record will allow email if it’s sent from

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 ip4: ~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
*, *, *, *, * Contact GDS Contact GDS
* 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.


Record type: TXT

Host or record name: _dmarc

Record value: v=DMARC1;p=none;sp=none;fo=1;,mailto:dmarc@<>;

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


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.


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.

Email any questions about this guidance to ​​

Published 24 August 2016
Last updated 18 April 2018 + show all updates
  1. The approach to email security is changing and we have removed the need to pass an assessment.
  2. Updated to reflect that GDS is no longer performing the whitelist check as email assurance is being handed over the NCSC, which uses the MailCheck tool.
  3. Updated to reflect changes to PSN.
  4. 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.
  5. First published.