Using MIME Multipart to Send Email with Both HTML and Plain

Why send both HTML and plain text in every email?

You’re not just sending an email—you’re trying to get your message read. But not all email clients render HTML the same. Some block it by default. Others fail to load images or styles. And some users, for privacy or accessibility reasons, have HTML turned off entirely.

If your email is only HTML, it might never be seen as intended—or worse, it might not be seen at all. That’s why every professional email should include both HTML and plain text, wrapped in MIME multipart format. It’s not a suggestion. It’s how you ensure your message lands, consistently.

MIME multipart is the standard way to send a single email with two versions: one rendered beautifully for clients that support it, and a plain version that works anywhere, anytime. It’s the technical backbone of reliable email delivery.

Key takeaways

MIME multipart packaging ensures every recipient gets a readable version, whether HTML is supported or disabled.
HTML-only emails risk being unreadable on 8–15% of client setups, especially in corporate or privacy-focused environments.
Reputable email clients and servers expect both text and HTML components in well-formed MIME messages, which supports better deliverability and inbox placement.

What is MIME multipart and how does it work?

You can send an email with both HTML and plain text content by using MIME multipart—part of the email standards that defines how messages are structured. Each part is encoded separately, with its own content type (like text/plain or text/html), and separated by a unique boundary string. The email client picks the best part to display based on the recipient’s email reader and settings. This ensures readability across all devices and clients, even if HTML isn’t supported.

The structure of a MIME multipart email

When you send a message with both HTML and plain text, they’re not combined into a single blob. Instead, they exist as distinct parts inside the same MIME container. The main message header includes a Content-Type: multipart/alternative field, which tells the receiving system to expect multiple versions of the same content.

Each part starts with a boundary line, like --boundary12345, and contains a content-type header specifying whether it’s plain or HTML. The body of that part follows, and the next boundary marks the start of the next part. This structure is defined in RFC 2046, the standard that governs MIME.

Let’s say your email has a simple offer. The HTML part renders a rich version with images and links. The plain text part is a clean, readable version of the same message—ideal for users who disable HTML or use screen readers. The email client automatically chooses the best version, but you still control the content.

Why this setup matters

Without MIME multipart, you’d either send only HTML (risky for deliverability and accessibility) or only plain text (limiting design). Using both ensures broader compatibility. Major email providers like Gmail, Outlook, and Apple Mail rely on this structure to render messages correctly.

Even if you’re using a tool like bulk verification to clean your list before sending, or the email verification API to validate addresses in real time, the final delivery depends on the email format. A well-formed multipart message reduces the chance of misinterpretation by servers or filters, helping keep your message in the inbox.

You don’t have to write the full MIME structure manually, especially if you’re using a trusted email service. But understanding the underlying mechanics helps you troubleshoot issues like missing text or incorrect rendering. When in doubt, check how your email client displays the message—real-world testing is key.

For teams sending email at scale, testing inbox placement with tools like inbox placement tests can confirm that both parts are being delivered and rendered correctly. That’s as much about content format as it is about sender reputation—both matter.

How to structure a MIME multipart email correctly

You must start with a multipart/alternative content type, use a unique boundary that doesn’t appear in the message, list plain text before HTML, and end with a closing boundary. This ensures compatibility across clients and protects against rendering issues when HTML fails.

Choose a unique boundary identifier—like --boundary-12345—that doesn’t appear in your message body. Avoid common patterns or values like -- or ===, which might appear in actual content and break parsing.According to RFC 2046, the boundary must be a string that does not occur in the message content, ensuring the parser can properly separate parts.
Set the Content-Type header to multipart/alternative; boundary="boundary-12345". This signals to email clients that multiple versions of the same content exist, and they should pick the best available format.It’s a widely supported standard across modern email clients and delivery systems.
Place the plain text version first. This matters: many older clients or those with accessibility settings disabled don’t render HTML, so the plain version is the fallback.Let’s be clear—HTML comes second. That’s not arbitrary. It aligns with how clients prioritize rendering.
Follow the plain text part with the HTML part. Use Content-Type: text/html and include valid HTML. Don’t skip the Content-Transfer-Encoding: quoted-printable or 8bit if needed—this ensures encoding is preserved safely.
End the entire message with the boundary followed by --. This closes the multipart block. Without it, the parser treats the message as incomplete, leading to delivery failures or malformed rendering.Some systems, especially on the receiving end, will reject emails missing a proper closing boundary.

