6 Tips To Create HTML Email

Sam Erickson
Updated 6 hours ago
0

Key Takeaways

Design for a defined email-client support matrix, not for identical rendering everywhere.
Keep source CSS maintainable, inline essential declarations during your build, and preserve supported embedded styles where needed.
Use shallow presentational tables when compatibility requires them, with fluid widths and accessible content.
Host images at stable HTTPS URLs, but keep the message useful when remote images are blocked.
Send meaningful HTML and plain-text alternatives, then test the message delivered through your actual sending service.

Reliable HTML email comes from designing around uneven email-client support: conservative layouts, supported CSS, accessible content, and cross-client testing. These HTML email best practices apply whether you're building a marketing campaign or a transactional notification.

It can still feel like full-on time travel back to web design's early days. The trick isn't to abandon modern tooling; it's to separate how you author an email from the compatibility-focused HTML you send.

1. Inline Essential CSS During the Build

Don't confuse support for a style block with support for every CSS declaration inside it. Gmail's CSS reference documents embedded style blocks, selectors, and supported media queries; unsupported properties and selectors may be ignored. “Everything must be inline because clients ignore the head” is no longer a useful rule.

Write reusable template or component CSS, then inline the declarations your client matrix needs. Keep media queries in embedded style blocks: conditional rules cannot be represented as ordinary style attributes. Inlining changes where a declaration lives; it doesn't make an unsupported CSS feature work.

MJML is an authoring framework that generates responsive email HTML. Its <mj-style inline="inline"> setting requests inlining for those styles. Preview services serve a different purpose: they help you inspect the output rather than establish compatibility merely by generating it.

Source template + CSS
        |
        v
Compile / inline supported styles
        |
        v
HTML + meaningful plain text
        |
        v
multipart/alternative message
        |
        v
Sending service -> recipient client
                         |
                         v
                 Preview and inbox checks

Keep the generated HTML available for debugging. When spacing breaks, inspect what the build emitted and what the receiving client displays—not just the source component.

2. Choose Spacing Patterns for Your Clients

Margins, floats, and padding aren't universally forbidden or universally safe. Gmail lists all three among its supported properties, but that doesn't establish their behavior in every other client.

For a conservative table layout, start with padding on content cells and explicit margins on headings and paragraphs. Then verify the result. Can I email's padding tests document table-cell-only support and row-padding quirks in tested classic Outlook versions—so “replace every margin with padding” isn't a complete solution either.

Set heading and paragraph margins deliberately instead of depending on client defaults.
Use cell padding for section gutters, then check neighboring cells for unexpected spacing.
Keep floats out of essential layout unless you've tested the required clients.
Check support-test dates and reproduce important cases with your own template.

3. Use Presentational Tables and a Fluid Container

Tables remain a practical compatibility option, not a requirement for every email. When you use one for layout, add role="presentation" to each layout table and keep nesting shallow. Don't apply that role to an actual data table; preserve its headers and relationships. W3C's table guidance explains the distinction.

A Responsive 600px Email Example

A 600px desktop container is a design choice, not an email standard. This complete minimal document keeps the original nested-table approach but makes the main container fluid. The conditional wrapper supplies a fixed desktop width for classic Outlook, following the pattern illustrated by Cerberus's email templates.

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width">
  <title>Order update</title>
</head>
<body style="margin:0;padding:0;background-color:#f3f4f6;">
  <table role="presentation" width="100%" border="0"
         cellpadding="0" cellspacing="0"
         style="width:100%;border-collapse:collapse;">
    <tr>
      <td align="center" style="padding:16px 12px;">
        <!--[if mso]>
        <table role="presentation" width="600" align="center"
               border="0" cellpadding="0" cellspacing="0">
          <tr><td>
        <![endif]-->
        <table role="presentation" width="100%" border="0"
               cellpadding="0" cellspacing="0"
               style="width:100%;max-width:600px;
                      border-collapse:collapse;background-color:#ffffff;">
          <tr>
            <td style="padding:24px;text-align:left;color:#1f2937;
                       font-family:Arial,Helvetica,sans-serif;">
              <h1 style="margin:0 0 16px;font-size:24px;line-height:32px;">
                Your order has shipped
              </h1>
              <p style="margin:0;font-size:16px;line-height:24px;">
                Order A123 is on its way.
              </p>
            </td>
          </tr>
        </table>
        <!--[if mso]>
          </td></tr>
        </table>
        <![endif]-->
      </td>
    </tr>
  </table>
</body>
</html>

The non-Outlook container uses the available width up to its 600px maximum without requiring a media query. Treat this as a starting point, not a universally certified template: test longer copy, narrow reading panes, and enlarged text before adding columns or decorative elements.

The intuition behind responsive web design still applies: let content fit the available space. In email, establish a usable baseline before adding media-query enhancements.

Where Flexbox, Grid, and Accessibility Fit

For ordinary websites, choosing between the box model, Flexbox, and Grid is primarily a layout decision. For email, check the relevant per-client feature tests before making any layout feature essential. If you add an enhancement, verify that the message remains readable without it.

Use real headings, paragraphs, and descriptive links inside the layout. W3C's accessible writing guidance covers these foundations. Check text contrast too; don't rely on color alone to distinguish an action or status.

4. Host Images Reliably and Design for Blocking

