What is S/MIME (Secure/Multipurpose Internet Mail Extensions)?

An email certificate is an X.509 digital certificate used to digitally sign and encrypt email messages. The technical standard that governs how email certificates work is S/MIME, which stands for Secure/Multipurpose Internet Mail Extensions. S/MIME defines how public key cryptography is applied to email content and how email clients handle the resulting signed and encrypted messages.

Understanding how email certificates actually work requires understanding one precise asymmetry: signing and encryption use the same key pair in opposite directions and solve different problems. Signing proves who sent the message and that it was not altered. Encryption ensures only the intended recipient can read it. Both use asymmetric cryptography but the key roles swap between the two operations. That asymmetry is what makes email certificates flexible and composable: you can sign without encrypting, encrypt without signing, or do both in combination depending on what the situation requires.

This guide covers the cryptographic mechanism behind both operations, how email clients exchange the public keys needed to encrypt messages, the different certificate types available, and where S/MIME fits against other email security approaches.

How the Cryptographic Mechanism Works

Every email certificate contains a public key and is associated with a private key that the certificate holder keeps secret. The certificate is signed by a Certificate Authority that vouches for the identity associated with the key pair. The public key can be shared freely. The private key never leaves the holder’s control.

The two operations that email certificates enable, signing and encryption, each use the key pair but in different directions. Understanding the direction clarifies who can do what and why.

Signing: the sender’s private key, verified by anyone with the sender’s public key

When you digitally sign an email, your email client computes a hash of the message content using SHA-256 or a similar algorithm. It then encrypts that hash using your private key. The result is the digital signature. Your email client attaches the signature and your certificate (containing your public key) to the outgoing message.

When the recipient’s email client receives the message, it extracts your certificate, uses the public key in it to decrypt the signature, and recovers the original hash. It independently computes the hash of the message content it received. If the two hashes match, two things are confirmed: the message was signed by whoever holds the private key corresponding to the public key in the certificate, and the message content has not been altered since it was signed.

The identity assurance depends on the certificate’s validation level. A certificate that the CA issued after verifying your email address (Individual Validated) confirms the signer controls that email address. A certificate issued after verifying your organization name also confirms the organizational identity. Either way, the recipient’s email client shows a trust indicator based on whether the CA that signed the certificate is in the trusted CA list.

The direction here is important: the private key encrypts the signature hash, the public key decrypts it. This is the reverse of normal encryption. It works because of a mathematical property of asymmetric key pairs: data encrypted with one key can only be decrypted with the other, and the relationship is bidirectional. In normal encryption, the public key encrypts and the private key decrypts. In signing, the private key encrypts and the public key decrypts. The different direction is what makes signatures verifiable by anyone while only producible by the private key holder.

Encryption: the recipient’s public key, decryptable only by the recipient’s private key

When you encrypt an email to a recipient, you need their public key. In practice, S/MIME email clients collect recipients’ public keys from signed emails they have previously received, from LDAP or Active Directory directories, or from public certificate directories.

S/MIME encryption combines symmetric and asymmetric cryptography. Your email client generates a random symmetric session key, encrypts the message content with that session key using AES or a similar symmetric algorithm, then encrypts the session key itself using the recipient’s public key. Both the encrypted message and the encrypted session key are sent to the recipient.

The recipient’s email client uses their private key to decrypt the session key. It then uses the recovered session key to decrypt the message content. Only the recipient can perform this decryption because only the recipient holds the private key corresponding to the public key that encrypted the session key. An attacker who intercepts the message sees only ciphertext and cannot decrypt it without the private key.

The hybrid approach (symmetric encryption for content, asymmetric encryption for key exchange) is used because asymmetric encryption is computationally expensive for large amounts of data. Encrypting a 10 MB email attachment using RSA directly would be very slow. Encrypting it with AES is fast. The only asymmetric operation needed is encrypting the short session key. This pattern is the same hybrid used in TLS.

Signing and encryption are independent and composable

A critical point that most explanations of S/MIME blur: signing and encryption are separate operations. You can send a signed but unencrypted message: the content is readable by anyone, but the signature proves you sent it unaltered. You can encrypt without signing: the content is private, but the recipient has no cryptographic proof of who sent it. You can do both: sign first, then encrypt the signed message, giving the recipient both confidentiality and verified authorship.

The typical S/MIME workflow in corporate environments is to sign all outgoing messages and encrypt only those going to recipients whose public keys are available. Messages to recipients without S/MIME certificates cannot be encrypted (there is no public key to encrypt the session key with) but can still be signed.

The Public Key Exchange Problem: How Recipients Get Each Other’s Public Keys

Encryption requires the sender to have the recipient’s public key before composing the encrypted message. This is the practical friction point in S/MIME deployment that TLS does not have. With TLS, the server publishes its certificate and any client can retrieve it at connection time. With S/MIME, there is no built-in mechanism for discovering a recipient’s public key from their email address alone.

