What Is an Email Certificate? A Practical Guide to S/MIME Email Security

What is inside an email certificate?

An email certificate is an X.509 certificate with two markers that make it an S/MIME certificate: the extended key usage id-kp-emailProtection and your mailbox address in the subject alternative name. The S/MIME Baseline Requirements use exactly those two markers to define what counts as an S/MIME certificate. Everything else in it says who the certificate authority (CA) checked and for how long the certificate is good.

To see the fields rather than describe them, we built a test certificate the way a CA would profile a Mailbox-validated Strict certificate and printed it with OpenSSL:

$ openssl x509 -in alice.crt -noout -text   (trimmed)
        Validity
            Not Before: Oct 12 09:16:11 2026 GMT
            Not After : Jan 14 09:16:11 2029 GMT
        Subject: CN = <mailbox address>
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                E-mail Protection
            X509v3 Subject Alternative Name:
                email:<mailbox address>
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.5.1.3

The private key that matches the certificate is not inside it. It usually stays with you, in your operating system's key store or your mail app, and it is the part you must back up.

How do signing and encryption use the certificate?

An email certificate does two separate jobs. Signing uses your private key to attach a signature that anyone can check with your certificate, which proves the message came from your mailbox and was not changed. Encryption works the other way round: the sender locks the message with the recipient's certificate, and only the recipient's private key opens it. RFC 8551, the S/MIME 4.0 standard, lists the same split: signatures give authentication, integrity and proof of origin; encryption gives confidentiality.

We ran both jobs with the test certificate. A signed message verified; after one word in the body was changed, the same check failed. A message encrypted to the certificate opened with its private key and refused to open with any other key:

$ openssl cms -sign -in msg.txt -signer alice.crt -inkey alice.key -out signed.eml
$ openssl cms -verify -in signed.eml -CAfile ca.crt -out /dev/null
CMS Verification successful

# change one word in the signed body, then verify again
$ openssl cms -verify -in tampered.eml -CAfile ca.crt -out /dev/null
CMS Verification failure

$ openssl cms -encrypt -aes-256-cbc -in msg.txt -out enc.eml alice.crt
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"

# decrypt with a different private key
$ openssl cms -decrypt -in enc.eml -inkey other.key
Error decrypting CMS structure

Getting the other person's certificate is the step people trip over. A signed message carries the sender's certificate, so the usual move is to ask them to send you a signed email first; RFC 8551 suggests exactly that, and Apple's platform guide says Mail offers encryption once it has the recipient's certificate or can find it in the Exchange global address list. In apps that don't understand S/MIME, that attached signature shows up as a file, which is why people ask what the smime.p7s attachment on signed email is.

Which type of email certificate do you need?

The S/MIME Baseline Requirements define four types of email certificate, and the right one depends on what the certificate should name: only the mailbox (Mailbox-validated), a person (Individual-validated), a company (Organization-validated), or a person at a company (Sponsor-validated). The CA always checks that you control the mailbox, and adds identity checks for whatever else the certificate names.

A quick rule: choose Mailbox-validated if you only need signed and encrypted mail; choose a type that names your company if recipients should see the business behind the address. The guide to S/MIME validation types covers the documents each check needs. At My-SSL, the Individual plan validates the email address only and the Business plan also validates the organization and puts the company name in the certificate; both are listed on the S/MIME email certificate page.

How long is an email certificate valid?

A publicly trusted email certificate is valid for at most 825 days on the Strict and Multipurpose profiles and at most 1,185 days on the Legacy profile, under section 6.3.2 of the S/MIME Baseline Requirements (version 1.0.16, as of October 12, 2026). Two of the top five search results still describe terms of "1 to 3 years" or a "maximum term of 3 years"; the 3-year end is longer than any single Strict or Multipurpose certificate allows.

The rules also tighten on a set date. Ballot SMC018 says that from July 1, 2027 only the e-mail protection extended key usage, plus optionally client authentication, may appear in a publicly trusted S/MIME certificate, so certificates that today also sign documents lose that role at their first renewal on or after that date. The details are in the July 2027 S/MIME key usage change, and what happens to older encrypted mail when a certificate expires is covered in the S/MIME renewal guide.

Is an email certificate the same as DKIM or DMARC?

No. DKIM and DMARC work at the level of the sending domain and are checked by the receiving mail server, while an email certificate signs a single message for a single mailbox and is checked by the recipient's mail app. RFC 6376 describes DKIM as a way for the owner of a domain to claim responsibility for a message; RFC 7489 describes DMARC as domain-level policy and reporting. Neither says which person wrote the message, and neither encrypts it.

The two fit together rather than compete. A domain should publish SPF, DKIM and DMARC whether or not anyone uses S/MIME. An email certificate adds what those cannot: a signature a reader can check on their own screen, and encryption that stays on the message after it leaves the server. It does not stop an impostor from sending unsigned mail, so it helps only when recipients notice that a message they expect to be signed is not.

Which email apps can use it?

Outlook, Apple Mail and Thunderbird all sign and encrypt with an email certificate once you import it, according to Microsoft, Apple and Mozilla's own help pages. Gmail is the exception: Google offers S/MIME only as a hosted feature on certain Google Workspace editions, switched on by an administrator, and as of October 12, 2026 it does not list free Gmail accounts.

How do you get one and start using it?

Getting an email certificate takes four steps: pick the type, prove you control the mailbox, install the certificate with its private key in your mail app, and back that key up. For the mailbox check, the Baseline Requirements let a CA send a unique random value to the address, which stays usable for no more than 24 hours, so answer the CA's email the same day.

1. Pick the type from the table above, one certificate for each address you sign from.
2. Pass validation: the emailed code for the mailbox, plus organization or identity documents if the type names a company or a person.
3. Install it where your mail app looks: Keychain on a Mac, Certificate Manager in Thunderbird, the digital ID settings in Outlook.
4. Back up the private key. Our decryption test above shows why: mail encrypted to your certificate cannot be opened with any other key.

Which S/MIME guide do you need next?

This page is the starting point for the S/MIME guides on My-SSL. Each guide below answers one job in detail, grouped by where you are: choosing a certificate, setting it up in a mail app, fixing an error, or keeping it valid as the rules change.