S/MIME Certificate Validation Types: Mailbox, Organization, Sponsor and Individual

What are the four S/MIME certificate types?

They are mailbox-validated, organization-validated, sponsor-validated and individual-validated, and the difference between them is the contents of the certificate subject. Mailbox-validated is limited to an email address with an optional common name and serial number. Organization-validated carries legal-entity attributes only. Sponsor-validated combines natural-person attributes with an organizationName. And individual-validated carries natural-person attributes with no organization at all.

An S/MIME certificate is recognisable in the first place by two things: an extended key usage of id-kp-emailProtection (OID 1.3.6.1.5.5.7.3.4), and a mailbox address in the subject alternative name extension, carried either as an rfc822Name or, for internationalised addresses, as an otherName of type id-on-SmtpUTF8Mailbox. Every publicly trusted S/MIME certificate has both, whichever of the four types it is.

One consequence is worth stating plainly, because it is the thing people most often get backwards: the type has no bearing on the cryptography. A mailbox-validated certificate and a sponsor-validated certificate protect a message identically. What differs is how much a recipient can establish about who sent it — and, therefore, how much your signature is worth to somebody who does not already know you.

What does each type actually prove?

Section 3.2 of the requirements sets out three separate checks — mailbox control, organization identity and individual identity — and each type is defined by which of the three the CA must complete. Mailbox-validated needs the first alone. Organization-validated needs mailbox control plus organization identity. Individual-validated needs mailbox control plus individual identity. Sponsor-validated is the only type that requires all three.

Mailbox control itself has more than one permitted method, and the choice affects your timeline more than most people expect. A CA can prove authority over the whole email domain using the same kinds of checks used for TLS certificates, or it can prove control of a single mailbox by sending something to it, or it can confirm the applicant runs the associated mail servers. There is also an ACME-based method, which is what makes automated S/MIME issuance possible for organisations willing to run the plumbing.

Organization and individual identity are heavier. Organization identity means the CA establishes that the legal entity exists and that the attributes going into the certificate match a reliable source. Individual identity means verifying a natural person, normally against identity documents. Neither can be waved through, and neither is instant. If your rollout plan assumes sponsor-validated certificates for forty people will arrive as quickly as mailbox-validated ones, the plan is wrong by days rather than hours.

There is one registration shortcut worth knowing about. Sponsor-validated certificates may be registered through an Enterprise RA — an organisation the CA has delegated certain request duties to — which is how a company issues to its own staff without every employee dealing with the CA directly. For a broader look at where email certificates fit alongside the rest of a certificate estate, see what an email certificate is and how S/MIME works.

What are the Legacy, Multipurpose and Strict generations?

Generations are a second axis, applied on top of the type, that controls what else the certificate is allowed to contain. There are three: Legacy, Multipurpose and Strict. Legacy existed to let pre-existing CA practices become auditable when the requirements first arrived, and it has been closed since July 15, 2025 — subscriber certificates may no longer be issued under any of the four Legacy policy OIDs. That leaves Multipurpose and Strict as the only live choices.

The practical difference is the extended key usage extension. Strict requires id-kp-emailProtection and forbids any other value, so a Strict certificate does email and nothing else. Multipurpose requires email protection too but permits additional values alongside it, which is how one certificate can sign mail and authenticate a user to a system. Neither generation may ever carry server authentication, code signing, time stamping, or anyExtendedKeyUsage — those are prohibited outright.

That validity column explains a stubborn piece of misinformation. A great deal of published material still says S/MIME certificates run for up to three years, and the figure was accurate when Legacy allowed 1,185 days. It is not accurate for anything issued today. As of August 2026 the ceiling is 825 days, a little over two years, for both live generations — and the requirements themselves suggest CAs should stop short of the maximum, because of how the day count is defined.

How do I tell which type my certificate is?

Read the certificate policies extension and find the OID under the arc 2.23.140.1.5. The digit that follows the arc is the type — 1 mailbox-validated, 2 organization-validated, 3 sponsor-validated, 4 individual-validated — and the digit after that is the generation, with 1 Legacy, 2 Multipurpose and 3 Strict. Two numbers, and you have identified the certificate exactly, without relying on whatever the product was called at checkout.