Three approaches address this:

• Exchange through signed email: The simplest method. When someone sends you a digitally signed email, their certificate (containing their public key) is attached. Your email client stores the public key and makes it available when you compose an encrypted reply. Two people who have exchanged signed emails can immediately start encrypting messages to each other.
• LDAP or Active Directory directory: In enterprise environments, S/MIME certificates are published to an LDAP directory or Active Directory. Outlook and other corporate email clients automatically look up recipients’ certificates from the directory when composing encrypted messages. This removes the need for prior signed email exchange within the organization.
• Public certificate repositories: Some CAs publish customer certificates to public LDAP directories or web-based repositories. Sectigo and GlobalSign both offer this for their S/MIME certificates. Email clients configured to query these directories can encrypt to recipients they have never previously communicated with, as long as the recipient has a published certificate.

The practical implication for organizations deploying S/MIME: encrypt-to-external-recipients works reliably only if external recipients either have exchanged signed emails with your staff or have published certificates. For purely internal use within a single organization, publishing to an internal LDAP or Active Directory eliminates this friction entirely.

Types of Email Certificates (S/MIME Certificate Profiles)

The CA/B Forum published the S/MIME Baseline Requirements in September 2023, establishing standardized certificate profiles and validation requirements for all publicly trusted S/MIME certificates. These requirements define four certificate types based on validation level and subject identity.

The September 2023 CA/B Forum Baseline Requirements also mandated stronger cryptographic minimums for new S/MIME certificates: RSA keys must be at least 3072 bits (up from 2048), and ECDSA keys must use P-256 or P-384. SHA-1 is prohibited. These changes align S/MIME certificate requirements with the tighter standards already applied to TLS certificates.

What Email Certificates Protect Against

S/MIME digital signatures address phishing and impersonation attacks where an attacker sends email pretending to be from a trusted individual or organization. A signed email with a valid certificate from a trusted CA proves the message genuinely originated from someone who controls the signing key associated with the verified identity. A recipient who sees the signed indicator in their email client knows the message was not spoofed.

Email spoofing is trivially easy without S/MIME. The From header in an email is a user-editable field with no inherent authentication. SPF, DKIM, and DMARC provide domain-level authentication (proving the message came from an authorized mail server for that domain) but do not prove which individual at that domain sent the message. S/MIME adds individual-level authentication on top of domain-level authentication.

S/MIME encryption addresses the interception of email content in transit or at rest. Email travels through multiple servers and storage systems between sender and recipient. TLS between mail servers encrypts content in transit but only between adjacent servers: each server decrypts and re-encrypts as it passes the message along. S/MIME encrypts at the client and decrypts at the client, end-to-end. Only the recipient’s private key decrypts the message. Mail servers, mail service providers, and anyone who gains access to the server storage sees only ciphertext.

TLS between mail servers (STARTTLS or SMTP over TLS) and S/MIME are complementary, not alternatives. TLS encrypts the transport connection between servers, preventing interception on the network. S/MIME encrypts the message content end-to-end, preventing access by anyone except the intended recipient including mail server operators. An organization that needs to protect email content from its mail service provider needs S/MIME, not just TLS.

What Email Certificates Do Not Protect Against

S/MIME does not protect against malware in attachments. The encryption and signature ensure the attachment arrived unmodified from the stated sender. They do not prove the attachment is safe to open. A signed and encrypted email can carry ransomware.

S/MIME does not protect against compromise of the private key. If a sender’s private key is stolen, an attacker can create signatures that appear legitimate. If a recipient’s private key is stolen, past and future encrypted messages addressed to that recipient can be decrypted. Private key security is the operational foundation on which all S/MIME security rests. Keys should be stored in hardware security modules, smart cards, or TPM chips rather than as unprotected files on disk.

S/MIME does not protect subject lines or message headers. Only the message body and attachments are signed and encrypted. The To, From, CC, Subject, and other headers remain in plaintext. An observer cannot read the message content but can see who communicated with whom, when, and about a topic indicated by the subject line.

Email Client Support for S/MIME

S/MIME is supported natively in Outlook (Windows and Mac), Apple Mail on macOS and iOS, Thunderbird, IBM Notes, and most enterprise mail clients. The setup process involves installing the certificate into the email client’s certificate store and configuring the client to sign and optionally encrypt outgoing messages.

Gmail’s web interface does not support S/MIME for consumer accounts. Google Workspace Business and Enterprise plans support S/MIME when configured by the organization’s administrator, allowing Workspace users to send and receive signed and encrypted messages. Google’s mobile Gmail app does not support S/MIME. Organizations deploying S/MIME for Workspace users typically use a gateway solution that handles S/MIME on the server side, making encryption transparent to end users.