Why order matters

Putting plain text before HTML isn’t just tradition. It’s a design choice rooted in backward compatibility. If a client can’t process HTML, it will fall back to plain text. If the order is reversed, it may try to render HTML first and fail silently.

Common pitfalls to avoid

Reusing boundaries across different messages or threads.
Using non-printable characters in boundaries.
Forgetting to close the multipart block with --boundary--.
Having a boundary string that appears as plain text in the content.

When building or debugging, use a tool like MxToolbox to validate MIME structure. It’s also worth verifying email lists early—outdated or invalid addresses won’t deliver properly, regardless of MIME quality. Check your list health with bulk verification before sending.

Example of a properly formatted MIME multipart email

You can send a single email with both plain text and HTML content by using the multipart/alternative content type. This tells receiving mail clients to choose the best version to display—HTML if supported, plain text as a fallback. The boundary delimiter separates the parts, and each part must specify its own content type and charset.

Structure and syntax

Start with Content-Type: multipart/alternative; boundary="boundary-12345". The boundary must be unique and consistently used. Every part begins with --boundary-12345, followed by headers and content.

The first part should be plain text. It uses text/plain; charset="utf-8" to ensure readable characters across devices. This is the fallback for clients that don’t support HTML.

The second part uses text/html; charset="utf-8" for the rich content. It can include bold, links, images, and styling. Both parts must be self-contained—no external references like img src="http://example.com/logo.png" in HTML without proper MIME standards.

Complete example

Here’s a working sample:

--boundary-12345 Content-Type: text/plain; charset="utf-8" Hello, this is a plain text email. --boundary-12345 Content-Type: text/html; charset="utf-8"

Hello, this is an HTML email.--boundary-12345--

Notice how each part is clearly delineated and ends with the boundary. The final boundary ends with -- to signal the end of the message.

Using this format ensures your email is readable by all clients, including older email software, screen readers, and email clients that block HTML by default. It’s an industry-standard practice.

If you're sending campaigns at scale, verifying your email list is critical. Invalid or malformed addresses hurt deliverability. You can clean your list before sending with bulk verification or integrate real-time checks via the verification API.

Common mistakes when using MIME multipart

You're sending email with both HTML and plain text using MIME multipart, but your users still get jumbled content or fail to receive messages. The most common issues? Reusing boundaries, omitting the final terminator, placing HTML before plain text, or using boundary strings that clash with message content. These mistakes break parsers and hurt deliverability — even if your email looks fine in testing.

Boundary and structure errors

Reusing the same boundary string across multiple messages or parts causes parsing conflicts. Each email should have a unique boundary, generated dynamically per message.
Omitting the final boundary terminator (--) at the end of the message breaks the MIME structure. Without it, receivers can't detect the end of the body, leading to malformed content.
Using a boundary string that appears literally in the email body — such as a sequence like "----" or "boundary" — can cause the parser to stop early. Always use a randomly generated, non-repeating string (e.g., ----=_NextPart_000_001A_01234567).

Content order and fallbacks

Placing HTML before plain text breaks the fallback principle. If a user disables HTML, they’ll see raw markup or nothing at all. Always place plain text first, then HTML, in the content order.
Choosing a non-unique or predictable boundary string (e.g., ----Boundary) increases the risk of collisions. Use a cryptographically random or timestamp-based string to ensure uniqueness.
Some older clients or strict validators (like those at RFC 2046) reject messages where the MIME structure is ambiguous. Always follow strict format rules.

Even small mistakes in MIME structure lead to real-world problems: bounces, delivery failures, or messages being flagged as spam. Tools like bulk verification help catch issues early by validating email infrastructure — not just addresses, but how messages are formatted at the protocol level.

Why accurate email list hygiene supports MIME multipart success

You can send a perfectly formatted MIME multipart email with HTML and plain text, but if it goes to an invalid or non-deliverable address, you waste bandwidth, hurt your sender reputation, and increase the risk of being flagged as spam. Validating your list first ensures every message reaches a real inbox, not a dead end.

