What are the technical standards for HTML emails (MIME compliance)?

Think of MIME as the shipping container spec for email. Multipurpose Internet Mail Extensions is the set of rules that lets a single message carry HTML, plain text, images, and attachments without falling apart in transit. Get it wrong and your beautifully designed email shows up as a wall of raw code, or worse, doesn't show up at all.

Here's a pre-send checklist you can actually run through before hitting send:

• Content-Type: multipart/alternative wrapping both an HTML part and a plain text part. If you only send HTML, you're telling filters you've got something to hide.
• UTF-8 encoding declared in the Content-Type header. Anything else and your emoji, accents, and smart quotes break on someone's screen.
• Plain text version that actually says something. Not "view this email in your browser." Write a real text version that delivers the message.
• No JavaScript. It gets stripped by every major client, so if your email depends on it, your email is broken.
• Tables for layout, inline CSS for styling. Modern CSS (grid, flexbox) works in some clients and not others. Tables still render everywhere.
• Under 102KB total HTML. Gmail clips anything bigger, which hides your unsubscribe link and tanks engagement signals.
• Valid, well-formed HTML. Unclosed tags and broken nesting trip spam filters that score on structure.

Why the fragmentation? Email clients never agreed on a rendering standard the way browsers eventually did. Outlook still uses Microsoft Word's rendering engine for HTML. Apple Mail uses WebKit. Gmail strips half your CSS. So you design for the lowest common denominator and accept that pixel-perfect is a fantasy.

Before you send, paste your HTML into our rendering test tool and scan the source. If anything's off, our Review My Emails SOS hotline is free (and we actually pick up). Related reading: why the plain text version matters and how clients handle blocked images.