S/MIME Email Encryption: Setup, Certificates and Compliance (2026)

S/MIME encryption is the most widely deployed way to add end-to-end confidentiality and verified sender identity to ordinary email. Built into Microsoft Outlook, Apple Mail and most enterprise clients, S/MIME encryption uses certificates issued by a trusted Certificate Authority to scramble a message so that only the intended recipient can read it — and to sign it so the recipient’s mail client can prove it really came from you. This guide to S/MIME email encryption explains what S/MIME encryption is, how it works, how to get a certificate, how to set it up across the major clients, and the real-world limits you need to plan for. It sits inside our email security hub and complements our broader email encryption guide.

What is S/MIME encryption?

S/MIME — Secure/Multipurpose Internet Mail Extensions — is a standard for signing and encrypting MIME email messages. The current version is S/MIME 4.0, defined in RFC 8551, with certificate handling specified in RFC 8550. It does two distinct jobs. Signing attaches a cryptographic signature that proves who sent a message and that it was not altered in transit — authentication, integrity and non-repudiation. Encryption scrambles the message body and attachments so that only the holder of the matching private key can read them — confidentiality. You can sign without encrypting, encrypt without signing, or, most commonly, do both at once.

The crucial thing to understand about S/MIME encryption is that it protects the message itself, not just the connection between servers. Ordinary transport encryption (TLS) protects email while it hops between mail servers, but the message sits in plaintext on every server along the way. S/MIME encryption keeps the content unreadable end to end, from your outbox to the recipient’s inbox.

How S/MIME encryption works

S/MIME encryption relies on public-key cryptography and X.509 certificates. Every user has a key pair: a public key, which others use to encrypt mail to you and to verify your signatures, and a private key, which you keep secret and use to decrypt incoming mail and to sign outgoing mail. A Certificate Authority (CA) issues an X.509 certificate that binds your email address — and optionally your verified name or organisation — to your public key, so recipients’ clients can trust it chains back to a root they already recognise.

In practice the flow looks like this. To send you an encrypted message, the sender’s client needs your public certificate; it usually obtains this the first time you send them a signed message, or from a corporate directory. The client generates a one-time symmetric session key, encrypts the message with it, then encrypts that session key with your public key. Only your private key can unwrap the session key and decrypt the content. RFC 8551 mandates modern algorithms for this — AES-GCM for content, and elliptic-curve options such as X25519 and Ed25519 alongside RSA — so a correctly configured S/MIME encryption setup is cryptographically strong.

Getting an S/MIME certificate

Because S/MIME uses a Certificate Authority model rather than the decentralised web of trust that PGP relies on, you obtain your certificate from a CA. Since September 2023 the CA/Browser Forum’s S/MIME Baseline Requirements have standardised what CAs may issue, defining four validation profiles:

Commercial CAs such as DigiCert, Sectigo, GlobalSign and IdenTrust sell S/MIME certificates, typically for a modest annual fee. Free, publicly-trusted options have thinned out — Actalis still offers a free mailbox-validated certificate at the time of writing, while some long-standing free issuers have been discontinued, so verify availability before relying on one. Newly issued certificates are now capped at 825 days of validity, so renewal is a recurring task. Certificates arrive as a password-protected PKCS#12 (.pfx or .p12) file containing both your certificate and private key, ready to import into your mail client or operating system keystore.

Setting up S/MIME encryption in your mail client

Client support is where S/MIME encryption shines, because it is built into the software most businesses already use:

• Microsoft Outlook — classic Outlook reads certificates from the Windows certificate store; configure under Trust Center → Email Security. The new Outlook for Windows requires manual certificate installation, and Outlook on the web (OWA) needs the Microsoft S/MIME browser extension pushed by an administrator, which in practice limits browser S/MIME encryption to managed Windows devices.
• Apple Mail (macOS & iOS) — import your .p12 via Keychain Access on macOS or a configuration profile on iOS, mark it trusted, and a sign/encrypt control appears in the compose window.
• Gmail — hosted S/MIME is available only on certain paid Google Workspace tiers (Enterprise and Education editions), enabled by an administrator; it is not available on consumer Gmail.
• Thunderbird — configure under Account Settings → End-to-End Encryption; Thunderbird needs a CA-issued personal certificate and can generate a signing request for you.

Once your certificate is installed, sending a signed message is usually a single toggle. Encryption requires that you already hold the recipient’s public certificate, which is why most workflows begin by exchanging signed mail. Use our free tools to confirm the authentication foundations your secure mail also depends on.

S/MIME encryption in the enterprise

