Detailed guide: Common Technology Services (CTS) guide to implementing the secure email blueprint

This document explains how to implement the secure email blueprint. It describes the process in general terms rather than for specific email services. If you need specific information about an email provider or application email contact.cts@digital.cabinet-office.gov.uk to request it or contact the vendor directly for advice.

In addition to this document the email monitoring tool will provide feedback to support your implementation.

Email service prerequisites

‘An email service’ describes any system sending emails on behalf of an organisation. This includes the email service providing users with mailbox access, internal relays and gateways, email filtering services, and third party services that send email on your behalf such as transactional email services.

An organisation implementing these changes needs an email service that can:

• have rules created that ensure emails are sent using TLS for certain domains
• use TLS opportunistically
• apply DKIM signatures to outbound messages
• auto-reply to inbound emails if required
• check DMARC on inbound email

They will also need:

• to be able to make administrative changes throughout their email service
• a public Domain Name System (DNS) record they can change to for each email domain they operate

PSN DNS records aren’t sufficient to provide email security with organisations using cloud-based email services.

Transport Layer Security (TLS)

Read our guide on TLS for more details on what it is and how it works.

Create TLS rules

Create rules to enforce TLS inbound and outbound for:

• *.gsi.gov.uk, *.gsx.gov.uk, *.gse.gov.uk, *.gcsx.gov.uk
• these domains that can receive email securely
• any other contacts that are known to support TLS such as commercial partners or suppliers

TLS should be 1.2 (although it is not always possible to enforce this) and use only ciphers marked as good. Do not create a rule to enforce TLS to *.gov.uk as a number of domains aren’t yet able to support it.

Do not rely on the recipient to force the TLS connection.

Cloud-based or PSN-based email services will have their TLS certificates created and managed on their behalf. If you are operating an internet-facing email service you will need to procure and manage appropriate TLS certificates. Enable opportunistic TLS by default for all other email, including within the PSN if using a PSN-based email service.

Create an auto-reply

To ensure your email service is capable of sending and receiving email using TLS you must create an email address, eg 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 contents of the reply do not matter but it is important that the reply comes from the domain to which the message was sent.

This will be used to check outbound TLS and DKIM signing from each domain.

Domain-based Message Authentication, Reporting and Conformance (DMARC)

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

Check existing DNS

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

If you have DKIM records you need to know the DKIM selector to find the record. This can be found 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,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.

This record will not have any affect on the delivery of your email but 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 are reporting on you need to 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 will start receiving email reports from major email recipient domains. The reports are in 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.

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

Iterating your DMARC record

Once you have a week of reports you should be able to identify where your email is coming from. 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 where it isn’t present.

You should also understand how any subdomains are being used to send email.

Update your record to:

v=DMARC1;p=quarantine;sp=quarantine;fo=1;pct=10;rua=mailto:dmarc-rua@dmarc.service.gov.uk,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.

Non-email domains

Create a DMARC record for domains that do not send email.

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

This prevents any email being accepted from this domain.

Further reading

DMARC is an open protocol so while there is guidance above for the desired end state of a government domain there is nothing government specific about your implementation. You can use web-based sources of information to help you with your implementation, such as:

• the Internet Engineering Task Force
• Kitterman Technical Services
• Google support
• DMARC.org

DomainKeys Identified Mail (DKIM)

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

Generate the key

Creation and implementation of a DKIM key varies extensively 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 search for

‘configure DKIM in <service name>’

Follow CESG 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 should be rotated 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 DNS time to update.

Create entry in public DNS record

Add the DKIM signature to a TXT record in your DNS record, which 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 email 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 test 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

You can also check your configuration in the domain page of the email monitoring tool. You need to setup the auto-reply described in the DMARC section or send an email to emailsecurity@digital.cabinet-office.gov.uk for the DKIM key to appear there.

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.

DKIM signatures must be added as the last step which modifies the body of the email before the email is sent outbound. Any standard disclaimers must be added to the message prior to the signing with DKIM. Read more information on how certain providers handle DKIM signatures.

PSN-based email users should check their MessageLabs/Symantec 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 an ADSP record

An Author Domain Signing Practices (ADSP) record tells recipients if they should expect a DKIM signature to be in place. For each domain where you know a DKIM signature will appear publish a TXT record with the name:

_adsp._domainkey

and the value:

dkim=discardable

Non-email domains

No DKIM record is required but you could publish an ADSP record to further prevent misuse of the domain.

Use the same record as above.

Further reading

DKIM is an open protocol so while there is guidance above for the desired end state of a government domain there is nothing government specific about your implementation. For help you with your implementation read:

• The importance of rotating your DKIM keys
• Explaining DKIM to your grandmother
• Generating DKIM keys

Sender Policy Framework (SPF)

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

Creating 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 mx include:_spf.google.com ~all

This record will allow mail if the sending IP is one of the hosts listed in your MX record, plus mail from google.com.

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

v=spf1 mx 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.

Non-email domains

Create an SPF record for domains that do not send email.

v=spf1 -all

This prevents any email being accepted from this domain.

Other email sending services

Most of your email may be sent by a person to another person or group. You may also have services that send transactional email triggered by actions in line of business applications or other services. You may also have mail 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 sub domain. For example, a PSN-based email service will need to include the MessageLabs email filtering service in their SPF records, as this is where internet-based recipients will see their email originating. To do this you would need to have

include:spf.messagelabs.com

included in your SPF record.

Any service sending email from your domain needs to be included in your SPF records and apply DKIM signatures to outbound email. It should also send email using TLS.

Ask your service provider for information about applying DKIM signatures and including email sending services in your SPF record.

Making DNS changes

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

When requesting changes you will need to include specific information for each record. When making requests using the Vodafone change request form you may need to put TXT changes in the MX field and note that it should be a TXT change. If given the option set a short Time To Live (TTLs) in DNS records so you can see changes quickly and fix issues.

DMARC

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

SPF

*Check guidance for your service on which to use. **Put your email server domain(s) and/or email sending IP ranges in place of the <> sections above.

DKIM

*Put your selector, or the selector provider by your service provider in place of ‘selector’ in the host or record name. **Paste your DKIM key in from your key generator.

ADSP

Communicating these 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 and organisations implementing it should be considered secure.

You should communicate to anyone in your organisation who may develop or manage a service that sends email that they need to share information about that service with you and that their service must do what is required to send email safely.

Assurance

CTS will monitor the implementation of secure email across government using a monitoring tool and a manual audit process.

Monitoring tool

The email monitoring tool checks that:

• TLS is enabled in and outbound from your email domains
• you have published records for DMARC, SPF, DKIM, and ADSP

It uses this information to:

• provide you with a dashboard for your organisation and your domains
• let you check whether an email sent between two domains is likely to be secure

It contains two whitelists:

1. Domains known to accept secure inbound connections.
2. Domains that are able to send in a secure and verifiable manner.

Manual checks

Organisations will be asked to provide evidence to the Government Technology Information Assurance team that the:

• secure email guidance has been implemented
• email service is run in a secure way

An Email Assurance Standard will be published soon requiring email services not based on the PSN but considered secure to meet similar standards as found in the PSN Code of Connection IA requirements. Cloud-based services should be administered according to CESG guidance for securing cloud services at OFFICIAL.