← RFC Reference

RFC 5751: S/MIME 3.2 Message Specification

Why This Exists

Transport-layer security (TLS, STARTTLS) protects email between hops, but it has limits:

• Server operators can read your mail. TLS terminates at each server. The sending server, receiving server, and any intermediaries see the plaintext content.
• No guarantee of origin. DKIM proves a domain handled the message, but doesn't prove which person authored it.
• No tamper detection after delivery. Once a message is stored on the server, DKIM signatures may break if the message is modified. S/MIME signatures protect the content itself.

S/MIME provides end-to-end encryption (only the recipient can decrypt) and digital signatures (the recipient can verify the sender's identity and that the content wasn't altered). It uses X.509 certificates from the same PKI that secures HTTPS.

How It Works

The Two Operations

S/MIME wraps standard MIME messages in cryptographic envelopes using CMS (Cryptographic Message Syntax):

You can sign only, encrypt only, or sign-then-encrypt (the most common combination).

Signing a Message

The sender uses their private key to create a digital signature over the message content. Two formats exist:

• Clear-signed (multipart/signed): The original message is readable by any client. The signature is a separate MIME part. Non-S/MIME clients see the message normally and ignore the signature.
• Opaque-signed (application/pkcs7-mime): The message and signature are bundled together. Only S/MIME-aware clients can extract the content.

-- Clear-signed message structure --
Content-Type: multipart/signed;
  protocol="application/pkcs7-signature";
  micalg=sha-256; boundary="----sig"

------sig
Content-Type: text/plain

This is the original message content.
It is readable by any email client.

------sig
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBgl...
(base64-encoded CMS SignedData)
------sig--

Encrypting a Message

The sender encrypts using the recipient's public key (from their X.509 certificate). Only the recipient's corresponding private key can decrypt:

-- Encrypted message structure --
Content-Type: application/pkcs7-mime;
  smime-type=enveloped-data;
  name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

MIAGCSqGSIb3DQEHA6CAMIA...
(base64-encoded CMS EnvelopedData)

In practice, S/MIME uses hybrid encryption: a random symmetric key (e.g., AES-128-CBC) encrypts the message, and the recipient's RSA/EC public key encrypts that symmetric key.

Key Technical Details

Certificate Requirements

S/MIME relies on X.509 certificates issued by a Certificate Authority (CA). The certificate must:

• Include the sender's email address in the Subject Alternative Name (SAN) or Subject field.
• Have the emailProtection Extended Key Usage (EKU).
• Be issued by a CA that the recipient's client trusts.

This is the biggest practical barrier to S/MIME adoption: every sender needs a certificate, and every recipient needs the sender's public certificate to verify signatures or send encrypted replies.

Algorithm Requirements (S/MIME 3.2)

SHA-1 and 3DES are still referenced for backward compatibility but are considered weak. S/MIME 4.0 updates these requirements significantly.

Certificate Discovery

For encryption, the sender needs the recipient's certificate. Common discovery methods:

• Previous correspondence: Extract the certificate from a signed message the recipient sent you.
• LDAP directory: Many organizations publish certificates in an LDAP directory.
• DNS (SMIMEA/DANE): RFC 8162 defines DNS-based certificate discovery via SMIMEA records.
• Keyserver or gateway: Enterprise S/MIME gateways manage certificates centrally.

Common Mistakes

• Confusing S/MIME with TLS. TLS protects the connection between servers. S/MIME protects the message content end-to-end. They solve different problems and should be used together.
• Using SHA-1 for signatures. SHA-1 is cryptographically broken for collision resistance. Always use SHA-256 or stronger.
• Encrypting without signing. An encrypted-but-unsigned message proves nothing about the sender's identity. Always sign before encrypting for authenticated encryption.
• Forgetting certificate distribution. You can't send encrypted email to someone if you don't have their public certificate. Plan for certificate exchange before deploying S/MIME.
• Using self-signed certificates. Recipients' clients will show trust warnings. Use certificates from a recognized CA for interoperability.
• Not handling mixed recipients. If some recipients have S/MIME certificates and others don't, you need to send the message twice: encrypted for those with certificates, plain for those without.
• Breaking DKIM with opaque signing. Opaque-signed messages restructure the MIME body, which can invalidate DKIM body hashes. Clear-signed messages are safer for DKIM compatibility.

Deliverability Impact

• S/MIME signatures can improve trust. Some enterprise mail gateways verify S/MIME signatures and treat signed messages more favorably. Microsoft Outlook prominently displays a trust ribbon for valid S/MIME signatures.
• Encrypted content is opaque to spam filters. Spam filters cannot inspect encrypted message bodies. Some filters may treat encrypted messages with suspicion, while others pass them through. For bulk email, S/MIME encryption is typically not practical.
• Not a replacement for SPF/DKIM/DMARC. S/MIME operates at the user level; SPF, DKIM, and DMARC operate at the domain level. Both layers serve different purposes. S/MIME proves individual identity; DKIM proves domain authorization.
• Enterprise compliance. Regulated industries (finance, healthcare, government) often require S/MIME. Supporting S/MIME signatures on transactional email can be a differentiator for compliance-sensitive recipients.

Related RFCs