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 --------------------- We generated a local .eml file with the correct multipart/related structure — it renders perfectly in Thunderbird. We sent the same content via MailerSend API — the received email uses multipart/mixed and the image appears as an attachment in Thunderbird. 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: 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. 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. 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.
