Do ISPs issue SMTP errors specifically for HTML-only emails?

No, ISPs do not typically issue SMTP errors specifically for HTML-only emails. Rejections are usually due to broader issues like sender reputation, blocklist inclusion (or blacklisting), or failure to pass email authentication protocols (SPF, DKIM, DMARC), rather than the HTML format itself.

What is multipart/alternative and why is it important?

Multipart/alternative is a MIME type that allows an email to contain both a plain text version and an HTML version. It is important because it ensures maximum compatibility across all email clients, allowing each client to display the version it supports or the user prefers.

Can an email client block an HTML email due to security concerns?

Email clients can block certain HTML elements, like JavaScript or active content, for security reasons to protect users from malware and phishing. This is a security measure against malicious code, not a blanket rejection of HTML formatting itself.

How do spam filters treat HTML emails?

Spam filters do not reject emails solely based on HTML. However, certain HTML characteristics, such as HTML-only emails, excessive image-to-text ratios, or overly complex/malformed code, can increase an email's spam score and lead to it being filtered to the junk folder.

Is plain text email better for deliverability than HTML?

Neither plain text nor HTML is inherently "better" for deliverability; the best approach is to send both using multipart/alternative. Plain text offers universal compatibility, while HTML provides rich content. Both contribute to a well-rounded and deliverable email, as long as content and sending practices are good.

Which email clients still primarily display plain text?

Older or minimalist email clients, such as Pine, Mutt, and Elm, primarily display plain text. Some users also configure modern clients like Apple Mail or webmail services to view only plain text for security or simplicity. For more information, see when plain text emails are needed .

Are there any ISPs or email clients that only accept text emails and reject HTML emails? - Content - Email deliverability - Knowledge base

ISPs and email clients generally do not reject HTML emails entirely. The email infrastructure is designed to be highly versatile, supporting various content types. While the concept of a "text-only" client or ISP might exist in niche or legacy environments, it is not a widespread policy or technical limitation that leads to outright rejection.

The prevailing standard for email, known as multipart/alternative, ensures that both a plain text version and an HTML version of an email are sent together. This allows the recipient's email client to choose the format it can best display, or the one the user prefers. This approach mitigates issues of non-compliance.

While HTML offers rich formatting, images, and interactive elements, the plain text alternative is vital for ensuring accessibility and compatibility across all platforms. Some users, particularly those with visual impairments or those using older devices, still rely on this plain text rendering. It also acts as a fallback for instances where HTML may not render correctly.

How email clients handle HTML and plain text

Historically, some minimalist or command-line email clients such as Pine, Mutt, or Elm primarily displayed plain text. These clients prioritize simplicity and security, often chosen by users who deliberately opt out of rich HTML experiences. However, it is crucial to understand that these clients don't actively reject the HTML part of an email. Instead, they simply display the plain text version if one is provided, making the email viewable, albeit without formatting.

Modern email clients, including those offered by major providers, fully support HTML. However, they employ sophisticated security measures to prevent malicious code, like JavaScript or active content, from executing within an email. These measures are designed to protect users from phishing and malware. It is not a rejection of HTML, but a safeguard against potentially dangerous elements within it.

The multipart/alternative MIME type is key to this compatibility. When an email client processes a message with both HTML and plain text parts, it typically renders the HTML version by default, assuming it can do so securely and effectively. If, for any reason, the HTML cannot be displayed, the client automatically falls back to the plain text version. This ensures that the message content is always accessible to the recipient.

Issues can arise, though, if the HTML in an email is poorly formatted or malformed. This can lead to rendering problems or, in some cases, trigger spam filters. For insights into how this can impact delivery, see our guide on what impact does malformed HTML have on deliverability.

Malformed HTML: a deliverability risk

Poorly coded HTML can lead to unexpected display issues and may increase the likelihood of your emails being flagged by spam filters. Ensure your HTML is clean and adheres to email coding best practices to avoid these pitfalls.

Rendering issues: Inconsistent display across various email clients and devices, leading to a poor user experience.
Spam flags: Higher likelihood of being marked as spam or junk due to suspicious coding patterns.

ISP filtering and content-based rejections

Internet Service Providers (ISPs) and Mailbox Providers (MBPs) like

Gmail and

Outlook do not reject emails based solely on their HTML content. Their primary concern is protecting users from spam, phishing, and malware. Rejection decisions are typically made based on a sender's reputation, email authentication, and the overall content's compliance with anti-spam guidelines.

While HTML itself isn't a direct trigger for rejections, certain characteristics of HTML emails can negatively influence spam scoring. For instance, an email that is HTML-only (lacking a plain text part), contains excessive image-to-text ratios, uses suspicious embedded content, or has overly complex code, might increase its spam score. These factors contribute to a recipient's perceived trustworthiness and can lead to messages being filtered to the spam folder or even blocked.

Rejections by ISPs generally stem from issues more significant than merely using HTML. Common reasons include the sending IP or domain being on a blacklist (or blocklist), failing email authentication (SPF, DKIM, DMARC), or a poor sender reputation built from high spam complaints or sending to invalid addresses. If an email is rejected at the SMTP level, it's usually due to these broader deliverability concerns, rather than the presence of HTML. For more information on blocklists, refer to how email blacklists actually work.

