Skip to main content
    My-SSL LogoMy-SSL
    Guides

    How to Set Up S/MIME in Google Workspace (Gmail)

    Hosted S/MIME needs a supported Workspace edition, a root Gmail trusts, and one of three ways to load user certificates. Which path applies to you.

    MS
    My-SSL Team
    ·
    14 min read
    ·
    Published August 12, 2026
    ·
    Last updated August 12, 2026

    The short answer

    Setting up S/MIME in Google Workspace is four gates, not one procedure. As of August 2026, hosted S/MIME is offered on Frontline Plus, Enterprise Plus, and Education Fundamentals, Standard and Plus — Business Starter, Standard and Plus do not include it, and personal @gmail.com accounts never have. An administrator then enables it under Apps → Google Workspace → Gmail → User settings, confirms Gmail trusts the issuing certificate authority, and loads each user's certificate one of three ways: users uploading their own PKCS#12 file, an administrator pushing them through the Gmail API, or client-side encryption backed by an external key service. Changes can take up to 24 hours to apply.

    The four gates of a Google Workspace S/MIME setup, in order, and the two gates where most deployments stallA left-to-right sequence of four gates. Gate one is the edition check: hosted S/MIME is available on Frontline Plus, Enterprise Plus, and the Education Fundamentals, Standard and Plus editions, and a branch below shows that Business Starter, Standard and Plus, along with personal Gmail accounts, stop here because the feature is not offered. Gate two is enabling S/MIME in the Admin console under Apps, Google Workspace, Gmail, User settings. Gate three, highlighted in gold, is the trust check: if the certificate chains to a root Gmail already trusts, no upload is needed, and only a private or internal CA requires uploading a root at the top-level organizational unit. Gate four, also highlighted in gold, is certificate delivery, with three routes: each user uploading their own PKCS#12 file, an administrator pushing certificates through the Gmail API, or client-side encryption using an external key service. A note underneath records that changes can take up to 24 hours to apply.Four gates, in order — and only two of them are workGATE 1 — EDITIONIs it offered?Frontline PlusEnterprise PlusEducation F / S / PGATE 2 — ENABLEOne checkboxApps → Google Workspace→ Gmail → User settingsper organizational unitGATE 3 — TRUSTPublic CA?Yes → nothing to doPrivate CA → uploadroot at top-level OUGATE 4 — CERTSLoad themthree routes,one per teamsizeSTOPS HERE — NOT AVAILABLEBusiness Starter / Standard / Plus · personal GmailGate 4 in detail: pick the route that matches how many mailboxes you haveA FEW PEOPLEEach user uploads their own.p12 / .pfx + passwordGmail settings → AccountsA WHOLE DOMAINAdmin pushes via Gmail APIsmimeInfo.insert (PKCS#12)no bulk upload in the consoleGOOGLE MUST NOT READ ITClient-side encryptionexternal key service holdsthe private keysEvery change on this diagram can take up to 24 hours to apply — wait it out before you start debugging.
    Gates 1 and 2 take about five minutes between them. Almost every setup that goes wrong went wrong at gate 3 or gate 4, which is where the Google documentation splits into separate pages.

    Google documents this across four separate help pages — turning the feature on, managing trusted roots, certificate profiles, and the Gmail API. Read end to end they describe one project, but each page assumes you have already answered a question raised on another. What follows puts them in the order you actually hit them, and flags the two points where a setup stalls without telling you why.

    Which Workspace editions can turn S/MIME on?

    As of August 2026, hosted S/MIME is available on Google Workspace Frontline Plus and Enterprise Plus, and on Education Fundamentals, Education Standard and Education Plus. It is not included with Business Starter, Business Standard or Business Plus, and it does not exist for personal @gmail.com accounts, which have no Admin console behind them. If the setting is absent from your console, the edition is the first thing to check — nothing else on this page will make it appear.

    The Business Plus assumption is worth calling out because it costs real money. It is a paid, mid-tier plan whose name suggests the full feature set, and organisations occasionally buy S/MIME certificates for staff before discovering the mailboxes cannot load them. Certificates are issued to a person and an address rather than to a platform, so they are not wasted — they will work in Outlook, Apple Mail or Thunderbird against the same mailbox — but Gmail's own S/MIME will stay switched off until the edition changes.

    Edition names and inclusions change more often than the underlying feature does. Before committing to a plan on the strength of this one capability, confirm the current list in Google's own documentation on the day you buy.

    Hosted S/MIME or client-side encryption?

    Choose based on one question: must Google be unable to read the message content? With hosted S/MIME, Google stores the private key and can process the message on its servers, which is what keeps server-side search and filtering working normally. With Gmail client-side encryption, the keys come from an external key service you control, so Google cannot decrypt the content — at the cost of running that key service, wiring up an identity provider, and doing per-user API work. For most organisations the answer is hosted S/MIME.

    Hosted S/MIME compared with Gmail client-side encryption across four practical differencesA two-column comparison. Hosted S/MIME: Google stores the private key; setup is an Admin console checkbox plus certificate loading; server-side features such as search and spam filtering continue to work on message content; and external recipients need only ordinary S/MIME. Client-side encryption: the private keys are held by an external key service you control, highlighted in gold as the deciding difference, meaning Google cannot decrypt the content; setup additionally requires a key service, an identity provider and per-user Gmail API work. The closing line states the decision rule: choose client-side encryption only when a requirement says the provider must not be able to read the message, and hosted S/MIME otherwise.Two different products with similar namesHosted S/MIMEClient-side encryption (CSE)WHO HOLDS THE PRIVATE KEYGoogle stores itWHO HOLDS THE PRIVATE KEYAn external key service you controlCAN GOOGLE DECRYPT CONTENTYes — that is what keeps search workingCAN GOOGLE DECRYPT CONTENTNoWHAT SETUP COSTS YOUA checkbox, then load certificatesWHAT SETUP COSTS YOUKey service + IdP + per-user API workThe decision rulePick CSE only when a rule says the provider must not be able to read the mail. Otherwise hosted S/MIME is the proportionate answer.
    Both appear under Gmail security settings, which is why teams sometimes build the harder one by accident. The private-key row is the only difference that should drive the choice.

    Both appear under Gmail's security settings, and the names are close enough that teams sometimes start building the harder one by accident. Client-side encryption earns its complexity when a regulator, a contract, or an internal policy specifically says the provider must not be able to access message content. Absent that, the extra machinery buys nothing an auditor will ask about, and hosted S/MIME gives you signatures and encryption in an afternoon.

    Turning on hosted S/MIME in the Admin console

    In the Google Admin console, go to Apps → Google Workspace → Gmail → User settings, select the organizational unit you want on the left, find the S/MIME setting, and tick Enable S/MIME encryption for sending and receiving emails. That single checkbox is the whole of gate two. One detail decides where you tick it: if you will ever need the advanced controls for uploading your own root certificates, S/MIME has to be enabled at the top-level organization, normally your domain.

    1. Open the Admin console and navigate to Apps → Google Workspace → Gmail → User settings.
    2. Under Organizations, select the org unit to configure — the top-level organization if you intend to manage trusted roots.
    3. Scroll to the S/MIME setting and enable S/MIME encryption for sending and receiving email.
    4. Save, then leave it alone. Changes can take up to 24 hours to apply, and testing inside the first few minutes produces misleading results.

    Enabling the setting does not encrypt anything by itself. It makes Gmail willing to use S/MIME once certificates exist, which is gate four. There is also a separate setting that requires S/MIME for outgoing messages to particular domains — useful once a deployment is stable, and a good way to generate support tickets if you turn it on before every mailbox has a working certificate.

    Does Gmail already trust your CA?

    Gmail carries a default set of trusted root certificate authorities, and a certificate from a widely trusted public CA is normally accepted with no upload at all. The advanced root controls exist for private and internal certificate authorities — an enterprise CA issuing certificates to staff, for instance. So the first move is not to upload anything: load one certificate, send one signed message, and see whether Gmail accepts it. If it does, gate three is already finished.

    The four rules a root certificate must satisfy before Gmail will accept it for hosted S/MIMEFour requirement cards. First, the file must be PEM format. Second, it must contain exactly one root certificate, not a bundle. Third, highlighted in gold, the chain must include at least one intermediate certificate authority, because Gmail rejects a root that issues end-entity certificates directly — this is the rule that most internal certificate authorities fail. Fourth, S/MIME must be enabled at the top-level organizational unit before the advanced root controls appear at all. A closing line notes that none of this applies when the certificate already chains to a root Gmail trusts by default.Uploading your own root: four rules, one of them surprisingRULE 1 — FORMAT.pemnot .der, not .p7bRULE 2 — CONTENTSone root onlyupload a bundle and it failsRULE 3 — THE CATCHneeds an intermediatea root that signs leafcertificates is rejectedRULE 4 — SCOPEtop-level OUenable S/MIME there orthe controls never appearBefore you do any of this, check whether you need toGmail ships with a default set of trusted root CAs. A certificate from a widely trusted public CA is normally accepted withno upload at all — the advanced controls exist for private and internal certificate authorities.
    Rule 3 is the one internal CAs trip over: a two-tier PKI built to keep things simple, with the root signing user certificates directly, is exactly the shape Gmail refuses.

    If you do need to upload, the requirements are narrow. The file must be PEM format and contain exactly one root certificate rather than a bundle, and the chain must include at least one intermediate CA — Gmail rejects a root that issues end-entity certificates directly. That last rule catches a lot of internal PKIs, because a two-tier design with the root signing user certificates is a common way to keep an in-house CA simple, and it is precisely the shape Gmail will not take. Rebuilding the hierarchy with a signing intermediate is the fix, and it is not a small change once certificates are already deployed.

    For most organisations this is an argument for using a public CA rather than running a private one. The certificates your staff need are ordinary publicly trusted S/MIME certificates, which already chain through an intermediate and are recognised by Outlook, Apple Mail and Thunderbird as well as Gmail — so recipients outside your domain can verify signatures without you distributing anything. Our S/MIME certificate buying guide covers how the validation levels differ.

    Three ways to get certificates onto accounts

    There are exactly three routes, and team size picks the one you want. Individual users can upload their own PKCS#12 file from Gmail's settings. An administrator can push certificates for the whole domain through the Gmail API. Or client-side encryption can supply keys from an external key service. The Admin console has no bulk certificate upload, which is the single fact that decides how a rollout past a handful of mailboxes has to be built.

    RouteWho does itWhat it takesSensible up to
    Self-uploadEach userA .p12 or .pfx file and its password, uploaded from Gmail settingsA team you can walk through it
    Gmail APIAdministratorsmimeInfo.insert per send-as address, PKCS#12 payload, service account with domain-wide delegationAny size — the only bulk option
    Client-side encryptionAdministratorExternal key service, identity provider, per-user API workOnly where Google must not hold keys

    Letting users upload their own certificate

    Once an administrator has enabled S/MIME for the org unit, a user opens Gmail settings, goes to the Accounts section, and chooses Upload a personal certificate. Certificate authorities deliver S/MIME certificates as a PKCS#12 bundle — a .p12 or .pfx file — protected by a password, and both the file and that password are needed here. Users who already installed the same certificate in Outlook or Apple Mail can reuse the identical file; one certificate covers every client for that address.

    Pushing certificates with the Gmail API

    For a domain-wide rollout the Gmail API is the only realistic route. The relevant call is users.settings.sendAs.smimeInfo.insert, which uploads an S/MIME configuration for one send-as address:

    POST https://gmail.googleapis.com/gmail/v1/users/{userId}/settings/sendAs/{sendAsEmail}/smimeInfo

    The key must be supplied in PKCS#12 format, and the call needs the gmail.settings.basic or gmail.settings.sharing scope — which in practice means a service account with domain-wide delegation, so it can act on behalf of each mailbox rather than asking every user to authorise it. The same resource offers list, get, delete and setDefault, and those matter more than the initial insert: setDefault picks which certificate an address signs with when a user holds several, and list is how you audit who is actually covered before switching on any requirement to encrypt.

    Budget for renewal in the same script. S/MIME certificates expire, usually well inside the lifetime of the mailbox, and a deployment built as a one-off migration tends to be rediscovered a year later when signatures start failing. If you are buying certificates for the domain, S/MIME certificates from My-SSL are issued by Certum as standard publicly trusted PKCS#12 bundles, which is the format both the self-upload flow and this API expect.

    Why encryption still fails after setup

    Because signing and encrypting need different things. Signing uses your own private key, so it works the moment your certificate is loaded. Encrypting uses the recipient's public certificate, so Gmail can only encrypt to people whose certificate it already holds — and it normally obtains that automatically from a signed message they sent you. Until that exchange has happened there is no key to encrypt with, and Gmail quietly delivers over ordinary TLS instead.

    Why Gmail can sign a message immediately but cannot encrypt one until the recipient's certificate has arrivedTwo contrasting rows. The upper row, signing, shows that your own certificate alone is enough: Gmail signs with your private key and the message goes out immediately. The lower row, encryption, is highlighted in gold and shows that two certificates are required — Gmail encrypts with the recipient's public certificate, which it only holds after that person has sent a signed message that Gmail stored. Until that happens, the message is delivered over ordinary TLS instead, with no lock shown in the compose window. A footer states the practical consequence: a new contact cannot be sent encrypted mail until they sign one message first.Signing needs one certificate. Encrypting needs two.SIGNING — works the moment your certificate is loadedyour certificateprivate key signssent, signedrecipient needs nothing…and this is also how the recipient'smail client learns your public certificate.ENCRYPTING — blocked until their certificate reaches youtheir certificatepublic key encryptslock shown in composemessage encrypted end to endWhere does their certificate come from?From a signed message they sent you.Gmail stores it and reuses it after that.NO CERTIFICATE ON FILE YET?Gmail delivers over ordinary TLS instead — nothing fails, nothing warns, and no lock appears.
    This is the report that usually arrives as "encryption isn't working on the new accounts". It is working; the two sides have simply never exchanged a signed message.

    Nothing warns you about this, which is why it arrives as a bug report rather than a question. The compose window shows a lock icon beside recipients Gmail can encrypt to; recipients without a stored certificate simply have no lock. The fix is unglamorous: have both sides send one signed message, then check the lock again. For a new external counterparty, that first signed exchange is a step in the process, not a fault to debug.

    What to check when it doesn't work

    Work down the four gates in order rather than starting with the certificate, because three of the four common failures are upstream of it. The setting missing entirely means the edition does not include hosted S/MIME. The advanced root controls missing means S/MIME was enabled below the top-level organization. A rejected root usually means the chain has no intermediate. And a setup that looks broken within the hour may simply not have propagated yet.

    • No S/MIME setting in the Admin console. Check the edition first. Business Starter, Standard and Plus do not include hosted S/MIME.
    • No option to upload root certificates. Enable S/MIME at the top-level organization; the advanced controls do not appear on a child org unit.
    • Root certificate rejected. Confirm PEM format, exactly one certificate in the file, and at least one intermediate in the chain below the root.
    • Certificate uploads but nothing signs. Give it time — changes can take up to 24 hours — then confirm the address on the certificate exactly matches the send-as address.
    • Signing works, encryption doesn't. Expected until the recipient's certificate has reached you in a signed message. Check for the lock icon in the compose window.
    • Upload fails on the file itself. Gmail wants a PKCS#12 bundle (.p12 or .pfx) with its password. A .cer or .pem file holds the certificate without the private key and cannot sign anything.

    If the same certificate needs to work in a desktop client too, the Outlook installation guide covers the equivalent steps there, and the same PKCS#12 file serves both.

    Frequently Asked Questions

    Get instant answers to common questions about SSL certificates and our services.

    Still Have Questions?

    Our SSL experts are available 24/7 to help with any questions about certificates, installation, or technical issues.

    Getting the certificates themselves

    Everything above assumes a certificate exists for each address. S/MIME email certificates from My-SSL are issued by Certum, a publicly trusted certificate authority, and arrive as password-protected PKCS#12 files — the format both the Gmail self-upload flow and the Gmail API take without conversion. If you are covering a whole domain, order for the send-as addresses you intend to sign from, since the address on the certificate has to match.

    Related reading