RFC 2392: Content-ID and Message-ID Uniform Resource Locators

Defines cid: and mid: URI schemes for referencing MIME parts within a message, used in HTML emails with embedded images.
Alaa
By Alaa
SMTPedia documents email infrastructure end to end: SMTP standards from the RFC archive, delivera...
8 min read Updated Jul 22, 2026 117 views
RFC 2392
Content-ID and Message-ID Uniform Resource Locators
Current standard
Domain
MIME
Published
August 1998
Supersedes
First in series
SMTP relevance
Medium
↗ Read on rfc-editor.org

What this RFC defines

RFC 2392 defines two URI schemes for referencing parts of email messages: cid: (Content-ID) for referencing a specific MIME part within the same message, and mid: (Message-ID) for referencing an entire email message. These URIs enable HTML email to reference embedded images by their Content-ID rather than external URLs.

Where you see it in practice

When an HTML email contains an embedded image stored as a MIME attachment within the message itself (rather than hosted on a web server), the img src attribute uses a cid: URI like src=”cid:image001@example.com”. The MIME part containing the image has a matching Content-ID: <image001@example.com> header. This technique avoids external image tracking pixels and allows images to display even without network access.

How it connects to other RFCs

RFC 2392 works within the MIME framework defined by RFC 2045 and RFC 2046 (multipart/related). The cid: scheme references Content-ID values defined in RFC 2045. The mid: scheme references Message-ID values defined in RFC 5322. Together they provide a linking mechanism between email parts.

Current status

RFC 2392 is a current standard, published August 1998. CID-referenced embedded images remain a common technique in HTML email, particularly for corporate email signatures and newsletters that want images to display without external requests. Email client support is universal.

CID and MID URLs

RFC 2392 defined two URL schemes for referring to email content: cid: (Content-ID) URLs point to a specific MIME part within the current message, and mid: URLs point to another message by Message-ID. The cid: scheme is the mechanism that lets HTML email display inline images: the img tag src=”cid:image1@example.com” tells the mail client to look for a MIME part with Content-ID: . Without this, HTML email would need to reference external image URLs, which triggers privacy warnings.

Inline image implementation

Every HTML email marketing platform, transactional email system, and mail client that renders inline images uses cid: URLs per RFC 2392. The construction requires several coordinated pieces: the HTML body references cid:UNIQUE-ID, the corresponding MIME part sets Content-ID: , the part uses Content-Disposition: inline, and the multipart type is multipart/related (RFC 2387). Any of these pieces missing or misconfigured causes broken images or unexpected attachment prompts.

MID URLs in practice

The mid: URL scheme is far less common than cid:. It sees limited use in mail archives (linking one message to another by Message-ID) and in message search interfaces. Some enterprise systems use mid: URLs for compliance references (linking a policy notification to the original triggering message). For consumer email use, mid: URLs are largely unused; cid: URLs dominate.

Quick Reference

RFC 2392 (August 1998) defines the cid: and mid: URL schemes: syntax for referencing MIME body parts by Content-ID (cid:) and messages by Message-ID (mid:). Foundation for HTML emails with embedded images (the <img src="cid:logo123@example.com"> pattern). Nearly universal in transactional and marketing email; enables logos, product images, and inline graphics without external hosting. Companion to Content-Disposition.

RFC 2392 at a glance

AspectDetail
PurposeURL syntax for referencing MIME parts by Content-ID and messages by Message-ID
cid: schemeReference a MIME part in the same message
mid: schemeReference a specific message (rare use)
Companion headerContent-ID (identifies the referenced part)
Related MIME typemultipart/related (RFC 2046)
PublishedAugust 1998

HTML email with embedded images

HTML email with cid: embedded image Message structure:Content-Type: multipart/related; boundary=”—=related”—–=related Content-Type: text/html<html> <body> <p>Welcome to our newsletter</p> <img src=”cid:logo123@example.com” alt=”Company logo”> <p>Best regards, the team</p> </body> </html>—–=related Content-Type: image/png Content-Disposition: inline; filename=”logo.png” Content-ID: <logo123@example.com> Content-Transfer-Encoding: base64iVBORw0KGgoAAAANSUhEUgAAA… [base64 encoded PNG data]—–=related–How it works: 1. HTML img src=”cid:logo123@example.com” references a Content-ID 2. Mail client parses HTML; encounters cid: URL 3. Client searches sibling parts for matching Content-ID header 4. Finds application/pkcs7-mime or image/png part with Content-ID: <logo123@example.com> 5. Renders that part inline in place of the img elementRules: – Content-ID is enclosed in angle brackets in the header – cid: URL omits the angle brackets – Match is case-sensitive (typically) – Uses multipart/related to group the HTML with its referenced parts

