S/MIME: what RFC 8551 actually defines
A standards-first look at S/MIME 4.0: certificate-based end-to-end signing and encryption for email, and the gap transport security never closed.
SMTP moves a message from server to server. MIME structures what's inside it. Neither one protects the message body from being read by anyone who can access it in storage, and neither one proves who actually wrote it. Transport security like STARTTLS only covers a single hop while the message is in flight, not the message itself once it lands on a server somewhere along the way.
The gap transport security doesn't close
Encrypt the connection between two mail servers and you've protected exactly one hop. The message still sits in plaintext on the sending server's disk, the receiving server's disk, any relay in between, and every mailbox it gets copied into. A compromised server, a subpoenaed backup, or a misconfigured storage bucket exposes the full message regardless of how well the transport was encrypted.
Verifying who sent a message has the same problem. SPF and DKIM authenticate a domain, not a person, and they check the message as it crosses a specific hop rather than vouching for whoever originally wrote it. No standard let a recipient verify that a message actually came from a specific individual, not just a domain.
What RFC 8551 defines
RFC 8551 defines S/MIME version 4.0: a MIME-content-type-based scheme for signing and/or encrypting a message body using X.509 certificates. RFC 8551 expresses the protection as a MIME content type, so it travels with the message itself and doesn't depend on which servers relay it or how those servers are configured.
RFC 8551 supersedes S/MIME 3.2 (RFC 5751), mainly by mandating current cryptographic algorithms in place of older ones that had grown weak.
How it works
The sender's mail client does the work, not the mail server. Two operations are available, independently or combined:
- Encryption uses the recipient's public key certificate. Only the private key matching that certificate can decrypt the result, so the message body is unreadable to anyone else, including every server it passes through.
- Signing uses the sender's own private key to produce a signature over the message. Any recipient can verify that signature against the sender's certificate, confirming both that the content wasn't altered and that it came from the certificate's holder.
Either operation produces a MIME structure that replaces or wraps the original body: application/pkcs7-mime for encrypted content, and either multipart/signed or application/pkcs7-mime for signed content. A mail client that doesn't understand S/MIME still sees a normal, if unreadable, MIME part. One that does understand it decrypts or verifies before showing the message.
Anatomy of an S/MIME message
| Content type | Used for |
|---|---|
application/pkcs7-mime; smime-type=enveloped-data | Encrypted content |
application/pkcs7-mime; smime-type=signed-data | Signed content, opaque form |
multipart/signed | Signed content, an alternative form that keeps the original body readable alongside a detached signature |
Every S/MIME certificate sits in a chain: a leaf certificate issued to the sender, tracing up through zero or more intermediate certificates to a trusted root certificate authority (CA). A recipient's mail client validates a signature by walking that chain and checking that it trusts the CA at the top. If the recipient doesn't already trust that CA, or a link in the chain is missing or expired, the mail client can't confirm the signature, even though the certificate itself is technically valid.
A signed and encrypted message
A message that's both signed and encrypted carries a header like this:
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
The body underneath is opaque PKCS#7 data. The receiving client decrypts it with the recipient's private key, then checks the signature inside against the sender's certificate and its chain to a trusted CA.
The chain's validation decides what the recipient sees next. If it validates, the client shows a signature-verified indicator, often a badge or lock icon next to the sender's name, that confirms the message matches the certificate and hasn't been altered. If it doesn't, whether because the CA isn't trusted, the certificate expired, or the signature doesn't match, the client shows a warning instead, or doesn't confirm the sender's identity at all.
Limits
S/MIME's biggest deployment barrier is the certificate itself. Encryption requires the recipient's public key certificate, which usually means both parties need to obtain certificates and exchange them before any encrypted mail between them is possible at all. That's a setup cost most casual email exchanges skip.
Issuing certificates and checking whether they've been revoked adds operational overhead too. Someone has to run or pay for a CA relationship, renew certificates before they expire, and check revocation status on incoming messages. Consumer email clients rarely take on any of that.
RFC 8551 mandates modern algorithms, AES-GCM for encryption and ECDSA/ECDH for signing and key agreement, in place of the older algorithms S/MIME 3.2 allowed. That's a security improvement, but it means interoperating with a client still running S/MIME 3.x can require negotiating down to an older, mutually supported algorithm.
Check it yourself
S/MIME shows up most often in corporate and government email, where certificate issuance is centrally managed. If you receive a signed message from a sender like that, view the raw source of the email and look for the Content-Type header. multipart/signed or application/pkcs7-mime marks it as S/MIME. In Gmail, open the message and select "Show original" from the menu.
Where it fits
S/MIME isn't the only way to sign and encrypt email end to end. OpenPGP solves the same problem without the certificate authority S/MIME depends on. Both rely on the content-type mechanism described in the MIME reference: S/MIME's application/pkcs7-mime and multipart/signed are ordinary MIME types, interpreted by any client that understands S/MIME specifically.
For the wider set of standards this fits into, see the reference hub.
FAQ
Do both sender and recipient need a certificate?
Encryption requires the recipient's public key certificate, so yes, the recipient needs one. In practice both sides typically exchange certificates first, since encrypted mail isn't possible until each has the other's.
Does S/MIME protect a message in transit or at rest?
Both, in a sense. S/MIME applies the protection to the message body itself, not to the connection carrying it, so it stays intact wherever the message is stored or forwarded. That's a meaningful difference from transport-only security like STARTTLS, which stops protecting the message the moment it lands on a server.
What's the difference between signing and encrypting in S/MIME?
Signing uses the sender's private key so any recipient can verify the message wasn't altered and did come from that certificate. Encrypting uses the recipient's public key so only their private key can read the content. A message can use either one on its own, or both together.
Why isn't S/MIME more widely used for consumer email?
The certificate requirement. Both parties need working certificate infrastructure, issuance, exchange, and often revocation checking, before encrypted mail works between them at all. That's more setup than most consumer email ever takes on, which is why S/MIME shows up mostly in corporate and government settings where certificates are already centrally managed.
RFC reference
RFCs covered: RFC 8551. Superseded / updated by: None currently. RFC 8551 itself supersedes S/MIME 3.2 (RFC 5751).