What this RFC defines
RFC 5751 defines S/MIME version 3.2, the standard for signing and encrypting email messages using X.509 public key certificates. S/MIME provides end-to-end authentication via signatures and confidentiality via encryption at the message level, independent of the transport layer.
Where you see it in practice
Corporate email environments that require digitally signed emails for compliance or legal purposes use S/MIME as defined by RFC 5751. When a bank or financial institution sends you a signed email that shows the sender’s verified identity in your email client, it is using an S/MIME certificate following this RFC. S/MIME requires both sender and recipient to have X.509 certificates, which limits its adoption outside enterprise environments.
How it connects to other RFCs
RFC 5751 obsoletes RFC 3851. It builds on RFC 1847 (MIME security multiparts), RFC 2045 (MIME), and RFC 5322 (message format). It uses X.509 certificates as defined by PKIX standards. S/MIME is distinct from PGP/MIME, which uses OpenPGP keys rather than X.509 certificates for the same purpose.
Current status
RFC 5751 is a current standard, published January 2010. S/MIME remains widely deployed in enterprise and government environments. A successor (S/MIME 4.0, RFC 8551) was published in 2019 with updated algorithm requirements; new deployments should reference RFC 8551 for current cryptographic standards.
S/MIME version 3.2
RFC 5751 defined S/MIME (Secure/Multipurpose Internet Mail Extensions) version 3.2 in January 2010, providing message-level signing and encryption using X.509 certificates. Unlike TLS, which encrypts the transport hop-by-hop, S/MIME encrypts the message itself, so the content remains protected at rest and across intermediaries. S/MIME uses CMS (Cryptographic Message Syntax, RFC 5652) for the underlying signature and encryption format, wrapped in MIME parts of type multipart/signed and application/pkcs7-mime.
Deployment reality
S/MIME sees significant use in enterprise environments where a central authority manages certificates for all users. Microsoft Outlook has built-in S/MIME support; enterprise Exchange deployments frequently use it. Consumer adoption is negligible because obtaining a personal S/MIME certificate requires manual enrollment, and mobile mail clients have inconsistent support. PGP (via OpenPGP RFC 4880) is the alternative message-level encryption format, more common in technical and privacy-focused communities.
Superseded by RFC 8551
RFC 5751 was obsoleted by RFC 8551 in April 2019, which defined S/MIME 4.0. The updated version added stronger cryptographic algorithms (SHA-256 minimum, deprecating SHA-1), improved handling of forwarded and modified messages, and clarified various operational details. If your application uses S/MIME 3.2, upgrading to 4.0 is recommended for improved cryptographic hygiene. The wire format changes are minor; the security improvements are significant.
RFC 5751 (January 2010) defines S/MIME (Secure/Multipurpose Internet Mail Extensions) version 3.2: end-to-end email encryption and signing using X.509 certificates and CMS (Cryptographic Message Syntax). Provides confidentiality (encrypt to recipient’s public key), integrity (digital signatures), authentication (identity via certificate), and non-repudiation. Obsoleted by RFC 8551 (S/MIME 4.0) in April 2019. Reference RFC 8551 for current specification. Widely deployed in enterprise, government, and regulated industries (healthcare, finance, defense).
RFC 5751 at a glance
| Aspect | Detail |
|---|---|
| Purpose | End-to-end email encryption and digital signatures |
| Version | S/MIME 3.2 |
| Trust model | X.509 PKI (certificate authorities) |
| Format | CMS (RFC 5652), wrapped as application/pkcs7-mime or multipart/signed |
| Superseded by | RFC 8551 (S/MIME 4.0, April 2019) |
| Published | January 2010 |
| Alternative to | PGP/OpenPGP (web-of-trust model) |
S/MIME operations
| Operation | Content-Type | What it provides |
|---|---|---|
| Sign (opaque) | application/pkcs7-mime; smime-type=signed-data | Signature; body wrapped in signed CMS envelope |
| Sign (clear) | multipart/signed with application/pkcs7-signature part | Signature separate from readable body |
| Encrypt | application/pkcs7-mime; smime-type=enveloped-data | Confidentiality; body encrypted to recipient’s certificate |
| Sign then encrypt | enveloped(signed) nested CMS | Confidentiality + integrity + authentication |
| Encrypt then sign | signed(enveloped) nested CMS | Less common; useful for gateway signing over encrypted content |
Changes from RFC 5751 (S/MIME 3.2) to RFC 8551 (S/MIME 4.0)
| Aspect | S/MIME 3.2 (RFC 5751) | S/MIME 4.0 (RFC 8551) |
|---|---|---|
| Signature algorithms | RSA, DSA, ECDSA (SHA-1, SHA-256 acceptable) | SHA-1 deprecated; RSA-PSS added; EdDSA supported |
| Encryption algorithms | AES-128 mandatory, AES-256 optional; 3DES legacy | AES-128 GCM and AES-256 GCM added; ChaCha20-Poly1305 optional |
| Key wrap | RSA (PKCS#1 v1.5), RSA-OAEP optional | RSA-OAEP mandatory; ECDH added |
| Message digest | SHA-1, SHA-256 recommended | SHA-256 minimum; SHA-3 optional |
| Certificate handling | X.509 | Same, with modern extensions |
S/MIME vs PGP/OpenPGP
| Aspect | S/MIME | PGP/OpenPGP |
|---|---|---|
| Trust model | PKI: certificates issued by trusted CAs | Web of trust: users sign each other’s keys |
| Client support | Widely built into corporate mail clients (Outlook, Apple Mail); native | Add-on required for most clients (Enigmail, Mailvelope, GPG Suite) |
| Deployment | Enterprise, government, regulated industries | Individual privacy-conscious users, journalism, activism |
| Key acquisition | Enterprise directory, LDAP, business card exchange | Keyserver upload, in-person verification |
| Message format | CMS-based (application/pkcs7-mime, multipart/signed) | OpenPGP (multipart/encrypted, multipart/signed with application/pgp-signature) |
| Interoperability | Requires trusted CA in receiver’s trust store | Requires sender’s public key in receiver’s keyring |
Common S/MIME mistakes
Related standards and further reading
- RFC 8551: S/MIME 4.0 (current standard, obsoletes RFC 5751)
- RFC 8550: S/MIME 4.0 certificate handling
- RFC 5652: CMS (Cryptographic Message Syntax, foundational)
- RFC 5750: S/MIME 3.2 certificate handling (obsoleted by RFC 8550)
- RFC 3369: CMS predecessor
- SSL/TLS Email Setup Guide: transport encryption vs S/MIME end-to-end
Frequently asked questions
Should I use S/MIME or wait for RFC 8551 S/MIME 4.0?
Deploy RFC 8551 (S/MIME 4.0) for new implementations. It supersedes RFC 5751 with modern crypto (SHA-256 minimum, RSA-OAEP required, EdDSA supported, AES-GCM). RFC 5751 remains functional but uses aging cryptographic primitives. If your application uses S/MIME 3.2, upgrading to 4.0 is straightforward: wire format is nearly identical.
What is the difference between opaque and clear signing?
Opaque signing (application/pkcs7-mime; smime-type=signed-data) wraps the entire message in a signed CMS envelope; recipients without S/MIME capability see an unreadable attachment. Clear signing (multipart/signed with a separate signature part) keeps the readable body accessible; recipients without S/MIME see the body but not verify the signature. Prefer clear signing for wider readability, opaque for strict envelope preservation.
How does S/MIME compare to TLS transport encryption?
Different scope. TLS (RFC 3207) encrypts hop-by-hop transit; intermediaries see plaintext. S/MIME encrypts end-to-end from sender’s client to recipient’s client; intermediaries never see plaintext. TLS is universal; S/MIME requires certificates on both ends. Complementary: TLS for baseline transport security, S/MIME when end-to-end confidentiality is required (regulated data, legal privilege, sensitive personal information).
Do web-based mail services support S/MIME?
Enterprise offerings (Microsoft 365 Enterprise, Google Workspace with S/MIME setup) yes. Consumer webmail (Gmail personal, Yahoo, Outlook.com personal) generally no; end-to-end encryption from a webmail interface requires client-side crypto that consumer services do not typically provide. Users needing S/MIME on personal mail typically use desktop or mobile clients (Apple Mail, Outlook, Thunderbird with Enigmail).
What replaces S/MIME 3.2 for regulated industries?
S/MIME 4.0 (RFC 8551) is the natural upgrade path with modern crypto. Some regulated environments have specific certificate authority requirements (government-issued CAs, DoD PKI). The 4.0 upgrade is generally straightforward, with wire compatibility preserved for message format while cryptographic primitives are strengthened. Consult regulatory guidance for your industry for specific requirements.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