The technical integrity of your email, particularly its authentication, is far more critical than whether it contains HTML or plain text. Strong SPF, DKIM, and DMARC configurations are essential for proving your emails are legitimate, as highlighted in Google's email sender guidelines. Failure to pass these checks is a common reason for rejection, not HTML usage. You can learn more about a simple guide to DMARC, SPF, and DKIM to help authenticate your email. Without proper authentication, your emails are much more likely to be rejected or marked as spam, regardless of their content format.

HTML email: features and benefits

Visual appeal: Rich design, branding, images, and interactive elements.
Tracking: Easier to track opens, clicks, and engagement metrics for campaign analysis.
Call to action: Prominent buttons and clear CTAs can enhance user interaction.

Plain text email: simplicity and deliverability

Compatibility: Accessible to virtually all email clients and devices, including older ones.
Deliverability: Often perceived as less "spammy" by some filters and security systems, potentially boosting inbox placement.
Focus: Pure content focus, with no distractions from complex design elements.

Best practices for email format and deliverability

The universal best practice is to always send emails as multipart/alternative, including both an HTML version and a plain text version. This ensures that your email can be viewed by all recipients, whether they use advanced HTML-capable clients or older, text-only systems. It demonstrates a commitment to accessibility and robust deliverability.

Example multipart/alternative structure

Content-Type: multipart/alternative; boundary="--_boundary_XYZ"

--_boundary_XYZ
Content-Type: text/plain; charset="UTF-8"

This is the plain text version of your email.
You can read more at: example.com/important-link

--_boundary_XYZ
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
  <body>
    <p>This is the <strong>HTML version</strong> of your email.</p>
    <p>You can read more at: <a href="http://example.com/important-link">Example Website</a></p>
  </body>
</html>
--_boundary_XYZ--

When crafting your HTML email, aim for clean, semantic, and simple code. Avoid complex CSS, JavaScript, or unconventional HTML tags, as support varies greatly across different email clients. Focusing on email HTML best practices from resources like developer.woocommerce.com or similar guides can help ensure consistent rendering and prevent deliverability issues related to malformed or unsupported code.

For the plain text version, make sure it is a clear and complete representation of your HTML content. All calls to action and important links should be present and legible. It's not just a fallback for older clients, but also a crucial component for some spam filters and for users who prefer to view plain text. To understand more about this, explore why a plain text version is important for email deliverability.

The evolving landscape of email

The vast majority of email communication today is HTML-formatted. Rich visual content, branding, and interactive elements are standard expectations for modern marketing and transactional emails. Data consistently shows that most users prefer and view HTML emails when given the choice, as discussed in the Stack Overflow discussion on HTML-only email.

While concerns about HTML and security persist, the industry has largely adapted by implementing robust security features within email clients and at the ISP level. The presence of HTML is not inherently a red flag for rejection. Rather, it is the nature of the HTML content (e.g., hidden links, malicious scripts) or the sender's reputation that determines deliverability. For more on this, see what percentage of emails are viewed in HTML versus plain text.

Feature	Support Level	Notes
HTML5 Video	Limited	Most clients don't autoplay or require user interaction. Use GIFs instead.
JavaScript	None	Blocked for security reasons by nearly all clients to prevent malicious code execution.
Responsive design	Good	Requires careful coding with media queries and fluid layouts for optimal display.
Custom Fonts	Limited	Falls back to web-safe fonts if not supported, ensure your fallback fonts match.
GIF Animations	Good	Widely supported, but might show only the first frame for some older clients.
CSS positioning	Limited	Many advanced CSS properties, like floats or positions, are not reliably supported.

Views from the trenches

Best practices

Always include both HTML and plain text parts in your emails to ensure maximum compatibility across all email clients.

Focus on clean, simple HTML code that renders consistently, avoiding complex scripts unsupported by many email clients.

Prioritize strong email authentication protocols such as SPF, DKIM, and DMARC as they are critical for deliverability.

Common pitfalls

Sending HTML-only emails can lead to rendering issues for some recipients and may increase spam scoring.

Overlooking the plain text version can result in broken links or unreadable content for certain email clients.

Assuming all email clients render HTML identically can lead to inconsistent user experiences and deliverability problems.

Expert tips

Implement multipart/alternative MIME type even for simple messages for broader compatibility.

Test your HTML emails across various clients and devices using email testing tools to identify rendering inconsistencies.

Monitor your DMARC reports to spot any issues related to HTML content or authentication failures.

Expert view

Expert from Email Geeks says: I have never heard of an SMTP server explicitly blocking emails based on them being HTML. Rejections at that level are usually due to broader policy violations or sender reputation.

Feb 17, 2021 - Email Geeks

Expert view

Expert from Email Geeks says: Some older email clients like Pine, Mutt, and Elm will only display the plain text part of an email, but they do not block the mail itself, they simply render the plain text version.

Feb 17, 2021 - Email Geeks

Ensuring email compatibility and deliverability

While there are no ISPs or major email clients that outright reject HTML emails in favor of plain text, the way email is formatted and sent significantly impacts its deliverability and user experience. The practice of including both HTML and plain text versions using multipart/alternative is a crucial best practice. This ensures that your messages are accessible to all recipients, regardless of their email client's capabilities or personal preferences.

Focusing on clean, well-structured HTML and a clear, readable plain text fallback, alongside robust email authentication, will put you in the best position for consistent inbox placement. Ultimately, successful email delivery is less about choosing one format over another and more about adhering to industry best practices and maintaining a strong sender reputation.