Bounces don’t just fail — they damage deliverability

Every bounce — soft or hard — signals something is wrong. If a significant portion of your messages hit invalid addresses, ISPs and email providers take note. High bounce rates are a red flag, often leading to throttling or outright blocking. This is especially true for complex messages like MIME multipart, which require more processing and increase risk if sent to addresses that can’t receive them.

Digital deliverability standards, like those from the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), emphasize that consistent sending to invalid addresses undermines sender reputation. The more bounces you generate, the more likely you are to be placed on a blocklist, even if your content is clean.

Verify before you send — it’s not optional

Let’s be clear: sending HTML and plain text via MIME doesn't fix a broken list. It’s a technical strength, not a deliverability substitute. The foundation of successful email delivery is a clean, validated list. Remove invalid, catch-all, and disposable email addresses before sending — especially when including rich content that may trigger stricter filtering.

Bulk verification tools can identify these bad addresses at scale. You can test your entire list in minutes with bulk verification, which flags invalid, role-based, and disposable domains. This step is as essential as checking your SMTP settings.

For ongoing campaigns, use the real-time verification API to validate every new address as it enters your system. This prevents invalid entries from ever reaching your send queue.

Ultimately, MIME multipart isn’t a deliverability win on its own. It’s a delivery tool. Clean data is what enables it to work. Without accurate hygiene — the kind that uses real-time checking and bulk validation — even the most well-crafted email will fail to land in the inbox.

For insight into what your list actually looks like, try inbox placement testing to measure how well your properly formatted messages perform across major providers.

How to verify email lists before sending MIME multipart content

You should verify every email address in your list before sending MIME multipart emails—especially those with HTML and plain text components. Invalid, catch-all, or disposable addresses disrupt delivery and hurt sender reputation. Use a reliable tool to filter out bad, risky, or non-deliverable entries. Even small errors in your list reduce inbox placement and trigger spam filters. A clean list saves time, improves engagement, and keeps your sender reputation healthy.

Start with a full list verification process

Run your full list through an email verification service. This checks syntax, domain validity, and whether the mailbox exists. Tools like Emaillistchecker.io flag invalid or malformed addresses before you waste sends.
Filter out catch-all addresses. Catch-alls accept all incoming mail, but they’re often used for spam trapping. They can’t deliver properly and may harm your reputation. Many verification tools identify these with a “catch-all” verdict.
Remove role-based accounts (e.g., sales@, admin@). These are frequently used by bots, automated systems, or non-personal users. They may not open emails, respond, or trigger accurate engagement metrics. They also increase the risk of bounces and spam complaints.
Block disposable email domains. Services like temp-mail.org or 10minutemail.com create short-lived inboxes. They’re common in bots and spam. These addresses typically don’t support rich HTML rendering, and many bounce silently. Always reject them during verification.
Test your list’s deliverability with inbox placement tools. Even if an address is valid, it may land in spam. Use a service like inbox placement testing to simulate real delivery and catch issues early.

Use your verified list with confidence

Once you’ve cleaned your list, sending MIME multipart emails becomes predictable. The HTML component displays properly in capable clients, the plain text fallback works, and delivery rates improve. This structure is reliable only when the underlying data is clean. As a rule of thumb: if your list isn't verified, the content you're sending—no matter how well-designed—will never reach its intended audience.

Industry-standard practices, like those described in RFC 2822, require strict formatting and address validation. Ignoring verification breaks email standards and risks blocking by modern filters. The cost of sending to invalid or non-deliverable addresses—both in wasted resources and damaged sender reputation—far exceeds the cost of verification.

Use your list only after verification. For scale, integrate Emaillistchecker.io's real-time API into your workflow. It checks addresses at point of entry, keeping your database clean from day one.

The role of deliverability testing in MIME multipart email success

Even perfect MIME multipart formatting won’t guarantee inbox delivery if your sender reputation is poor. Your email might parse correctly, but it’ll land in spam or be throttled unless your domain and IP have a clean track record. Testing inbox placement with real inboxes across Gmail, Outlook, and Yahoo is the only way to confirm your messages actually arrive where they should.

