Guidance

Google Apps for Work Security Guidance: Email

Published 2 November 2015

This guidance was withdrawn on

This content has been moved to the CESG website: https://www.cesg.gov.uk/cloud-guidance

© Crown copyright 2015

This publication is licensed under the terms of the Open Government Licence v3.0 except where otherwise stated. To view this licence, visit nationalarchives.gov.uk/doc/open-government-licence/version/3 or write to the Information Policy Team, The National Archives, Kew, London TW9 4DU, or email: psi@nationalarchives.gov.uk.

Where we have identified any third party copyright information you will need to obtain permission from the copyright holders concerned.

This publication is available at https://www.gov.uk/government/publications/google-apps-for-work-security-guidance/google-apps-for-work-security-guidance-email

This document gives deployment security considerations when configuring email with Gmail as part of the Google Apps for Work (GAFW) web service. The secure configuration of this cloud hosted service aligns with government’s guidance on implementing the Cloud Security Principles. Please send any feedback you may have to enquiries@cesg.gsi.gov.uk.

1. Protecting email

The encryption of email at rest (for example, hosted by on-premise enterprise servers) and in transit (for example to a cloud service) ensures secure delivery, maintaining both data integrity and confidentiality.

2. Transport Layer Security

CESG recommend that email sent between Government departments and certain third parties should be encrypted in transit. It is good practice to use end-to-end Transport Layer Security (TLS) to do this. GAFW should be configured so that:

  • inbound email servers requesting an encrypted connection are supported
  • outbound email to specified servers is always sent encrypted
  • TLS is enforced where possible as the default encryption method
  • where supported, email sent to third parties uses encryption
  • certificate pinning is enabled where high confidence is required in sending email to a known recipient organisation
  • email is routed through any third party cloud services (for example, an email scanner) via both inbound and outbound connections to the service
  • any third party email services used are configured to encrypt email

Email from Google users to other Google users is encrypted while in transit to include Gmail, Google Apps and notifications sent from Google+. Gmail offers secure transport (TLS) compliance, an option that requires mail is transmitted via TLS when sent to specified domains and email addresses. This setting can be found in the Google Admin Console (GAC) under Google Apps | Settings for Gmail | Advanced settings | Compliance. Gmail-provided TLS has a number of routing properties worth noting:

  • TLS compliance applies to all users in an Organisational Unit (OU). Users within a child OU inherit the settings assigned to the parent organisation. For more on OUs, CESG have produced deployment security guidance Google Apps for Work: Administrator Good Practice.
  • TLS can be configured for both inbound and outbound email. If TLS is not available at a specified domain, inbound email will be rejected and outbound email will not be transmitted.
  • The option Outbound - messages requiring Secure Transport via another setting can be configured for outbound email to which another secure connection setting applies. For example:
    • outbound email may have already been routed through a secure connection
    • an Alternate secure route has been defined for outbound email (see below)
  • A list of domains for which secure delivery via TLS is necessary can be populated
    • CESG recommend that a CA signed certificate is required when delivering outbound email to the populated list of TLS enabled domains.
  • If a third party encryption service is used and unencrypted traffic needs to be routed to it (or a secure route for the domain has not been listed in the Secure transport (TLS) compliance settings) it is possible to route email via an Alternative secure route. This setting alters the routing behaviour set in the secure transport (TLS) compliance setting.
  • If an outbound gateway server has been defined to accept TLS, outbound email sent to domains that do not support TLS (but are on the list of TLS enabled domains) will not be rejected.

3. Email flow

Gmail is designed to host all of an enterprise’s email. This means that all email to the enterprise’s domain name will be hosted by Google. If an enterprise also hosts a separate on-premise email system, users will be able to determine which service is in use by looking at the domain stated in the email address.

4. Gmail routing

By default, GAFW email servers deliver incoming email to the Gmail inboxes of an enterprise’s users. If email is addressed to a user not registered in a GAFW enterprise’s domain, this email will be discarded. Google call this configuration direct delivery. Other delivery options provided by Gmail (referenced in the guidance below) give Google access to email content as it is being routed, meaning that Google must be trusted to handle that data. If it is important for some email not to flow through GAFW, necessary routing decisions must be made earlier in the email flows.

Routing settings can be accessed from the GAC by various means and under Google Apps | Settings for Gmail | Advanced settings | Routing. Gmail affords a number of routing options which comprise:

  • Default routing allows a domain-wide routing policy to be set up (only applies to inbound email). If an on-premise email server is used, this routing option can establish split delivery to route unregistered Google Apps users to the on-premise email server.
  • Receiving routing can be used to route inbound email to both Gmail and also to an external server using dual delivery. Split delivery can also be used to route email to different email hosts (eg a Microsoft Exchange) dependent upon the recipient’s OU.
  • Sending routing allows an outbound email gateway to be set up and through which all of a domain’s sent email passes. This routing can implement dual delivery for an OU where outbound email is delivered to recipients and also to an external email archive.