Use stable, publicly fetchable HTTPS image URLs on infrastructure you control or trust. A content delivery network (CDN) is an optional hosting choice, not a compatibility requirement. Don't depend on a logged-in session, short-lived signed URL, or deployment asset that disappears when you publish the next release.

Reliable hosting cannot force a client to display remote images. Classic Outlook blocks automatic Internet picture downloads by default, subject to its trust settings and exceptions. Recipients may need to enable images before seeing them.

Compress images and export them at sensible dimensions rather than sending oversized originals.
Specify image width and height attributes; for responsive images, test proportional resizing with height:auto and an appropriate width constraint.
Write meaningful alt text for informative images and use alt="" for purely decorative ones.
Keep essential instructions, prices, order details, and action links in live text—not only inside an image.
Preview the email with images disabled, including its logo and primary action.

Alternative text communicates an image's information or function to people who cannot see it. It isn't a substitute for making the surrounding message understandable.

5. Start With Dependable Font Stacks

Arial, Verdana, and Georgia are useful starting points, but don't assume any named font exists on every device. A font-family stack supplies ordered alternatives, ending with a generic family.

/* Source CSS fragment: inline these rules where needed. */
.email-copy {
  font-family: Arial, Helvetica, sans-serif;
}

.email-heading {
  font-family: Georgia, "Times New Roman", serif;
}

A custom font is a progressive enhancement: an improvement where supported, not a dependency. @font-face defines the custom font; the font-family stack supplies alternatives when it isn't available. Email font-loading support varies, and some tested clients have fallback bugs, so inspect the actual result rather than assuming the stack always behaves perfectly.

Test headings and buttons using the fallback fonts. Leave room for different line breaks, and avoid fixed-height text containers that make a font substitution destructive.

6. Send a Meaningful Plain-Text Alternative

Send text/plain and text/html versions as parts of a multipart/alternative message. The parts represent the same information in different formats; the receiving client selects a supported alternative. Put plain text first and HTML afterward, following the ordering defined by RFC 2046.

This is the MIME structure, not a complete ready-to-send message. Let your sending library or provider construct the boundaries and encodings:

MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="email-alt"

--email-alt
Content-Type: text/plain; charset=UTF-8

Your order has shipped.
Order A123 is on its way.

--email-alt
Content-Type: text/html; charset=UTF-8

<h1>Your order has shipped</h1>
<p>Order A123 is on its way.</p>

--email-alt--

Make the text version useful on its own: preserve the essential information, action URLs, and applicable unsubscribe instructions. Read it yourself instead of assuming that stripping tags produces a good result. Plain text serves text-only viewing; it doesn't replace accessible HTML.

Test HTML Email Against a Defined Client Matrix

Start with your audience's requirements. Record the client, platform, account type where relevant, and test date. Don't put every Outlook product into one bucket: new Outlook for Windows uses WebView2, so a classic-Outlook preview isn't interchangeable with a new-Outlook test.

Suggested test group	What to inspect
Gmail web and Gmail mobile apps	Test separately; check narrow widths, spacing, links, and images.
Classic Outlook, new Outlook, and Outlook on the web	Include the variants your audience uses; compare container widths, typography, and actions.
Apple Mail on iPhone and Mac	Check text resizing, image scaling, light mode, and dark mode.
Yahoo Mail and other audience-specific clients	Add the web and mobile environments your support requirements call for.

Litmus and Mailgun Inspect, which incorporates Email on Acid tooling, provide cross-client previews and testing. They're preview and quality-assurance services, distinct from an authoring framework such as MJML. Verify that the service covers your required client variants rather than choosing by its advertised preview count.

Compile realistic content. Include long names, lengthy headings, and missing optional sections.
Inspect client previews. Check narrow screens, enlarged text, dark mode, and blocked images.
Send through your real provider. Test the delivered message after personalization, link rewriting, and other configured processing.
Check behavior, not just screenshots. Follow action links, inspect reading order, review both MIME alternatives, and verify unsubscribe behavior where applicable.

A browser preview is useful while building, but it isn't a substitute for testing in the receiving email clients. Define success as readable content, usable actions, and no broken layout—not pixel-identical screenshots everywhere.

FAQ

Should I inline CSS in HTML emails?

Use build-time inlining for essential styles when your client matrix needs it; don't hand-maintain duplicate CSS. Keep media queries in embedded styles, and test the compiled result rather than assuming inlining guarantees compatibility.

Are tables still needed for HTML email layouts?

Use presentational tables when your required clients need a conservative layout, but keep nesting shallow and add role="presentation" to each layout table. Keep real data tables semantic, with header cells instead of presentation roles.

How do I make an HTML email responsive?

Start with a fluid, single-column container capped at a comfortable desktop width, then add media-query enhancements. Keep images flexible and test narrow screens, long content, and larger text in your actual email clients.

How can I preview an email in Gmail, Outlook, and mobile clients?

Use Litmus or Mailgun Inspect for cross-client previews, then send the final message through your real delivery provider to test inboxes. Include Gmail web and mobile, the Outlook variants your audience uses, and Apple Mail; check dark mode, blocked images, and links.

Should an HTML email include a plain-text version?

Yes. Send meaningful text/plain and text/html parts in multipart/alternative, with the text part first. Include the same essential information and action URLs in both; don't treat the text part as a spam-filter workaround.