Why formatting alone isn’t enough

Deliverability isn’t just about structure—it’s about trust. A well-formed MIME message with both HTML and plain text components will render properly if it reaches the inbox. But if your domain is on a blocklist or has a history of bounces, that same email may be silently discarded or flagged. The MIME format guarantees content clarity; it doesn’t guarantee delivery.

Spam filters evaluate sender reputation using signals like IP history, engagement rates, and complaint volume. Even a single malformed header can trigger suspicion, but so can sending to a list full of inactive or invalid addresses. The quality of your email list and your sending habits matter as much as your code.

Validating delivery with real inbox testing

Let’s be clear: the best test isn’t on a tool’s dashboard. It’s checking where your actual emails land—with real users on real mail clients. That’s why inbox-placement testing is essential. It simulates delivery across major providers and reports whether your message arrives in the inbox, spam folder, or gets blocked outright.

Tools like Emaillistchecker.io's inbox-placement testing use real inboxes across Gmail, Outlook, and Apple Mail to measure your message’s behavior. You can check whether your MIME multipart content displays correctly or gets stripped out. This is especially critical when sending transactional or marketing emails where timing and appearance matter.

For deeper confidence, pair this with list hygiene. Use bulk verification to clean invalid, catch-all, or disposable emails before sending. This improves deliverability and helps maintain sender reputation. A strong sender identity—protected by SPF, DKIM, and DMARC—also helps. These protocols don’t replace testing, but they’re part of a defense-in-depth strategy.

For real-world context, industry guidelines from RFC 5322 and RFC 5321 define message syntax and SMTP behavior—important for correctness, but not sufficient for delivery. The real world is messy: ISPs filter, throttle, and penalize without clear signals. Only testing under actual conditions reveals the truth.

Does using MIME multipart affect sender reputation?

Using MIME multipart to send both HTML and plain text does not hurt sender reputation. In fact, it’s a standard practice that helps avoid spam filters when done correctly. Poorly structured MIME — like incorrect boundaries or missing headers — can cause parsing issues, which may indirectly trigger spam detection. But the format itself isn’t a red flag.

Why MIME multipart doesn’t harm reputation

MIME multipart is an industry-standard format defined in RFC 2046 and widely supported by email clients and servers.
Spam filters don’t block messages simply because they use multipart; they look for malicious content, poor sender reputation, or known bad patterns, not structure.
Email providers like Gmail, Outlook, and Yahoo treat properly formatted multipart messages as reliable. This includes users who disable HTML by default — you’re meeting their needs.
Properly implemented, multipart improves open rates and accessibility, which are positive signals for deliverability. Learn more in RFC 2046.

How to avoid risks from incorrect MIME structure

Always validate your boundary strings: they must be unique, not contain line breaks, and properly enclosed in quotes.
Use established libraries (like PHP’s mail() with proper headers, Python’s smtplib, or Node.js’s Nodemailer) that handle boundary generation automatically.
Test your emails using a service like inbox placement testing to see how your message renders in real inboxes.
Never skip the Content-Type header for each part — especially when mixing HTML and plain text.
Even minor parsing errors (e.g., a missing newline before the boundary) can result in malformed emails, which some spam filters interpret as suspicious behavior.

Let’s be clear: MIME multipart is not the enemy. The enemy is poor implementation. If you're writing raw email headers and bodies, double-check every line ending, every header placement, and every boundary. Even small flaws can undermine deliverability.

Use tools like bulk email verification to clean your list before sending. A clean list reduces bounce risks and avoids the kinds of misdeliveries that make spam filters suspicious. Your reputation depends more on list quality and consistency than on a single technical format.

Best practices for ensuring MIME multipart emails work everywhere

You need to send every email as a multipart MIME message with both HTML and plain text parts—not just because it's the standard, but because it ensures deliverability across clients and devices, including those that strip or ignore HTML. Even visually rich emails must include a plain text fallback to prevent loss of content and to pass spam filters. Test early, test often, and verify your list first.

Core implementation rules