These rules can be applied to all users, or optionally configured per OU:

5. Gmail gateways and third-party email services

An administrator of GAFW Gmail can configure inbound and outbound email gateway servers to integrate with third party email services. For mail scanning, this should be done in line with an enterprise’s existing email scanning policies, to filter email and to protect users (and those they communicate with) from spam, viruses, phishing attacks and data loss.

It is possible to use a third party cloud service in addition to Google’s own Gmail scanning services.The third party service can provide scanning of:

  • inbound traffic to limit the risk of unsolicited and harmful email reaching user mailboxes
  • outbound traffic to ensure that viruses are not sent from an enterprise’s network while also reducing the possibility for exploitation of an enterprise’s email domains by malicious actors (for example, spoof email masquerading as being sent from the enterprise)

Configuring gateways and third party services will be most effective when:

  • SMTP traffic has been restricted to the service’s cloud server IP ranges. Limiting traffic to between the enterprise’s internet gateway and the cloud will help prevent spam and viruses being sent directly to or from the enterprise email servers and which bypass the cloud service.
  • Enterprise SMTP servers are not using third party/open relay services. Open relay email servers can accept email from any domain and forward it to another sender without verification. It is exploitable by malicious actors and presents a security risk that should be mitigated.
  • email protection to the cloud service has been ensured by secure delivery and where possible, TLS has been enforced to only deliver email when a secure connection can be established with the recipient

Alternatively it is possible to use Google itself as an email scanner via its SMTP relay service. Outgoing email from an on-premise email service can be filtered by Google for malicious content before reaching external contacts. Google Apps email security settings will also be applied to the outgoing email.

6. MX records

MX records will need to be reconfigured when changing email providers or redirecting email to a remote server. When handling MX records it is worth noting that:

  • Google offer both generic and host-specific advice on how to set up MX records
  • care should be taken when changing MX records in administrative settings to ensure that email is routed via known and trusted parties
  • if an external organisation manages an enterprise’s MX records, they should be made aware of any intended changes to email services in a timely manner; this will avoid denial of service scenarios for an enterprise’s email users should problems arise during deployment
  • 72 hours should be allowed for MX record changes to fully propagate across the Internet and deployments staged accordingly

7. Gmail settings

An administrator using the GAC can control how an enterprise’s users make use of Gmail. Under Admin Console | Google Apps | Settings for Gmail | Advanced settings, the configuration of a number of these controls can be made, some of which are addressed here. This is not a comprehensive list and other settings might need to be considered in compliance with an enterprise’s information handling policies.

7.1 General Settings | End User Access

  • Disable Google Apps Sync and Google Apps Connector if support for Microsoft Outlook and BlackBerry Enterprise Server is not to be provided.
  • Disable Automatic Forwarding to prevent users from automatically forwarding their incoming email to another address. Any existing forwarding rules or filters will no longer forward email.
  • Disable Allow per-user outbound gateways by un-checking the box Allow users to send mail through an external SMTP server when configuring a "from" address hosted outside your email domains. This will prevent users from sending mail through an external email server, which would allow email to bypass the enterprise’s outbound email gateway. Google document further information on outbound gateways and outbound relays.
  • CESG recommend enabling Google’s Image Proxy service as this makes anti-phishing mitigations more effective. An Image URL proxy whitelist may need to be populated and enabled to support images from internal websites.

7.2 General Settings | Spam

  • To improve spam handling, the Inbound gateway field should be populated with the IP addresses of email servers that route incoming email to Gmail. To only receive email from the inbound gateway and to prevent unsolicited and unwanted email delivery, MX records should point to the gateway IP address. The option to Only let users receive email from the email gateways listed above should then be enabled.

7.3 General Settings | Compliance

  • The Comprehensive mail storage setting safeguards a copy of all sent or received email in a domain (including email passed by non-Gmail mailboxes), storing it in the users’ Gmail mailboxes.
    • The routing of mail to non-Gmail servers with this setting enabled ensures storage of email in Gmail mailboxes for Google Apps Vault archiving.
    • This setting should be enabled when a non-Gmail system uses the SMTP Relay Service to route email for an enterprise’s users (for example, automated notification systems) to their Gmail mailboxes.
  • To only allow the sending or receiving of email from specified addresses or domains, the Restrict delivery option allows a list of recipients to be populated that an enterprise’s users are authorised to exchange email with (for example, only sending email to other Government departments).
Back to top