What this RFC defines
RFC 1847 defines two MIME multipart subtypes for message security: multipart/signed and multipart/encrypted. These provide the container format for email messages that carry a cryptographic signature or are encrypted, allowing the security layer to be applied to any MIME content type without restricting the content encoding.
Where you see it in practice
When you receive a digitally signed email from a corporate sender that your mail client shows with a certificate icon or verified sender badge, the outer message structure is a multipart/signed container as defined by RFC 1847. The structure contains the original message content as the first part and the detached signature as the second. S/MIME (RFC 5751) and PGP/MIME both use the multipart/signed and multipart/encrypted types defined here.
How it connects to other RFCs
RFC 1847 is the MIME framework for message security. RFC 5751 (S/MIME) and OpenPGP’s MIME profile both build on the multipart/signed and multipart/encrypted types defined here. It works within the MIME framework of RFC 2045 and RFC 2046. RFC 1847 defines the container; the signature and encryption algorithms are defined by the specific security protocols that use it.
Current status
RFC 1847 is a current standard, published October 1995. Despite its age, it remains the definitive specification for MIME security multiparts and has not been superseded. S/MIME and PGP/MIME implementations continue to rely on its container format.
Secure multipart formats
RFC 1847 defined two secure MIME multipart formats: multipart/signed (a body part plus its cryptographic signature as a second part) and multipart/encrypted (encryption control info plus the encrypted payload). Published in October 1995, this document is the structural foundation used by both S/MIME (RFC 5751 later, then RFC 8551) and PGP/MIME (RFC 3156). Any signed or encrypted email you have ever received uses one of these multipart structures.
Multipart/signed structure
A multipart/signed message has three parameters in its Content-Type: protocol (the signature format, e.g., application/pgp-signature or application/pkcs7-signature), micalg (the hash algorithm used, e.g., sha256), and boundary (as with any multipart). The body has exactly two parts: the signed content (which is normal MIME) and the signature (which is opaque cryptographic data). Verifiers hash the signed content and check the signature against the expected key.
Practical deployment
Multipart/signed is preferred over inline signing because it lets clients that do not understand the signature format still display the signed content correctly. If a recipient without S/MIME or PGP support receives a multipart/signed message, they see the signed part rendered normally and the signature as an unfamiliar attachment they can ignore. This graceful degradation is why RFC 1847 multipart format won over embedded formats where the signature is intermixed with the content. Every modern signed email you receive follows the RFC 1847 layout.
RFC 1847 (October 1995) defines the Security Multiparts framework: two MIME content types (multipart/signed and multipart/encrypted) used by both S/MIME and PGP/OpenPGP to carry cryptographic protection. Separates the protected content from the cryptographic metadata (signature or encrypted key), letting mail clients without security awareness still display the content while security-aware clients verify or decrypt. Foundation for all modern signed and encrypted email.
RFC 1847 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Define MIME structure for signed and encrypted email |
| Two types | multipart/signed and multipart/encrypted |
| Used by | S/MIME (RFC 5751, RFC 8551) and PGP/OpenPGP (RFC 4880, RFC 3156) |
| Key benefit | Content readable by non-security-aware clients; security verified by aware clients |
| Published | October 1995 |
multipart/signed structure
multipart/encrypted structure
Why the multipart approach won
| Approach | Behavior with legacy clients | Behavior with security-aware clients |
|---|---|---|
| multipart/signed (RFC 1847) | Show readable body; ignore signature part | Verify signature over body |
| Opaque signing (single application/pkcs7-mime with signed-data) | Show “attachment cannot be displayed” | Extract body from signed envelope, verify, display |
Common Security Multipart mistakes
Related standards and further reading
- RFC 5751: S/MIME 3.2
- RFC 8551: S/MIME 4.0 (current)
- RFC 4880: OpenPGP
- RFC 3156: MIME Security with OpenPGP
Frequently asked questions
What is the difference between multipart/signed and DKIM signing?
Different scope and purpose. multipart/signed (RFC 1847) signs the message body content end-to-end from sender to recipient; used by S/MIME and PGP. DKIM (RFC 6376) signs specified headers plus body hash for domain-level authentication; used for anti-spoofing at the sending domain level. multipart/signed is content-level; DKIM is transport-level. They are complementary; a message can carry both.
Why does multipart/signed break in mailing lists?
Mailing lists modify messages: add [ListName] to Subject, add footers to body, add List-* headers. The signature covers exact content bytes; any modification invalidates it. Options: (1) list signs with its own key (replacing sender’s signature), (2) list preserves body exactly (rare), (3) list uses ARC to preserve original authentication verdicts. Combining signing with list-friendly behavior is challenging.
Should I use multipart/signed or opaque S/MIME signing?
multipart/signed for most cases. Non-security-aware clients see readable body; aware clients verify signature. Opaque signing hides body from unsupported clients, providing no fallback. Choose opaque only when you specifically need to prevent unsigned reading of the content (rare in email; more relevant for document workflows).
Can multipart/encrypted contain a multipart/signed inside?
Yes; this is the sign-then-encrypt pattern. Structure: multipart/encrypted with an inner multipart/signed, providing both signature and confidentiality. Decrypt first, then verify. Very common in secure email deployments. Alternative encrypt-then-sign (signed outside encrypted) is less common but useful for gateway signing over encrypted content.
Is RFC 1847 still current?
Yes. RFC 1847 has not been superseded; the multipart/signed and multipart/encrypted types it defines remain the foundation for signed and encrypted email in 2026. The specific security protocols using them (S/MIME, PGP) have evolved, but the multipart framework is stable. New implementations should target RFC 1847 for the multipart structure alongside their chosen security protocol.
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.