Always include a plain text part, even for purely visual emails. Many email clients, especially enterprise systems and older devices, render only plain text by default. RFC 2046 specifies that multipart messages must include a readable alternative.
Keep the plain text version concise and readable—no HTML, no bold, no links wrapped in brackets. Use short paragraphs and clear language. A reader should understand the core message without needing to parse complex formatting.
Avoid inline styles and CSS in the HTML part. Email clients like Outlook (especially older versions) strip or ignore them. Instead, use standard table-based layouts for structure, with minimal CSS applied inside style attributes on table elements.
Use semantic HTML structure in the HTML part. Wrap content in <div> or <table> elements with clear, consistent indentation. Ensure text is readable at 14px or larger when displayed.
Test across major clients—Gmail, Apple Mail, Outlook (Windows and Mac), Thunderbird, and mobile inboxes—before scaling. Tools like Mail-Tester can help evaluate rendering and spam signals.

Pre-send validation

Verify your email list before sending. Invalid, typo-ridden, or non-existent addresses can trigger spam traps, bounces, and harm sender reputation. Use bulk verification to clean your list at scale.
Validate each address for syntax, domain existence, and mailbox health. Our tool confirms deliverability with 98.9% accuracy, flagging risky, disposable, and catch-all addresses.
Consider using an inbox placement test to see how your email lands in real user inboxes, especially for transactional or campaign messages. Inbox placement testing reveals how likely your message is to reach the inbox.
Ensure your sender identity is properly authenticated. Use SPF, DKIM, and DMARC records to reduce the risk of spoofing and to improve trust scores. Misconfigured authentication is a top reason for delivery failures.

Conclusion: MIME multipart is the foundation of reliable email delivery

Using both HTML and plain text in your emails ensures your message reaches recipients regardless of client capabilities, filtering rules, or accessibility settings. This dual format is not a preference—it’s the standard for professional email delivery.

MIME multipart formatting must be correct. A single misconfigured boundary or incorrect Content-Type can cause rendering issues, trigger spam filters, or result in delivery failures. Verified, clean email lists and inbox-placement testing are the next critical steps to ensure your properly formatted messages actually arrive in inboxes.

Sources

Gmail classifies anyone sending close to 5,000 or more messages to personal Gmail accounts in 24 hours as a bulk sender — and that status is permanent once triggered. — Google Email Sender Guidelines FAQ (2024)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What is MIME multipart and why do I need it?

MIME multipart allows you to send both HTML and plain text versions of an email in one message. It ensures your content is readable regardless of client settings or rendering limits.

Can I send only HTML email without plain text?

Technically yes, but it reduces deliverability. Many email clients block or strip HTML-only messages. Plain text is required for fallback.

What happens if I use the same boundary in multiple emails?

It may cause parsing errors, leading to malformed messages. Each message must use a unique boundary identifier.

How do I verify email addresses before sending MIME multipart emails?

Use a reliable email verification service to remove invalid, catch-all, role-based, and disposable addresses before sending.

Does MIME multipart improve my spam score?

No. Proper MIME multipart does not affect spam scores. Malformed multipart content can cause delivery issues, which may indirectly harm reputation.

Why should plain text come before HTML in MIME multipart?

Because email clients fall back to plain text when HTML is disabled or unsupported. Placing plain text first ensures readability.

Can I include attachments in MIME multipart emails?

Yes, but they go into a separate part with a multipart/mixed content type. MIME multipart is just one part of the full MIME structure.

How do I test if my MIME multipart email reaches inboxes?

Use inbox-placement testing tools to send real messages to inboxes and check whether they land in the inbox or spam.

Is Emaillistchecker.io compatible with email delivery tools like SendGrid?

Yes. Emaillistchecker.io integrates with SendGrid, Mailchimp, HubSpot, and Klaviyo to verify and clean lists before sending.

Do email verification tools like Emaillistchecker.io check for deliverability?

Yes. They verify address validity and provide deliverability insights, including risk signals like catch-all addresses and disposable domains.

What happens if I send MIME multipart to a catch-all email?

The message may be accepted but not delivered to a real user. This increases bounce rate and harms sender reputation.

How does sender reputation affect MIME multipart emails?

MIME formatting itself is neutral. However, high bounce, spam complaint, or delivery failure rates hurt reputation, regardless of formatting.