Summary
The question of whether to send multipart/alternative emails has evolved significantly over time. Historically, it was considered a best practice to ensure compatibility across diverse email clients and to provide a plain text fallback for those unable to render HTML. Today, with advancements in email client technology and screen reader capabilities, the direct impact on email deliverability is minimal. However, its role in accessibility and offering a robust user experience remains a point of discussion. While modern email clients are highly capable of processing HTML, providing a well-structured plain text alternative can still cater to niche cases or specific accessibility tools.
Key findings
- Deliverability impact: Direct deliverability (inbox placement) is not significantly affected by the presence or absence of a multipart/alternative body today.
- Accessibility for modern clients: Modern screen readers can effectively interpret HTML emails, especially when proper semantic HTML and alt attributes are used for images.
- Legacy support: Very old or specific text-only email clients might still rely on the plain text part.
- Content representation: The multipart/alternative format allows different representations of the same content, letting the client choose the best fit.
Key considerations
- Quality of plain text: A poorly generated plain text version can be more detrimental to user experience than no plain text version at all. This highlights the importance of ensuring a good plain text version when sending multipart/alternative.
- Effort vs. benefit: Consider the resources required to create and maintain a high-quality plain text version versus the incremental benefits, given modern client capabilities.
- Image-only emails: For emails that are primarily image-based, providing a text alternative or ensuring proper alt text within the HTML is crucial, as noted in discussions about protecting deliverability for image-only emails.
- Accessibility focus: Focus on overall email accessibility best practices, including semantic HTML and clear content, rather than solely relying on the plain text part of multipart/alternative. Smart Messenger highlights the importance of email text versions for accessibility.
What email marketers say
Email marketers often weigh the historical advice of sending multipart/alternative against the practicalities of modern email campaigns. Many question whether the effort translates into tangible benefits for deliverability or engagement, especially when automated tools generate subpar plain text versions. The general sentiment leans towards focusing on a high-quality HTML email, while recognizing that a well-crafted text version can still enhance accessibility for a segment of their audience, though perhaps not for deliverability directly.
Key opinions
- Limited deliverability impact: Many marketers do not see a direct or significant impact on inbox placement from including a plain text part.
- Resource allocation: There's a debate on whether the time and effort spent on generating a separate plain text version is justified by the return.
- Accessibility focus: Some marketers emphasize the importance of the text version for screen readers and users who prefer minimal interfaces.
- HTML-centric design: With most email clients displaying HTML by default, the plain text version can often be an afterthought or poorly rendered automatically.
Key considerations
- Audience segmentation: Consider your target audience and their common email clients. If a significant portion uses older clients or specific accessibility tools, a good plain text version becomes more valuable.
- Content quality: If you do include a plain text version, ensure it is readable and accurately conveys the message, as poor text versions can negatively impact user perception or even spam scores, as discussed in relation to image-to-text ratio.
- Automated text generation: Many email service providers (ESPs) automatically generate a plain text version from HTML. Marketers should review these to ensure they are satisfactory, as sometimes identical emails can still be flagged as spam if content varies significantly or is poorly formatted.
- Technical implementation: For specific scenarios like sending HTML and text content with different structures, the multipart/alternative MIME type is relevant.
Marketer from Email Geeks suggests that including a plain text version might not directly improve deliverability, leaving the benefit of multipart/alternative in question.
Marketer from Email Geeks states that if HTML-only emails are sent to their personal plain-text email client (Pine), it's not their fault if it doesn't render well. This highlights the user's preference for plain text.
What the experts say
Email deliverability experts offer a nuanced perspective on multipart/alternative emails. While acknowledging its historical significance as a Best Current Practice (BCP), they largely agree that its direct impact on deliverability has diminished. The focus has shifted from mere presence to the quality of content within both parts, particularly concerning accessibility for screen readers. Experts highlight that a poorly constructed plain text version can be more detrimental than simply sending HTML-only emails, emphasizing that modern email clients and accessibility tools are increasingly adept at handling HTML content effectively.
Key opinions
- Deliverability is not the primary factor: The choice to send multipart/alternative no longer significantly affects whether an email reaches the inbox.
- Evolution of BCP: While it was once a BCP, current consensus suggests it's no longer strictly essential for all senders.
- HTML for accessibility: Modern screen readers are sophisticated enough to parse HTML, often making a separate plain text version less critical for accessibility, especially when proper alt tags are included.
- Poor text versions: A automatically generated, unreadable plain text version can actually detract from the user experience, rather than enhance it.
Key considerations
- User experience focus: The primary reason to include a plain text version now is for user preference and specific accessibility needs, aligning with broader goals of improving overall email deliverability and engagement.
- Content consistency: Ensure that if both HTML and plain text versions are sent, they convey the same message accurately. Issues like commented code in emails are more relevant to technical parsing than multipart/alternative.
- Handling image-only emails: If emails are heavily image-based, relying solely on images without robust HTML text or alt text can be a significant accessibility barrier, regardless of multipart/alternative usage.
- Understanding email structure: A fundamental understanding of how an email is structured, including MIME types and content parts, helps in making informed decisions about email formatting.
Expert from Email Geeks notes that while they might prefer clients to implement multipart/alternative, its presence or absence does not significantly affect email delivery.
Expert from Email Geeks states that current best practices for email sending may not always align with what is strictly necessary for deliverability. This suggests a distinction between historical norms and modern requirements.
What the documentation says
Technical documentation, primarily RFCs, defines the structure and intent behind multipart/alternative MIME types. These specifications outline how different representations of the same content should be included within an email, allowing email clients to select the most suitable version for display. While the RFCs provide the foundational framework, practical implementation and user agent (email client) behavior often dictate the real-world impact on content rendering and accessibility. The key is ensuring a graceful degradation for recipients, providing a fallback for clients that cannot render the richer HTML version.
Key findings
- RFC 2046 definition: This RFC specifies multipart/alternative as a way to provide multiple versions of the same content in different formats.
- Client selection: Email clients are designed to choose the 'best' or 'richest' format they can render, which is typically HTML if available.
- Order of parts: The RFC suggests placing the least faithful representation (e.g., text/plain) first and the most faithful (e.g., text/html) last.
- Purpose for compatibility: The fundamental purpose is to ensure that an email can be viewed by a wide range of email clients, from plain text to fully rich HTML.
Key considerations
- Proper MIME type: Correctly declaring Content-Type: multipart/alternative and defining proper boundaries is critical for parsing. This is related to general email formatting and encoding practices.
- Semantic consistency: While formats differ, the semantic meaning and intent of the message should be preserved across all alternative parts. This contributes to technical solutions for boost email deliverability.
- Distinction from mixed content: It's important to differentiate multipart/alternative (same content, different formats) from multipart/mixed (different, sequential parts like attachments), a key distinction highlighted in the anatomy of an email.
- Client-specific behaviors: While RFCs are universal, some email clients may have specific quirks or preferences in how they handle multipart/alternative content, requiring testing and adaptation.
Documentation from MailPace explains that multipart/alternative signifies that an email contains multiple representations of the same content, each in a different format, typically offering HTML and plain text versions.
Documentation from Krystal Labs clarifies that when attaching files, the main Content-Type should be set to multipart/mixed instead of multipart/alternative, distinguishing between providing alternatives and including separate parts.
