Plain Text Email &
Multipart MIME Structure

Multipart/Alternative MIME Structure

Email messages are structured as MIME (Multipurpose Internet Mail Extensions) — a standard that allows multiple content types in a single message. Properly formatted emails use `multipart/alternative` structure, which includes both HTML and plain text parts. Email clients choose which version to display based on user settings and client capabilities.

Typical Email MIME Structure:

How Clients Decide Which Version to Render:

• Gmail: Defaults to HTML, falls back to plain text if user requests "original message"
• Apple Mail: Renders HTML; plain text shows if HTML rendering fails
• Outlook: Renders HTML by default, shows plain text if user disables HTML
• Corporate firewalls: Often block HTML, render plain text instead
• Kindle email: Only accepts plain text, ignores HTML completely
• Old clients (Lotus Notes): Only understands plain text

The `boundary` Parameter: The boundary string separates different MIME parts. It's a random string guaranteed not to appear in the email body. Example: `----boundary-abc123xyz789` — this separates the plain text section from the HTML section.

Plain Text as a Deliverability Signal

Spam filters actively check for multipart/alternative structure. HTML-only emails are penalized as a deliverability risk because legitimate emails almost always include plain text.

Deliverability Impact (Real Data from Email Filtering Studies):

• HTML-only email: +0.5 to +1.5 spam score points
• Multipart/alternative (HTML + plain text): 0 points (neutral)
• Malformed plain text: +0.2 to +0.5 points (minor penalty)
• Well-written plain text: -0.2 points (slight boost)

Why Plain Text Matters:

• Legitimate marketing emails include both versions
• Phishing and mass spam often omit plain text
• SpamAssassin scoring (used by many ISPs) rewards multipart/alternative
• A missing plain text part is a red flag for automated spam filters
• Accessibility requirement: screen readers need plain text

Real-World Scenario: Two similar promotional emails from different senders. Email A: multipart with good plain text. Email B: HTML-only. Both have identical subject, from address, and content. Spam filter penalizes Email B by +1 point. Email A gets 4.2 spam score (passes at 5.0 threshold), Email B gets 5.2 (flagged for further review or filtered).

Text-to-HTML Ratio & Spam Scoring

Spam filters measure the ratio of actual text content to HTML markup. Too much markup and too little content = spam indicator.

Text-to-HTML Ratio Scoring:

• 70% text, 30% HTML markup: Optimal (0 points)
• 50% text, 50% HTML: Acceptable (0-0.2 points)
• 30% text, 70% HTML: Suspicious (+0.5-1.0 points)
• 10% text, 90% HTML: Very suspicious (+1.0-2.0 points)
• 5% text, 95% HTML (mostly images/formatting): Phishing-like (+2.0+ points)

How to Calculate Your Ratio:

Guideline for Campaigns: Aim for at least 40-50% actual text content (not including HTML tags). This keeps spam scores low while maintaining visual design.

Authentication Headers & MIME Envelope

DKIM, SPF, and DMARC headers live at the MIME envelope level — the outermost layer of the message. They protect the entire message structure and are added by your ESP, not embedded in the email body.

MIME Envelope Structure (How Headers Are Organized):

Critical Rule: Never include "DKIM verified" or authentication claims in the email body text. These belong in headers only. Claiming authentication in body text is a red flag for phishing.

Writing Plain Text: 72-Character Lines

Plain text email uses a specific format: 72-character line length with hard line breaks. This standard originated from 80-column terminal displays (72 chars + 8-char margins).

72-Character Line Format Example:

Why 72 Characters Matter:

• Older email clients (Lotus Notes, Thunderbird) wrap at 80 characters
• Terminal email readers (used by Unix/Linux enthusiasts) expect this format
• Corporate proxies sometimes re-encode messages; proper format ensures readability
• Mobile devices display text-only emails better with proper breaks
• RFC 2822 recommends 78 character maximum (72 + 6 safety margin)

Best Practices for Plain Text Formatting:

• Use hard line breaks (Enter key) every 72 characters, not soft wrapping
• Use ASCII characters only (no Unicode symbols, smart quotes, emojis)
• Use plain hyphens (-) and asterisks (*) for visual separation, not fancy Unicode
• Use spaces for indentation, not tabs (tabs render as 8 spaces in some clients)
• Double-space between paragraphs (blank line in between)
• Use ALL CAPS sparingly (only for headings or emphasis)

Auto-Generated vs Manually Written

Most ESPs can auto-generate plain text by stripping HTML tags from your HTML version. This works, but manually written plain text is significantly better for both deliverability and user experience.

Auto-Generated Plain Text (HTML → Text Conversion):

Manually Written Plain Text:

When to Manually Write Plain Text:

• Promotional/marketing campaigns (always)
• Transactional emails (order confirmations, receipts) (always)
• Newsletter-style emails (always)
• Auto-generated emails can use stripped HTML only if content is simple

When Subscribers See Plain Text

While most subscribers see your HTML version, a significant portion view plain text. Know when and why this happens.

Scenarios Where Plain Text is Rendered (30-40% of subscribers):

• Corporate firewalls (10-15%) — Block images and HTML for security, force plain text rendering
• Email client settings (5-10%) — Power users disable HTML rendering for privacy/security
• Amazon Kindle email (2-3%) — Send-to-Kindle feature only accepts plain text
• Old mail clients (1-2%) — Lotus Notes, older Thunderbird, legacy corporate email systems
• Text-only mode (3-5%) — Users with accessibility needs, terminal email clients
• Email client fails to render HTML (2-3%) — Broken HTML, unsupported CSS, rendering errors

Corporate Firewall Rendering: Many corporations use email gateway solutions that strip HTML for security. Users see plain text only. For corporate B2B emails, ensure plain text conveys the complete message — don't rely on HTML formatting.

Testing Plain Text Rendering: Most ESPs provide a "preview" option to see plain text version. Always review it before sending. Ask: "Does this make sense without any HTML formatting?"

Transactional Email Plain Text Best Practices

Transactional emails (order confirmations, password resets, receipts, shipping notifications) have higher importance and stricter requirements. A broken plain text part can make these emails unreadable.

Essential Info That MUST Appear in Plain Text:

• Order/transaction number
• Order date and total amount
• Shipping address (for orders)
• Important deadlines or expiration dates
• Password reset link (full, unshortened URL)
• Account credentials or access instructions
• Unsubscribe link
• Support contact information

Transactional Email Plain Text Example:

Character Encoding in Plain Text:

• Use UTF-8 encoding for plain text (same as HTML)
• Keep to ASCII characters when possible (a-z, 0-9, basic punctuation)
• Avoid: Unicode symbols (™, ©, →), smart quotes (", "), emojis
• Reason: Not all email clients or corporate systems handle UTF-8 encoding correctly
• If non-ASCII needed: Use ISO-8859-1 as fallback, but UTF-8 is preferred