Incorrect formatting of html emails sent through the gmail module

[Peter_Hill]

What is your goal?

Fix the incorrect html formatting in my emails, being sent from the gmail module

What is the problem & what have you tried?

I have a gmail module configured to send an email to a specific address with a handful of html in it. The emails display correctly when viewed on a mobile device but incorrectly when viewed on a desktop email client. The html headers appear in the email when viewed on a desktop client

Error messages or input/output bundles

No error messages, the formatting is incorrect.

[Stoyan_Vatov]

Hey Peter,

Can you share some screenshots of how the module is setup and what the html looks like?

[Temi_Josh]

You can reply with:

This sounds like the Gmail module may be sending the content as plain text instead of interpreting it as HTML. I’d first check that the email body is being passed as HTML and that the Gmail module’s content type is set correctly. If the HTML is being generated in an earlier module, it’s also worth checking the actual bundle output to make sure the HTML tags are still present and haven’t been converted or escaped.

This is a safe reply because it focuses on checking the content type and bundle output rather than assuming the exact cause.

[Peter_Hill]

Sure thing - for reference, it does this whether its set to content or Raw Html. I’ve tried deleting and readding the module as well to no avail. Its pulling the data from my spreadsheet correctly, just not formatting

the information correctly.

[Stoyan_Vatov]

Can you show the output of the module as well?

Cause the body looks correct but it seems something posts stuff twice.

[Peter_Hill]

which output do you mean? Sorry, Im new to this! I thought the output was the body of the email in the previous screenshot. Here is the whole scenario

[Stoyan_Vatov]

Go in the history tab and there will be a small bubble next to the module. When you click it it will show you the input and output bundles.

[Peter_Hill]

[Peter_Hill]

[Peter_Hill]

[Stoyan_Vatov]

Can you show the body content array and the collections inside and what they look like?

It could be that something is getting sent twice.

[Peter_Hill]

[Peter_Hill]

I’ve been trying to resolve this with Claude as well, here is Claudes summary for what its worth:

Gmail “Send an email” module produces a malformed message: multipart body declared as text/plain

The module builds a complete multipart/alternative document — text alternative, boundary, HTML part, closing boundary — but sets the outer header to:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0

There is no multipart/alternative and no boundary= parameter. The MIME structure therefore ends up as literal text inside a single plain-text part. Decoded body:

    New Qualified Lead Received
    Name:pete
    ...
--boundary_1788438207
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 7bit

<html>
<body>
    <h3>New Qualified Lead Received</h3>
    ...
</body>
</html>
--boundary_1788438207--

Four things worth noting:

The module generates the text alternative itself — it’s the HTML with tags stripped — so it is genuinely attempting multipart and only failing to declare it.

The boundary is a unix timestamp (boundary_1788438207 = 2026-09-03 11:43:27 UTC), rather than the random string a standard MIME library emits.

Both Body type options produce byte-identical output — Raw HTML and Collection of contents (text, images, etc.). There is no configuration that avoids it.

Client behaviour differs, and this is why it’s easy to miss: desktop clients render it as text/plain exactly as the header instructs, so the plumbing is visible. Mobile clients sniff the HTML and render it anyway. The desktop rendering is correct; mobile is being lenient. Verifying on a phone gives a false pass.

Regression: the same scenario, unchanged, rendered correctly previously. No configuration was edited between working and broken.

Workaround attempted: switching to Make’s generic Email (SMTP) module is blocked — “Common SMTP connection can’t be used for Google accounts because of the different authorization methods” — which forces you back to the affected module.

[Peter_Hill]

bump - does anyone have any ideas as to how I can resolve this please? Or do I need to escalate it directly with Make?

[Peter_Hill]

Can anyone help with this please?

Or is there a way of escalating this to Make themselves?

[samliew]

This might be an outlook bug, or may be as-intended.

Outlook relies strictly on multipart/alternative to choose between plain text and inline HTML^[1]

I did a test and got the same results.

My recommendation is to use the Raw HTML option if you are planning to send only HTML, as you aren’t sending more than one item in the “collection”.

Hope this helps! If you are still having trouble, please provide more details.

-– @samliew

---

1. Source: Outlook decoding - #7 by afroz-stellar - Email - Spiceworks Community ↩︎

[Dmitrkoliga]

@Peter_Hill

What is your goal?

Fix the incorrect html formatting in my emails, being sent from the gmail module

What is the problem & what have you tried?

I have a gmail module configured to send an email to a specific address with a handful of html in it. The emails display correctly when viewed on a mobile device but incorrectly when viewed on a desktop email client. The html headers appear in the email when viewed on a desktop client

Error messages or input/output bundles

No error messages, the formatting is incorrect.

I’d check the actual MIME/output first rather than the HTML itself. If the mobile version looks correct but desktop shows the HTML headers, it may be that the Gmail module is declaring the message as text/plain instead of multipart/alternative. I’d open the module’s output bundle from the scenario history and check the Content-Type there. That should help confirm whether the issue is with the HTML or how Gmail is building the email.