Turn on hosted S/MIME for message encryption

Supported editions for this feature: Frontline Plus; Enterprise Plus; Education Fundamentals, Education Standard, Teaching and Learning Upgrade, and Education Plus. Compare your edition

You can set up hosted Secure/Multipurpose Internet Mail Extensions (S/MIME) in your Google Admin console to help protect your people in your organization from phishing, harmful attachments, and other email threats. S/MIME improves email security by encrypting and adding a digital signature to messages. Messages are decrypted using the combination of a public key and a private key

When S/MIME is hosted, the organization using S/MIME for encryption stores the private key. Google Workspace Client-side encryption (CSE) also lets users send and receive encrypted S/MIME messages. But with CSE, private keys are managed by an external key service for increased privacy and data protection. Learn more about CSE.

You can also customize some Gmail settings to require S/MIME for certain messages. Learn more

Step 1: Turn on hosted S/MIME in your Google Admin console

Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
Go to Menu Apps > Google Workspace > Gmail > User settings.
Requires having the Gmail Settings administrator privilege.
On the left, under Organizations, select the domain or organization you want to configure.
Important: To use advanced S/MIME controls to upload and manage root certificates, you must enable S/MIME at the top-level organization, typically your domain. Learn more about S/MIME and root certificates.
Scroll to the S/MIME setting and check the Enable S/MIME encryption for sending and receiving emails box.
(Optional) To let people in your organization upload certificates, check the Allow users to upload their own certificates box.
(Optional additional controls) To upload and manage root certificates:
1. Next to Accept these additional Root Certificates for specific domains, click Add.
2. In the Add root certificate window, click Upload Root Certificate.
3. Browse to select the certificate file and click Open. A verification message appears for the certificate. This message includes the subject name and expiration.
4. Under Encryption level, select the encryption level to use with this certificate.
5. Under Address list, enter at least one domain that will use the root certificate when communicating. Separate multiple domains with commas. Domain names can include wildcards. To learn more about using wildcards in domain names, refer to RFC 6125.
6. (Optional) To allow CSE keypairs with certificates associated with an email address other than a user's primary email address, select the certificate mismatch option (For these domains allow certificates with email addresses that don't match users current email address).
  For security reasons, this option is recommended only when required by your organization. This feature is supported with CSE. It's not supported with hosted S/MIME. To learn more about certificate mismatch, visit Manage trusted certificates for S/MIME.
7. Click Done.
8. Repeat these steps to upload more certificate chains.
If your domain or organization must use Secure Hash Algorithm 1 (SHA-1), check the Allow SHA-1 globally (not recommended) box. To learn more about using SHA-1, visit Manage trusted certificates for S/MIME.
Click Save.

Changes can take up to 24 hours but typically happen more quickly. Learn more Messages sent during this time aren't encrypted.

Step 2: Have your users reload Gmail

After you enable hosted S/MIME in your Google Admin console, tell your users to reload Gmail. A lock icon appears in the message subject. If the message is encrypted with hosted S/MIME, the lock is green.

Step 3: Upload certificates

To use hosted S/MIME encryption, S/MIME end-user certificates must be uploaded to Gmail. The certificate should meet current cryptographic standards and use the Public-Key Cryptography Standards (PKCS) #12 archive file format.

This list of trusted certificates provided and maintained by Google applies only to Gmail for S/MIME.

We recommend that admins upload certificates with the Gmail S/MIME API. You can also use the Gmail S/MIME API to manage tasks like viewing, deleting, and setting default user keys. Learn more about the Gmail S/MIME API.

You can also let users upload certificates in their Gmail settings:

Go to Gmail.
Choose Settings See all settings.
Select the Accounts tab.
Next to Send mail as, select Edit info.
The Edit email address and encryption settings window appears. If you don't have this option, contact your administrator.
Click Upload a personal certificate.
Select the certificate and click Open. You'll be prompted to enter a password for the certificate.
Enter the password and click Add certificate.

Step 4: Have your users exchange keys

To start exchanging S/MIME messages, your users need to exchange keys with message recipients in one of these ways:

Send an S/MIME signed message to recipients. The message is digitally signed and includes the user's public key. Recipients can use this public key to encrypt messages they send to the user.
Ask recipients to send them a message. When they receive the message, it’s signed with S/MIME. The key is automatically stored and available. Going forward, messages sent to the recipient are S/MIME-encrypted.

Override sub-organization S/MIME settings

By default, organizational units inherit S/MIME settings from the top-level organizational unit. You can optionally override the inherited S/MIME settings for organizational units. This feature is useful for disabling or customizing S/MIME settings for organizational units.

To override S/MIME settings:

Sign in with an administrator account to the Google Admin console.
If you aren’t using an administrator account, you can’t access the Admin console.
Go to Menu Apps > Google Workspace > Gmail > User settings.
Requires having the Gmail Settings administrator privilege.
On the left, under Organizations, select the organizational unit you want to configure.
Scroll to the S/MIME setting, and click to expand it.
The label under the S/MIME setting label will indicate either Inherited from (organization or domain name), or Overridden.
Click Override to save changes to the sub-organization inheriting S/MIME settings.
After the sub-organization's settings are saved, Overridden is displayed under the S/MIME settings label. A dot also appears next to the overriding sub-organizations in the Organization Unit structure tree on the left.

Tip: If your sub-organization has overridden a higher level organization’s settings, you can use the Inherit button to inherit settings from the higher level organization.

Troubleshoot: Sub-organizations don't inherit S/MIME settings

Problem: Child organizational units don't inherit S/MIME settings from the root organizational unit.

Cause: The most common cause of this problem is that S/MIME was turned off for or modified for your entire organization (at the root level) after one or more organizational units added S/MIME settings using the override feature. Learn more about the S/MIME settings override feature

This issue can also happen when these S/MIME options are set at the child organizational level with the override feature: Enable S/MIME.., Allow users to upload their own certificates, or Allow SHA-1 globally. This is because these changes override the certificate settings for the root level.

Solution: To fix the problem and apply S/MIME inheritance to a child organizational unit:

In S/MIME settings, select the child organizational unit name on the left, under the S/MIME setting label.
Click Inherit to apply the root S/MIME settings to the child organizational unit
Reapply the child organizational unit’s settings:
1. Keep the child organizational unit selected on the left, under the S/MIME setting label.
2. Update the relevant S/MIME settings for the child organizational unit: Enable S/MIME.., Allow users to upload their own certificates, or Allow SHA-1 globally.
3. Click Override. This saves the child-specific settings while also ensuring the child inherits any past changes to root certificates or root-level S/MIME settings.

Repeat these steps for each affected child organizational unit.

Important: Every time you add or remove a root certificate, you must repeat these steps for all child organizational units where you want those changes to apply.

Was this helpful?

How can we improve it?