Email Template Rules

Email HTML rendering is stuck in roughly 2005 — no flexbox, no grid, unreliable CSS support, and a dozen mutually incompatible rendering engines — so build every template defensively for the worst-supported client, not the best.

Layout: tables, not flexbox/grid

• Build structural layout with nested HTML <table> elements, not <div> + flexbox/grid — Outlook desktop renders with Microsoft Word's engine, which ignores flexbox and grid entirely and will collapse the layout.
• Set explicit width attributes (not just CSS width) on tables and cells — several clients strip <style>-based sizing but respect the HTML attribute.
• Avoid CSS position, float, and multi-column layouts — none render reliably across major clients; stack single-column when in doubt.

Inline CSS

• Inline every style directly on the element (style="...") rather than relying on a <style> block — Gmail strips <style> tags in some contexts (webviews, forwarded messages) but always keeps inline styles.
• If a <style> block is used for progressive enhancement (media queries, dark mode), duplicate the critical styles inline as a fallback — never make the email depend on the <style> block for basic legibility.
• Avoid CSS shorthand properties with spotty support (background shorthand, font shorthand) — use explicit longhand (background-color, font-size, font-family) for predictable rendering.

The 600px width convention

• Design the email body at a fixed 600px width (or 600-640px) — this is the de facto standard that fits inside every major client's preview pane and reading width without horizontal scrolling, including on mobile where clients scale it down.
• Center the 600px table inside a full-width wrapper table with a background color, so the email looks intentional on both narrow mobile screens and wide desktop reading panes.

Alt text and image fallbacks

• Give every image meaningful alt text — many clients (especially Outlook) block images by default, and the alt text is often the only content a first-time viewer sees.
• Never put critical information (the CTA text, the offer, the unsubscribe link) only inside an image — always also render it as real HTML text for image-blocked and screen-reader contexts.
• Set explicit width/height attributes on every image to prevent layout jumps when images load, and use a background color close to the image's dominant color as a graceful blocked-image fallback.

Dark mode quirks

• Test explicitly in dark mode — some clients auto-invert colors, some respect prefers-color-scheme media queries, and some do neither, producing unreadable combinations (dark text auto-inverted to dark-on-dark) if you assumed one behavior.
• Set an explicit background color on every container rather than relying on "transparent defaults to white" — several dark-mode implementations will invert an unset background to black, breaking contrast with unset (transparent) text colors.
• Provide a prefers-color-scheme: dark block with adjusted colors for the clients that respect it, but never assume it will apply everywhere — the base (light) styles must still be legible on every dark-mode client whether or not it honors the media query.

Plain-text version

• Always send a plain-text multipart/alternative version alongside the HTML — some clients and spam filters weight the presence and quality of a plain-text part in deliverability scoring, and some users/clients render plain-text only.
• Generate the plain-text version from the same content, not as an afterthought stub — it should contain the same links and calls to action in readable form, not just "please view in HTML."

Testing across clients

• Test rendering across the actual major clients before sending (Outlook desktop, Gmail web/app, Apple Mail, common mobile clients) — CSS support genuinely differs enough between them that "works in my inbox" is not evidence it works elsewhere.
• Test with images blocked (the default in many clients) and confirm the email is still legible and the CTA still findable.
• Send a real test send to real inboxes before a production campaign — rendering previews in ESP tools do not catch every discrepancy that live delivery does.

Image-blocking resilience

• Design the layout so it degrades gracefully with all images blocked: text-based CTAs (styled buttons using table cells + background color, not image buttons), and a logo alt text that still identifies the sender.
• Never build a template that is a single large image with an image map — this is treated as spam-like by many filters and is completely inert with images blocked.