Skip to main content

The design of government emails

We are starting to look at the design of emails that the government sends to users and what should be standardised in the service manual. It would be good to get feedback from service managers and designers about what would be appropriate for their services.

Many services use email as a way of providing confirmation of actions, account management, notification of changes and reminders. There are also email conversations between users and civil servants for support and casework.

Users need to be able to:

  • tell the email is from the government
  • tell if it's real
  • know why the government is contacting them
  • make it easy to know what to do next

Currently there are no standards for emails across government. Each email looks and sounds different, even within each department or service. Few look official.

We are looking at what elements of emails should be standardised across services. These will form part of the service manual. It would be good to get feedback from service managers and designers about what would be appropriate for their services. We've set up a page on our hackpad to show different examples.

HTML vs plain text

Most government emails are currently in plaintext (or HTML designed to look like plaintext), and this would have been the recommendation until recently. However it's now very rare for a commercial organisation to send plaintext emails and most email clients handle HTML emails well. We think HTML emails feel more 'real' to users and it's easier to look official. So we would recommend sending HTML emails containing a plaintext fallback. Images should be loaded from the web to stop the email containing attachments. Email clients do not currently handle webfonts well, so we would recommend using system standard sans-serif font stacks (Helvetica/Arial/sans-serif).

Headers and footers

HTML email allows more styling and a consistent look across emails. We have standardised headers and footers on service web pages and we're investigating doing the same for services.

Alex Torrance has been working on the HMRC Self Assessment service and has been testing emails that look like this:

Email design

We are thinking of standardising the GOV.UK header in emails to show some continuity across web and email. The department logo would be optional, depending on its use in the service.

Every email should have a footer indicating what to do if the user thinks the email is not real. We may add in a section about how to check if links are correct. The idea is to get emails from across government feeling the same, so fake emails are more obvious.

Links in emails

There are many security risks with getting users used to clicking links in emails, especially HTML emails. However, in user research, we've found telling people to go to GOV.UK by typing it into the browser bar, search for the service they are trying to use, and then log in is too confusing.

We're looking at allowing two links in emails from services; one to the service start page on GOV.UK, and when neccessary, one directly to the service to perform email address verification. In all cases, the link URLs would be written out in full.

Other links and text

No other links would be allowed. The text should be written to make it clear why they are being contacted and what they can do. There should be no extra text for marketing or social media.

Addressing the user

It is good to mention the user by name in emails - it provides extra reassurance that it is a real email. However, every service has different ways of storing user's names, so we wouldn't say it had to be by first name or last name only. Getting the tone of addressing users correct is hard.


Sharing and comments

Share this page


  1. Comment by Liam posted on

    It saddens me that this government design body think that using HTML emails, with headers and footers, is somehow more official looking than plain text. If they want to reassure citizens that emails are from the government and therefore "real", then why not sign the emails with PGP? More people should be using PGP and for the government to do so, could increase its usage across the population (I have never bought into the idea PGP is too difficult to general usage).

    • Replies to Liam>

      Comment by Chris Heathcote posted on


      We will look at PGP/MIME for signing and test it, but it needs to work in all major mail clients and not stop users from understanding what's going on.

      Thanks for the suggestion.

  2. Comment by Michael Mcwatters posted on

    Good suggestions, but no mention of making it responsive / mobile-friendly. We see a lot of mobile consumption of HTML emails; as such. Unfortunately, many HTML emails don't adjust font-size or layout accordingly, making them frustrating and increasing the likelihood they'll get trashed.

    • Replies to Michael Mcwatters>

      Comment by Chris Heathcote posted on

      A good point - we would make sure they work well on smaller screens, as we see several services getting close to 50% non-Computer usage.

  3. Comment by Ed Horsford posted on

    Right now start pages tend to be written for new users, not returning users. It would be good to think about those on a return journey are confident they're in the right place.

    Could an identifier be in the url? Ie reference number, etc? It feels awkward to direct these users back to the email to get the number it could have passed on in the first place.

    • Replies to Ed Horsford>

      Comment by Ben Lovell posted on

      >Could an identifier be in the url? Ie reference number, etc?

      Is there any specific guidance around the inclusion of tokens in emailed URL(s)? This is something we'll need to tackle shortly at Pension Wise.

  4. Comment by Faye Churchill posted on

    This is a really good step forward.

    Phishing emails are a huge problem for HMRC (and probably other depts too) and phishers are quick to copy anything we do around email, making it much harder for a customer to identify whether this is genuine or not.

    We're using SPF and DKIM to help ensure our emails get through to the customer (and others pretending to be us don't) would you recommend this too?

  5. Comment by Lewis posted on

    Do you have any plans to standardise e-mail signatures? and any thoughts on bi-lingual?