Email communication has evolved significantly since its early days. What was once a simple text-based exchange has become a rich, multimedia experience, driven by HTML. This evolution often prompts questions about older email formatting standards and their continued relevance.
One such standard is the multipart/alternative content type, which essentially means sending two versions of the same email: one in plain text and one in HTML. The idea behind it was to ensure that regardless of the recipient's email client capabilities, they would always receive a readable version of the message.
The question today isn't whether it was a good idea, but whether it remains a necessary practice in an era dominated by advanced email clients and sophisticated spam filters. Does sticking to this tradition genuinely impact your email deliverability or overall user experience?
Understanding multipart/alternative emails
A multipart/alternative email is a MIME (Multipurpose Internet Mail Extensions) construct that allows an email to contain different versions of the same content. The most common use case is providing both a text/plain and a text/html version of the email body. The email client then chooses the most preferred or most capable version it can render, typically prioritizing the HTML version if supported. This is defined in the MIME RFC 1341 specification.
Historically, this was crucial. Many older email clients, especially text-based ones, could not display HTML. Without a plain text alternative, recipients would see a jumble of HTML code instead of a readable message. It also served as a safeguard against email clients that might strip HTML for security reasons or simply not support it.
The distinction between multipart/alternative and multipart/mixed is important. While multipart/alternative offers different versions of the same content, multipart/mixed is used for emails that contain different, independent parts, such as an email body plus an attachment. For more technical insight into this, consider this discussion on the types.
The diminishing impact on deliverability
The primary concern for many senders is whether omitting a plain text alternative will hurt their email deliverability. In short, for most modern use cases, the direct impact on deliverability (getting to the inbox) is minimal. Spam filters and Mailbox Providers (MBPs) today are incredibly sophisticated.
They evaluate hundreds of factors, from sender reputation to content quality, and are less reliant on the presence of a plain text part as a primary spam indicator. Unlike in the past, when an HTML-only email might have been flagged, contemporary systems can parse and understand HTML content effectively. So, if your HTML is well-structured and clean, the absence of a separate plain text version isn't likely to land you on a blacklist or blocklist.
What does significantly impact deliverability is the image-to-text ratio or sending image-only emails. These practices can still trigger spam filters because they make it harder for the filters to scan content for malicious links or keywords. While a plain text version might offer a fallback in such cases, it's not a substitute for proper HTML design.
Accessibility and user experience
Beyond deliverability, the main argument for multipart/alternative traditionally centered on accessibility, specifically for users relying on screen readers. The thought was that the plain text version would be easier for these tools to interpret.
However, modern screen readers are quite adept at parsing HTML. A well-coded HTML email, with semantic tags, proper heading structures, and descriptive alt text for images, often provides a better user experience for screen reader users than a poorly auto-generated plain text version. Many email clients, including Gmail, are designed to be accessible directly from their HTML interfaces.
The critical point is that a plain text version is only as good as its content. If it's a mangled mess of links and placeholders, it detracts from accessibility rather than enhancing it. It's more important to focus on creating a robust plain text fallback if you include one, rather than just including it for the sake of it.
Legacy accessibility needs
Older clients: Many email clients in the past could only render plain text, making the alternative version essential for readability.
Basic screen readers: Early screen readers primarily relied on plain text content, as they struggled to interpret complex HTML structures.
Simple display: Ensured that even in the most basic environments, the core message was conveyed without visual formatting issues.
Modern accessibility needs
Advanced clients: Most email clients today, including webmail and mobile apps, fully support HTML rendering.
Sophisticated screen readers: Modern screen readers can interpret HTML structure, including alt text, much like web browsers. Proper HTML markup is key for accessibility.
User experience: The focus shifts to creating a single, highly accessible HTML email that provides a consistent and rich experience for all users.
Technical considerations and challenges
While the impact on deliverability is negligible and accessibility concerns have shifted, there are still arguments for and against sending multipart/alternative emails.
From a technical standpoint, managing two versions of an email adds a layer of complexity. Automated tools can generate plain text from HTML, but these often result in suboptimal content, stripping out formatting that could be beneficial even in a text-only view (e.g., proper spacing, readable links). Manually crafting a good plain text version requires additional time and effort, which might not always be justified by the benefits.
Here's a simplified example of how a multipart/alternative email structure might look:
Example multipart/alternative email structureemail
Content-Type: multipart/alternative; boundary="_----------=_161201234567890"
--_----------=_161201234567890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
This is the plain text version of your email.
Visit our website: example.com
--_----------=_161201234567890
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<html><body>
<p>This is the <b>HTML</b> version of your email.</p>
<p>Visit our website: <a href="example.com">example.com</a></p>
</body></html>
--_----------=_161201234567890--
The overhead of including two distinct content bodies can also increase the overall email size, which, while usually minor, can accumulate for high-volume senders. This is less about deliverability and more about network efficiency, but it's a factor to consider.
For some, the plain text version is seen as a safeguard against potential rendering issues with complex HTML or as a way to cater to specific niche clients that still might prefer it. It's a matter of weighing the perceived benefits against the actual effort and potential drawbacks.
Aspect
Pros of multipart/alternative
Cons of multipart/alternative
Client compatibility
Ensures older or niche email clients, including some terminal-based ones like Mutt, can display readable content.
Most modern clients prefer HTML, making the plain text part often redundant.
Accessibility
Provides a fallback for screen readers or users with disabilities who might prefer a simpler text-only experience.
Auto-generated plain text can be poorly formatted and less accessible than well-structured HTML with alt text.
Deliverability
Minimal direct impact on deliverability. Some legacy spam filters might prefer it, but this is less common today.
Modern spam filters evaluate many other factors, rendering the plain text alternative less critical for inbox placement.
Maintenance & Size
Provides redundancy in case HTML rendering fails entirely (rare).
Increases email size slightly and adds complexity to email generation processes, potentially leading to inconsistencies between versions.
The verdict: A balanced approach
The email landscape has undeniably shifted. With the prevalence of sophisticated webmail clients and mobile apps, the vast majority of email recipients will view the HTML version of your message. Many sending platforms automatically generate a plain text part, often by stripping HTML tags, which can result in a suboptimal fallback. My advice for many clients is that explicitly creating a plain text version for deliverability is largely unnecessary.
However, that doesn't mean you should abandon accessibility or cater only to the newest clients. The focus should be on creating high-quality, responsive HTML emails that are inherently accessible. This includes using proper semantic HTML, ensuring sufficient color contrast, and always including descriptive alt text for all images. If you do send a multipart/alternative email, ensure the plain text part is a genuine, readable fallback, not just a token inclusion.
Best practices for accessible emails
Semantic HTML: Use appropriate HTML tags (e.g., <p>, <h1>, <a>) to structure your content logically for screen readers.
Alt text: Always provide descriptive alt text for images, as screen readers rely on this to describe visual content.
Link descriptions: Ensure your links are clear and descriptive, even outside of the anchor text, for better navigation.
Testing: Test your emails with actual screen reader software to understand how they are interpreted.
Views from the trenches
Best practices
Focus on delivering a single, robust, accessible HTML version of your emails.
Always include meaningful alt text for images in your HTML emails.
Ensure your HTML is semantically structured to aid modern screen readers.
Common pitfalls
Assuming multipart/alternative is a critical deliverability factor in 2024.
Relying on poorly auto-generated plain text versions that detract from accessibility.
Sending image-only emails without adequate textual alternatives or alt text.
Expert tips
Modern email deliverability is rarely impacted by the absence of a multipart/alternative format, as filters have evolved.
Prioritize creating highly accessible HTML over a potentially flawed separate plain text version.
The historical 'best current practice' of always including a plain text alternative has significantly less weight today.
Expert view
Expert from Email Geeks says that while there's a strong desire to recommend sending multipart/alternative emails, it actually doesn't affect email delivery much. It's more about doing the 'right thing' from a traditional perspective, but it's not a direct deliverability factor.
2020-11-30 - Email Geeks
Marketer view
Marketer from Email Geeks notes that screen readers today can speak HTML just fine, and often the automatically generated plain text versions of multipart emails are poorly formatted and unhelpful.
2020-11-30 - Email Geeks
Final thoughts
While multipart/alternative emails were once a critical best practice, their direct influence on email deliverability has waned. Modern email clients and spam filters are sophisticated enough to handle HTML-only emails without issue, provided they are well-coded and not attempting to bypass content filters with image-only designs.
Today, the decision to send multipart/alternative is more about philosophical adherence to older standards or catering to extremely niche legacy clients. For most senders, focusing on creating high-quality, accessible HTML emails, with proper semantic structure and alt text, will yield better results for user experience and deliverability than merely including a often-neglected plain text part.
Gmail, are designed to be accessible directly from their HTML interfaces.
Mutt, can display readable content.
