What Is an S/MIME Certificate?

What Is an S/MIME Certificate?

An S/MIME certificate is a digital certificate that lets you digitally sign and encrypt email. It applies the same underlying idea as an SSL/TLS certificate securing a website to a different channel: instead of protecting the connection between a browser and a server, it protects the message itself, wherever it travels afterward.

S/MIME certificates do two distinct things, and it matters which one you need:

• Signing proves who sent a message and that its content was not altered in transit, similar to how a signature works on software.
• Encryption makes the message unreadable to anyone except the intended recipient.

The two are independent: you can sign a message without encrypting it, and — critically — you cannot encrypt a message for someone unless you already have their public certificate, because encryption uses the recipient's certificate, not your own. This is why S/MIME adoption tends to spread person by person: you can send a signed message to anyone, but encrypted email requires exchanging certificates first. S/MIME sits in SSLCipher's certificate catalog alongside standard SSL/TLS certificates and code signing certificates, covering email instead of websites or software files.

Signing vs. Encrypting Email With S/MIME

A signed message carries a digital signature built from a hash of the message content and your certificate's private key, the same underlying mechanism used to sign software: the recipient's mail client recalculates the hash, checks it against the signature, and confirms the certificate chains to a trusted authority. If any of that fails, the client shows a warning instead of treating the message as trusted.

Encryption works differently. Before you can send someone an encrypted message, your mail client needs their public certificate — typically obtained the first time they send you a signed message, since a signed message includes the sender's public certificate. Once your client has it, it encrypts the message so that only the private key matching that certificate can decrypt it, meaning even your own outbound mail server never sees the plaintext content. This is also why an email encryption certificate only protects messages you send to people whose certificate you already hold, not every recipient by default.

S/MIME Certificate Types Under the 2023 Baseline Requirements

Since 1 September 2023, the CA/Browser Forum's S/MIME Baseline Requirements define a common set of validation levels for publicly trusted S/MIME certificates, broadly comparable to how SSL certificates have DV, OV and EV levels:

All four types can sign and encrypt mail; what differs is how much identity information the certificate authority verifies, and therefore how much the certificate itself vouches for beyond "this mailbox."

What Recipients See When You Sign or Encrypt Mail

A correctly signed message typically shows up in the recipient's mail client with a visible indicator — often a badge or ribbon icon near the sender's name — confirming the signature is valid, alongside the option to view the certificate details behind it. An encrypted message generally shows a lock icon and simply will not open for anyone without the matching private key, including the recipient's own mail provider in most configurations.

If a signature does not validate — because the certificate expired, was revoked, or does not match the message — mail clients typically flag the message rather than silently showing it as trusted. This is part of what makes an email signing certificate useful against impersonation: a forged "from" address without a valid signature stands out instead of blending in.

S/MIME Setup in Outlook, Apple Mail and Thunderbird

At a high level, S/MIME setup follows the same pattern across major mail clients, though the exact menus differ by version:

• Install the S/MIME certificate, together with its private key, into the operating system's or mail client's certificate store. This step typically happens once per device.
• Open the account's security or certificate settings in your mail client — Outlook, Apple Mail and Thunderbird all expose a dedicated section for this — and select the installed certificate for signing and, separately, for encryption.
• Choose whether signing, encryption, or both should apply by default to outgoing mail, and confirm the setting per account if you manage more than one mailbox.

Because the private key travels with the certificate during installation, keep the certificate file and any password protecting it as carefully as you would any other credential; anyone who has both can sign or decrypt mail as you.

Backing Up Your Key and Moving to a New Device

An S/MIME certificate is only useful on a device that also has its private key installed, so moving to a new computer or phone means exporting the certificate, with its password-protected private key, from the old device and importing it on the new one, rather than reissuing a fresh certificate each time. Losing the private key without a backup means losing the ability to decrypt any mail that was encrypted to that certificate — new mail signed or encrypted afterward can use a newly issued certificate, but old encrypted messages tied to the lost key cannot be recovered through the certificate alone.

Because of this, treating your S/MIME private key like any other sensitive credential — backed up somewhere secure, not only on the one device where it was installed — is worth doing before you need it rather than after.

Business Use Cases for S/MIME

S/MIME certificates show up most often in email that needs to be provably genuine or confidential:

• Invoices and contracts sent by email benefit from a verifiable signature confirming they came from the stated sender and were not altered afterward.
• Finance and HR correspondence often contains sensitive personal or financial details that justify encrypting the message body, not just the connection to the mail server.
• Phishing protection is a common driver for adoption: a validly signed message is harder to spoof convincingly than a plain "from" address, since the signature itself would fail to validate on a forged message.

These use cases explain why S/MIME adoption is often organization-led: once one team standardizes on signed or encrypted mail for a category of correspondence, the practice tends to spread to whoever exchanges that kind of mail with them.

Limits of S/MIME You Should Know Before Setting It Up

S/MIME has two practical limits worth knowing before you roll it out:

• Both sides need support. Signing works for any recipient, but encrypted mail requires the recipient's mail client to also support S/MIME and requires you to already hold their certificate — it is not something you can turn on unilaterally for every contact.
• Webmail support varies. Desktop and mobile clients such as Outlook, Apple Mail and Thunderbird have long-standing S/MIME support, but browser-based webmail interfaces vary in how well, or whether, they support certificate-based signing and encryption, so check your specific webmail provider before assuming it works the same way as a desktop client.

Getting an S/MIME Certificate

Which S/MIME type you need — mailbox-, organization-, sponsor- or individual-validated — depends on whether the certificate needs to represent an individual, a role inside a company, or a company itself, and how much identity verification you want behind it. The general purchase flow follows the same shape described in our guide to buying an SSL certificate: choose the product, complete the required validation, and receive the certificate ready to install.

SSLCipher's catalog includes S/MIME certificates alongside its SSL/TLS and code signing products; current products and prices are listed on the pricing page.

Frequently asked questions