Outlook on Windows supports S/MIME through Windows Certificate Store integration. When a certificate is installed in the Windows Certificate Store and the Outlook account email address matches the certificate’s Subject Alternative Name, Outlook automatically uses the certificate for signing. Encrypted replies to signed messages happen automatically once the public key exchange occurs through the initial signed message.

S/MIME vs PGP: The Two Email Encryption Standards

PGP (Pretty Good Privacy) and its open-source implementation GPG provide email signing and encryption using a different trust model from S/MIME. The two systems solve the same problem with different philosophies.

S/MIME is the standard in enterprise email environments because it integrates with existing PKI infrastructure and deploys through standard tooling. PGP/GPG is used by individual privacy-conscious users, journalists, security researchers, and open-source communities where the decentralized web-of-trust model fits the use case better than CA-based PKI.

Deploying Email Certificates in an Organization

Small organizations with under 50 users typically issue certificates individually: each user requests or purchases a certificate from a CA, installs it in their email client, and begins signing. The CA validates each email address and any organizational details specified.

Larger organizations use automated issuance workflows. Microsoft Active Directory Certificate Services can issue S/MIME certificates to users through domain enrollment, automatically populating them in users’ Windows Certificate Stores and Outlook. This removes the manual request process for each employee. Some organizations use third-party certificate management platforms (Keyfactor, Venafi) that integrate with Active Directory and multiple CAs to issue and rotate S/MIME certificates at scale.

Private key backup and recovery requires a documented policy. If a user’s private key is lost (device failure, departure from the organization), encrypted emails to that user cannot be decrypted. Organizations that need to access archived encrypted email for compliance or legal discovery purposes must have a key escrow or key recovery mechanism in place before encryption is deployed, not after.

Key escrow is the practice of storing a copy of each user’s private key in a secure organizational vault. It is required for email encryption in any regulated environment that needs to produce email content in response to legal discovery or regulatory audit. Deploy key escrow policy before rolling out S/MIME encryption organization-wide, otherwise encrypted archives become inaccessible when staff leave or lose their devices.

Frequently Asked Questions

What is an email certificate?

An email certificate is an X.509 digital certificate that enables S/MIME functionality in an email client. It contains the certificate holder’s email address, public key, and optionally their name and organization, all signed by a Certificate Authority. The certificate allows the holder to digitally sign outgoing emails (proving their identity and message integrity) and allows others to send them encrypted emails (using the public key in the certificate). Email certificates are also called S/MIME certificates, email signing certificates, or secure email certificates.

What is the difference between signing and encrypting an email?

Signing proves who sent the email and that it was not altered in transit. It uses the sender’s private key to create a signature that anyone with the sender’s public key can verify. The message content remains readable. Encrypting hides the message content so that only the intended recipient, holding the matching private key, can read it. It uses the recipient’s public key to encrypt a session key. The two operations use the key pair in opposite directions and serve different purposes. They can be used independently or together.

Do I need the recipient’s certificate to send them an encrypted email?

Yes. To encrypt an email, you need the recipient’s public key, which is contained in their S/MIME certificate. Without the recipient’s certificate, you can sign the email but not encrypt it. The most common way to obtain a recipient’s certificate is to receive a digitally signed email from them: their certificate is attached and your email client stores the public key automatically. In enterprise environments, certificates are typically stored in an LDAP directory or Active Directory where your email client retrieves them automatically when composing to an internal recipient.

Does S/MIME protect emails stored on a mail server?

Yes, if the messages were encrypted with S/MIME before sending. S/MIME encryption is end-to-end: the message is encrypted at the sender’s email client and only decrypted at the recipient’s email client. The mail server and mail service provider see only ciphertext for encrypted messages. This is a meaningful improvement over relying only on TLS between mail servers, which decrypts and re-encrypts at each hop, leaving message content accessible to each intermediate server.

What is non-repudiation and why does it matter for email?

Non-repudiation means the sender cannot credibly deny having sent a digitally signed message. Only the holder of the private key can produce a valid signature verifiable with the corresponding public key. If a message is signed with your S/MIME certificate, the signature proves you sent it. This has legal implications: digitally signed emails are accepted as evidence in legal proceedings in many jurisdictions, because the signature demonstrates the sender’s identity and confirms the content has not been altered. Non-repudiation is particularly valuable in financial transactions, legal communications, and regulatory compliance contexts where the authenticity of email records may be challenged.

How does S/MIME differ from TLS-encrypted email?

TLS encrypts the connection between mail servers during transmission. Each server decrypts the message as it passes through and re-encrypts it for the next hop. The message content is accessible at each server in plaintext. S/MIME encrypts the message content at the sender’s client and decrypts it only at the recipient’s client. No intermediate server, including the mail service provider’s servers, can read S/MIME-encrypted content. TLS protects transit; S/MIME protects the content end-to-end and provides sender authentication through digital signatures.