Design Emails That Look Amazing Everywhere.

Why Email Design Is Different from Web Design

Email design operates under constraints that web designers rarely encounter. The techniques that make modern websites fast and responsive can break email rendering entirely.

Tables, not divs or Flexbox, remain the most reliable layout method because email clients that strip or ignore modern CSS still render tables consistently. Inline CSS is mandatory — Gmail strips embedded styles from the head section, so every element must carry its own styles. CSS support is fragmented: border-radius works in most clients but fails in Outlook desktop; display: flex is unsupported in Outlook; position and float behave unpredictably. The email design workflow requires building in frameworks or visual builders, testing across dozens of client-device combinations, and fixing issues that only appear in specific environments.

The Fundamentals of HTML Email

Building an HTML email requires understanding the structural patterns that work reliably across clients.

DOCTYPE choices affect rendering. XHTML 1.0 Strict is the traditional choice; HTML5 is also acceptable. Some older Outlook versions behave better with XHTML.

Tables are the foundation of email layout. The basic structure uses an outer table for the overall layout, nested tables for sections, and inner tables for content blocks. Each table should include border="0", cellpadding="0", cellspacing="0", and role="presentation" for accessibility. Divs have limited use in email.

Inline styling means every element carries its own styles, which guarantees they survive whatever the email client does. Email frameworks like MJML generate inline-styled HTML automatically, reducing the burden of manual repetition.

The email design workflow involves building in a framework or visual builder, testing across clients, fixing issues, and iterating. MJML is popular for the development phase; drag-and-drop builders like Stripo or BEE offer faster prototyping. The key is a reliable build-test-fix loop.

Responsive Design for Every Device

More than half of all email opens occur on mobile devices. Responsive design is not optional; it is essential.

Media queries enable responsive email by applying different styles at different screen widths. The standard breakpoint is 600px. Below that width, the email switches to a single-column layout with larger fonts and touch-friendly tap targets. A typical media query for email looks like this, placed in the head section inside style tags and wrapped in a conditional comment for Outlook:

@media only screen and (max-width: 600px) {
  .container { width: 100% !important; }
  .column { display: block !important; width: 100% !important; }
  .hide-mobile { display: none !important; }
  .show-mobile { display: block !important; }
}

The fluid hybrid approach combines fluid tables (percentage widths) with media queries to create layouts that work even in email clients that strip media queries. The outer table uses width: 100%; max-width: 600px; to fill the screen on mobile while capping the width on desktop. Inner columns use percentage widths with max-width set, and media queries override the layout at the breakpoint. This approach degrades gracefully in clients that do not support media queries.

Touch-friendly CTAs require sufficient tap target size. Apple's Human Interface Guidelines recommend a minimum of 44x44 points. In email, that means CTA buttons should be at least 44px tall and wide enough to accommodate the text comfortably. Padding inside the button, typically 12–16px vertical and 20–30px horizontal, ensures the tap target is large enough. Avoid links that are close together, as they are hard to tap accurately on small screens.

Mobile-first considerations extend beyond layout. Font sizes should increase on mobile — 14px minimum for body text, with 16px being more comfortable. Line heights should be 1.5 to 1.8 for readability. Padding around content blocks should be 16–20px on mobile to prevent text from touching screen edges. These adjustments make the email more readable and accessible on small screens.

Email Client Compatibility

Each major email client has its own rendering quirks. Understanding them is essential for producing emails that look good everywhere.

Gmail quirks include stripping embedded styles from the head section, ignoring certain CSS properties like background-position and object-fit, and wrapping emails in its own markup. Gmail also applies its own default styles that can override yours. Gmail's CSS support is limited but improving — it now supports media queries in the Gmail app for Android and iOS, but not in the web client.

Outlook rendering engine limitations are the most severe of any major client. Outlook desktop uses Microsoft Word's rendering engine, which supports a tiny subset of CSS. It does not support border-radius (round buttons become squares), background-image on elements (use VML for background images), padding on list items (use margin or non-list elements), or display: inline-block consistently. Conditional comments can target Outlook-specific fixes:

<!--[if mso]>
  <td style="padding: 0;"> ...
<![endif]-->

Apple Mail capabilities are the best of any email client. Apple Mail supports nearly all modern CSS, including Grid, Flexbox, animations, and custom fonts (via @import or @font-face). The trade-off is that Apple Mail users are less likely to have images enabled by default, so designs must work without images. Apple Mail also introduced privacy protection features that mask open rates, making engagement measurement more challenging.

Yahoo requirements are generally straightforward. Yahoo supports standard email CSS well and processes media queries reliably. However, Yahoo has strict sender reputation requirements and may filter emails that fail authentication. Ensuring your emails are properly authenticated helps Yahoo deliverability.