At scale, S/MIME encryption is deployed centrally rather than user by user. On Windows domains, Active Directory Certificate Services can auto-enrol users through Group Policy and publish their public certificates to the directory so colleagues can encrypt to them automatically. Mobile device management platforms such as Microsoft Intune distribute the certificate to every device a user owns — and, importantly, push the user’s full history of encryption certificates, so that mail encrypted to an old key remains readable. The Global Address List acts as the lookup that lets a sender’s client find a recipient’s published public certificate.

Rolling out S/MIME email encryption across a workforce is a project, not a setting, so two enterprise practices matter most. First, separate the signing key from the encryption key, and escrow only the encryption key: archiving a Key Recovery Agent copy of the encryption key means lost mail can be recovered, while never escrowing the signing key preserves true non-repudiation. Second, plan certificate renewal and distribution as an ongoing process, because an expired certificate cannot encrypt new mail and an undistributed renewal silently breaks delivery.

S/MIME encryption limitations and gotchas

S/MIME encryption is powerful but not frictionless, and planning around its limits is the difference between a working deployment and a support headache:

• You can only encrypt to someone whose public certificate you hold. Without a prior signed message or a directory entry, you simply cannot encrypt to them.
• Lost private key means permanently lost mail. Forget the .pfx password or lose the key with no escrow, and every message encrypted to it becomes unreadable forever.
• Webmail and mobile have rough edges. Consumer webmail generally cannot do S/MIME; OWA needs an extension; the same private key must be installed on every device a user reads mail on.
• The subject line is not encrypted. Like most message-level encryption, S/MIME historically left headers such as the subject in cleartext, though header-protection extensions are emerging.
• EFAIL taught a hard lesson. The 2018 EFAIL research showed that malicious HTML could exfiltrate decrypted content; disabling automatic remote-content loading is a sensible, durable mitigation.

S/MIME encryption and compliance

S/MIME is a common choice in regulated environments. Under HIPAA, encryption of protected health information is an “addressable” safeguard — you implement it or document an equally effective alternative — and S/MIME is one accepted method. In finance, encryption helps satisfy GLBA and related obligations to protect customer data. Government identity cards such as the US PIV and military CAC carry S/MIME signing and encryption certificates as standard, which is one reason the technology is so entrenched in the public sector and its contractors. Signing also has an anti-phishing benefit that complements your domain-level email authentication: a verified S/MIME signature is visible to the recipient in their client, whereas SPF, DKIM and DMARC operate at the server level and are invisible to the human reader.

S/MIME vs PGP: which should you use?

The two end-to-end email encryption standards differ mainly in how trust is established. S/MIME uses a hierarchical CA model — a Certificate Authority validates identity and issues a certificate — which suits organisations, compliance and clients that support it natively. PGP uses a decentralised web of trust where users vouch for each other’s keys, which suits individuals, developers and privacy-focused communities. For a full side-by-side breakdown, see our S/MIME vs PGP comparison; if the web-of-trust model fits you better, our PGP email encryption guide walks through the alternative.

Related reading

• Email encryption guide
• PGP email encryption guide
• S/MIME vs PGP comparison
• Email spoofing explained

S/MIME encryption FAQ

Is S/MIME encryption free?

The S/MIME standard itself is free and built into clients like Outlook and Apple Mail, but you need a certificate from a Certificate Authority. A few issuers still offer a free mailbox-validated certificate for individuals, while organisation- and identity-validated certificates carry an annual fee. Verify a free issuer is still operating before depending on it, as several have been discontinued.

What is the difference between signing and encrypting with S/MIME?

Signing proves who sent a message and that it was not tampered with, and the recipient does not need anything special to benefit from it. Encrypting hides the contents so only the intended recipient can read them, and it requires that you already hold that recipient’s public certificate. Most secure workflows sign every message and encrypt selectively.

Can I read S/MIME encrypted email on my phone?

Yes, on clients that support it — Apple Mail on iOS and Outlook on mobile both handle S/MIME — but the same private key must be installed on the device first, usually through a configuration profile or your organisation’s device-management system. Consumer webmail in a mobile browser generally cannot decrypt S/MIME messages.

What happens to my encrypted mail when my certificate expires?

An expired certificate can no longer be used to encrypt new mail, but you can still decrypt older messages as long as you keep the matching old certificate and private key. This is exactly why you should never delete old keys when renewing — archive them, or in an organisation, escrow the encryption keys so historical mail stays readable.

Does S/MIME replace SPF, DKIM and DMARC?

No. SPF, DKIM and DMARC are domain-level authentication that mailbox providers check to decide whether to deliver your mail, and they protect your whole domain from spoofing. S/MIME is message-level: it encrypts content and shows a verified signature to the human recipient. They solve different problems and work best together — configure authentication first in our authentication hub, then add S/MIME where confidentiality is required.