For a PEM-encoded certificate, one command is enough:

openssl x509 -in mycert.pem -noout -text | grep -A2 "Certificate Policies"

S/MIME certificates are more often delivered as a password- protected PKCS#12 file, in which case extract the certificate part first and pipe it through:

openssl pkcs12 -in mycert.p12 -nokeys -clcerts | openssl x509 -noout -text

Then read the whole subject while you are in there. If the subject shows an organizationName next to a person's given name and surname, you are holding a sponsor-validated certificate whatever the invoice said. If it shows an email address and little else, it is mailbox-validated. The OID and the subject should agree; if they do not, that is worth raising with the CA. The general layout of these fields is covered in our walkthrough of X.509 fields and extensions.

The four OIDs ending in .1 are the Legacy ones. Seeing one of those in a certificate is not a fault — it simply means the certificate was issued before July 15, 2025, and its replacement will carry a different profile.

Which validation type do you need?

Start from what you want a recipient to be able to verify, not from a price list. If the answer is only that the message came from that address, mailbox-validated is enough. If it is that a company stands behind a shared address, organization-validated is the fit. If it is that a specific employee sent it on the company's behalf, sponsor-validated is the only type that says so. And if a named person is signing for themselves, individual-validated does it without inventing an employer.

A few patterns fall out of this that are worth naming. Role addresses — billing@, support@, invoices@ — should almost always be organization-validated, because they outlive the people who staff them and a certificate naming last year's finance manager ages badly. Regulated correspondence that has to attribute a document to a person, on the other hand, wants sponsor-validated, and no amount of organization validation substitutes for it.

Mailbox-validated has a narrower place than its price suggests. It is genuinely useful for internal mail, for testing a deployment before committing budget, and anywhere the recipients already know who you are through some other channel. It is weak for exactly the case people buy it for — persuading an outsider that a message is genuine — because the certificate makes no claim about who holds it. Our individual and business S/MIME certificates cover the person-level and organization-backed options, and the S/MIME buying guide walks through the purchase itself, including client compatibility.

Then answer the second question before you order, because it is the one that gets discovered late: does this certificate have a job beyond email? Strict is the cleaner profile and the direction the requirements are heading, but it will refuse to authenticate you to a VPN or a portal, by design. If a single credential has to do both, you need Multipurpose, and you need to confirm that is what the CA will issue.

How long do they last, and when does validation repeat?

As of August 2026, Strict and Multipurpose certificates may be issued for a maximum of 825 days. Separately, the requirements cap how long a CA may lean on validation work it has already done: organization identity and individual identity may each be reused for up to 825 days, mailbox control established through the domain or mail-server methods for up to 398 days, and mailbox control established by sending mail to the address for only 30 days.

Those reuse windows are the reason renewals sometimes feel inconsistent. One renewal goes through in minutes and the next asks for identity documents again, and nothing about your account changed — the evidence behind the earlier issuance simply aged past its permitted reuse period. The 30-day window on email-based mailbox control is the tightest of the set, which is why a confirmation link tends to reappear on almost every reissue while the heavier identity checks do not.

Plan renewals as a recurring obligation rather than an occasional event, particularly for a team. An expired S/MIME certificate does not only stop you signing: correspondents who hold your old certificate can keep encrypting to a key you are supposed to have retired, and anything already encrypted to it stays unreadable without the matching private key, so key backup deserves as much thought as renewal. Setting a reminder well before the date is worth the two minutes, and our certificate expiry reminder is free to use.

One change is already scheduled and worth a note in the calendar. Effective September 15, 2027, a CA may not issue S/MIME certificates from an issuing CA whose RSA key is smaller than 3072 bits, and CA certificates signed on or after September 15, 2026 must use at least a 4096-bit RSA key. Neither affects the key in your own certificate — subscriber RSA keys stay at a 2048-bit minimum — but both may change which issuing CA your certificates chain to, which matters if anything in your environment pins an intermediate.