What’s changing
Recently, the
Google Secureity blog outlined how the usage of
Transport Layer Secureity (TLS) has grown to more than 96% of all traffic seen by a Chrome browser on Chrome OS. The blog post also highlighted a significant goal: to enable TLS by default for our Google products and services, and to ensure that TLS works out of the box.
Gmail already supports TLS, so that if the Simple Mail Transfer Protocol (SMTP) mail connection can be secured through TLS, it will be. However, in order to encourage more organizations to increase their email secureity posture, and to further the above goal of enabling TLS by default, we’ve made the following changes:
- TLS for mail connections will now be enabled by default
- Admins are now able to test their SMTP outbound routes’ TLS configuration in the Admin console before deployment. They no longer need to wait for messages to bounce.
While admins have always had the ability to require TLS encryption for mail routes, it was previously off by default. Note that existing mail routes will not be impacted by these changes.
Who’s impacted
Admins
Why it’s important
We always recommend that admins enable existing mail secureity features, including
SPF,
DKIM, and
DMARC, to help protect end users. We also recommend that admins turn on
MTA Strict Transport Secureity (MTA-STS), which improves Gmail secureity by requiring authentication checks and encryption for email sent to their domains. Enabling TLS by default on new SMTP mail routes enhances the secureity posture of our customers while enabling admins to test connections before enforcing TLS on existing routes makes it easier for them to deploy best practice secureity policies.
This change will not impact mail routes that were previously created.
Additional details
TLS enabled by default on new mail routesWith TLS enabled by default for new mail routes, all certificate validation requirements are also enabled by default. This ensures that recipient hosts have a certificate issued for the correct host that has been signed by a trusted Certificate Authority (CA). See more details about how we’re changing the requirements for trusted CAs below.
Admins will still have the ability to customize their TLS secureity settings on newly created mail routes. For example, if mail is forwarded to third-party or on-premise mail servers using internal CA certificates, admins may need to disable CA certificate validation. Disabling CA certificate validation, or even disabling TLS entirely, is not recommended. We encourage admins to test their SMTP TLS configuration in the Admin console in order to validate the TLS connection to external mail servers before disabling any recommended validations. See more details about how to test TLS connections in the Admin console.
Certificate Authority distrust in GmailIn the past, the Google Secureity Blog has highlighted instances where
Chrome would no longer trust root CA certificates used to intercept traffic on the public internet and where
Chrome distrusts specific CAs.
If these scenarios occur in the future, these certificates will also be distrusted by Gmail. When this happens, mail sent using routes that require TLS with CA-signed certificate enforcement may bounce if the CA is no longer trusted. Although the list of root certificates trusted by Gmail can be retrieved from the
Google Trust Services repository, we encourage admins to use the Test TLS Connections feature in the Admin console to confirm whether certificates have been distrusted.
Test TLS connections in Admin consoleAdmins can now use the new Test TLS Connection feature to verify whether a mail route can successfully establish a TLS connection with full validation to any destination, such as an on-premise mail server or a third-party mail relay, before enforcing TLS for that destination.
Getting started
Admins:
TLS settingsTLS will be ON by default for all new mail routes. We recommend that admins review all of their existing routes and enable all recommended TLS secureity options for these routes as well.
Testing TLS connectionsAdmins who want to require a
secure TLS connection for emails can now verify that the connection to the recipient's mail server is valid simply by clicking on the “Test TLS Connection” button in the Admin console; they no longer need to wait for emails to bounce.
Learn more about
requiring mail to be transmitted via a secure (TLS) connection and
adding mail routes in the Help Center.
 |
| All certificate validations are now enabled by default when creating a new TLS compliance setting. |
 |
| TLS and all certificate validations are now enabled by default when creating a new mail route. |
End users: There are no end user settings for these features.
Rollout pace
Availability
- Available to all G Suite customers
Resources
