Q
Quaint Opossum
Dear MailerSend Support Team,
We are using the MailerSend REST API (POST /v1/email) to send HTML emails with inline images via Content-ID (CID), following the documentation at:
https://developers.mailersend.com/guides/adding-attachments-to-emails.html
WHAT WE SEND
-------------
Our API payload includes an inline attachment with "disposition": "inline" and "id" field, exactly as documented:
{
"from": { "email": "sender@ourdomain.com", "name": "Our Company" },
"to": [{ "email": "recipient@example.com" }],
"subject": "Test inline image",
"html": "<p>Logo:</p><img src='cid:logo0'/>",
"attachments": [{
"id": "logo0",
"filename": "logo0.jpg",
"content": "<base64-encoded JPEG>",
"disposition": "inline"
}]
}
THE PROBLEM
-----------
When the email is delivered, the MIME structure generated by MailerSend is:
multipart/mixed
├── text/html (contains src="cid:logo0")
└── image/jpeg (Content-ID: <logo0>)
According to RFC 2387, for CID references to be resolved by email clients, inline images must be wrapped in a multipart/related container:
multipart/related
├── text/html
└── image/jpeg
Because MailerSend uses multipart/mixed, strict RFC-compliant clients such as Mozilla Thunderbird display the image as a downloadable attachment instead of rendering it inline within the HTML body. Gmail renders it correctly only because it applies non-standard heuristics to resolve CID references regardless of the MIME container type.
HOW WE VERIFIED THIS
---------------------
  1. We generated a local .eml file with the correct multipart/related structure — it renders perfectly in Thunderbird.
  2. We sent the same content via MailerSend API — the received email uses multipart/mixed and the image appears as an attachment in Thunderbird.
  3. We also tested via MailerSend SMTP relay — the multipart/related structure we constructed was stripped entirely, and the image MIME part was removed from the delivered message.
REQUEST
-------
We would appreciate your guidance on one of the following:
  1. If there is an existing workaround or a specific API parameter/configuration that allows inline CID images to be delivered inside a multipart/related container, please let us know.
  2. If no such option is currently available, could you please clarify why the SMTP relay strips the multipart/related structure and why the API wraps inline attachments in multipart/mixed instead of multipart/related? Your documentation explicitly supports inline disposition with Content-ID references, yet the resulting MIME structure prevents them from working on RFC-compliant clients.
  3. If this is a known limitation, we kindly request that the email generation logic be updated so that attachments with "disposition": "inline" are placed inside a multipart/related container, as required by RFC 2387. This would ensure CID inline images render correctly across all major email clients, not just those that apply non-standard heuristics.
We are happy to provide the raw email sources (both the correctly structured .eml and the MailerSend-delivered version) for your analysis if needed.
Thank you for your attention. We are happy to provide raw email sources or additional details if needed.