Dark Mode Strategies

Dark mode changes how your email renders aesthetically and functionally. Designing for dark mode requires deliberate effort.

Meta colour scheme tags tell email clients that your design is dark mode aware. Adding <meta name="color-scheme" content="light dark"> and <meta name="supported-color-scheme" content="light dark"> to the head section enables dark mode support. These tags prevent clients from automatically inverting your colours, which would make white-background emails unreadable in dark mode.

Image swapping allows you to serve different images for light and dark modes. Some designers create two versions of their logo — one for light backgrounds and one for dark — and use media queries with prefers-color-scheme: dark to show the appropriate one. This ensures your brand assets look correct regardless of the user's colour scheme.

Colour adjustments for dark mode typically involve inverting or adjusting background and text colours. A white background with dark text becomes a dark background with light text. However, not all colours invert well. Brand colours often need manual adjustment to maintain contrast and readability in dark mode. Test every colour combination in both modes.

Testing approach for dark mode should include every major client. Gmail, Apple Mail, and Outlook all handle dark mode differently. Gmail applies its own dark mode styles regardless of your meta tags. Apple Mail respects your design choices when the meta tags are present. Outlook inverts colours aggressively. Test in each environment and adjust accordingly.

Typography, Images, and CTAs

These three elements carry the functional weight of your email. Getting them right is essential.

Web-safe fonts and fallback stacks are necessary because email clients cannot load custom fonts reliably. The standard approach is to use a font stack like font-family: 'Segoe UI', Roboto, Arial, Helvetica, sans-serif;. This provides a modern font for clients that support it, with reliable fallbacks for clients that do not. System fonts like Arial, Helvetica, Georgia, and Times New Roman work everywhere and should be the foundation of your typography.

Image blocking handling is critical because many email clients block images by default. Never rely on images to convey essential information. Alt text should describe the image content and purpose. If an image contains text, the alt text should include that text. Background colours and spacing should ensure the email is readable with images turned off.

Alt text best practices involve being descriptive but concise. For a product image, write "Men's navy wool blazer" rather than "Image of product" or leaving it blank. For a decorative image, use alt="" so screen readers skip it. For a CTA button implemented as an image, include alt text like "Shop the sale" so recipients can still understand the action even with images blocked.

CTA button best practices include making buttons visually distinct, using action-oriented text, placing them in prominent positions, and ensuring they work on every client. The VML-background pattern gives Outlook desktop round or rounded buttons that would otherwise appear as squares. Buttons should be at least 44px tall, use generous padding, and include sufficient colour contrast against the background.

Accessibility in Email

Email accessibility ensures your messages can be read and understood by everyone, including subscribers using assistive technologies.

WCAG compliance in email means meeting Web Content Accessibility Guidelines standards where they apply to email. Key requirements include sufficient colour contrast (at least 4.5:1 for normal text, 3:1 for large text), non-text content having text alternatives, and content being operable through a keyboard interface.

Semantic structure helps screen readers navigate your email. Use proper heading hierarchy (h1, h2, h3 in order) rather than styling text to look like headings. Use <table role="presentation"> to tell screen readers that layout tables are not data tables. Use semantic tags like <p>, <ul>, and <strong> rather than styling divs and spans to look like paragraphs, lists, and bold text.

Colour contrast must be sufficient for readability. Light grey text on a white background, commonly used for secondary information, fails colour contrast requirements for all but the largest text. Use contrast-checking tools to verify your colour combinations against WCAG standards. Remember that dark mode may change the effective contrast of your colours.

Screen reader testing reveals how your email sounds rather than looks. Test with VoiceOver on iOS and macOS, TalkBack on Android, and NVDA or JAWS on Windows. Listen for logical reading order, proper heading announcements, meaningful link text, and appropriate alt text. A screen reader test often catches issues that visual review misses.

Heading hierarchy provides the navigation structure for screen reader users. Use one h1 per email (typically the company name or email title), followed by h2 for section headings, and h3 for subsections. Do not skip levels. Keep the hierarchy logical and consistent across campaigns.

What You'll Learn in the Full Guide

Our comprehensive email design PDF guide provides full coding patterns for common email layouts including newsletters, promotional emails, transactional templates, and event invitations. It includes MJML templates that compile to production-ready HTML, with client-specific fixes built in. The accessibility checklist covers every WCAG requirement relevant to email. The design review process gives you a structured framework for evaluating emails before they go to development or production.

Who Needs This Guide

This guide is for email designers who want to improve their cross-client rendering skills, developers who build and maintain email templates, marketing teams responsible for campaign production, and anyone who needs to create emails that look great on every device and client. If you design or build email templates, this guide will help you create better, more reliable, more accessible emails.