The mid: URL scheme (rare)

mid: URL to reference a specific message Syntax: mid:message-id (whole message) mid:message-id/content-id (specific part in a specific message)Example: mid:abc123@example.comUse case: Referencing a specific message from another message. Used occasionally by mail archive systems or reply-chain automation. Consumer email clients rarely follow mid: links.A compliance policy might attach a report about a specific message with: <a href=”mid:abc123@example.com”>original message</a>For consumer email use, mid: URLs are largely unused; cid: URLs dominate for embedded content.

Common cid: implementation mistakes

Angle brackets in the cid: URL. The Content-ID header includes angle brackets: Content-ID: <logo@example.com>. The cid: URL does NOT include them: cid:logo@example.com. Emitting angle brackets in the URL breaks the reference.
Case mismatch in Content-ID. Typical mail clients require case-sensitive match. Emitting Content-ID: <Logo123@example.com> and cid:logo123@example.com may fail to resolve. Use consistent case; lowercase is convention.
Using multipart/mixed instead of multipart/related. multipart/mixed treats attached images as separate downloadable attachments rather than parts of the HTML body. HTML img src=”cid:…” may or may not resolve. multipart/related is the correct wrapper for HTML with embedded images.
Not using both multipart/related and multipart/alternative. Well-formed HTML+text emails with embedded images use nested structure: multipart/alternative(text/plain, multipart/related(text/html, embedded images)). Common shortcut: multipart/related with only HTML skips the plain text alternative. Emit both for maximum compatibility.
Broken cid: references from image editing tools. Some HTML email builders generate cid: URLs that do not match Content-ID headers of attached images. Result: broken image icons in the rendered email. Always verify cid: URLs match their target Content-ID during template testing.
MIME family RFCs
  • RFC 2045: MIME base headers (Content-ID defined here)
  • RFC 2046: Media types (multipart/related used for cid: references)
  • RFC 2183: Content-Disposition (attachment metadata companion)
URL and message structure standards
  • RFC 3986: URI syntax (base URL specification)
  • RFC 5322: Message Format (Message-ID defined here)
SMTPedia companion guides

Frequently asked questions

Should I use cid: URLs or hosted images in HTML email?

Depends on trade-offs. cid: URLs embed the image in the message (guaranteed to display, larger message size, works offline). Hosted images link to a URL (smaller message, tracking pixels possible, may not display if images are blocked). Modern practice: use cid: for critical branding elements (logos), hosted for content images (product photos, hero images). Many bulk senders use hosted only, accepting the blocked-images cost for reduced message size.

Why do embedded images sometimes not display?

Common causes: (1) cid: URL does not match Content-ID header (case mismatch, angle brackets, typo), (2) wrong MIME wrapper (multipart/mixed instead of multipart/related), (3) mail client blocks embedded images per user preference, (4) image part missing from message. Test with mail-tester.com or similar tools to catch structure issues before deploying.

Can I use cid: URLs in CSS?

Yes, in inline style attributes: <div style="background-image: url(cid:pattern@example.com)">. Mail client CSS support is limited; test across clients. External stylesheets are typically not supported in email regardless. Inline styles are the standard approach.

Are mid: URLs used for anything in modern email?

Rarely. Consumer mail clients typically do not follow mid: links. Occasional use in mail archive systems (reference to a specific archived message), compliance/legal reporting (linking policy notices to originating messages), and some enterprise workflow tools. For consumer email use, mid: URLs are largely unused; cid: URLs dominate for embedded content.

What is the security model for cid: URLs?

Local to the message; no external resource loaded. A cid: URL resolves within the current message’s parts and cannot reach the network. Safe from external tracking or content-injection perspectives. Contrast with hosted images (external URL): those can track opens via image loads. cid: images do not enable open tracking; that is a trade-off many bulk senders explicitly accept by using hosted.


About the Author

Alaa - SMTPedia 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.