HTML Email Basics: Examples, Structure, and Testing

HTML email is an email written with markup so it can carry headings, links, images, buttons, and brand styling. The work looks like web development until you ship it; email clients are stricter and far less consistent than browsers, and they will quietly rewrite what you send.

The safest templates lean on simple structure, inline CSS, real fallbacks, and testing in actual clients. Everything below assumes you would rather ship something plain that renders everywhere than something clever that renders in Chrome.

What an HTML email is made of

An HTML email is a MIME part containing HTML. Most marketing messages ship two parts: the HTML that controls layout, and a plain-text alternative that covers screen readers, text-only clients, filters, and people who have turned rich formatting off.

Production email adds inline styles, preview text, alt text, tracking-safe links, and mobile adjustments on top of that. If you paste website markup into an email builder, expect it to break; the two environments only look related.

Why email clients break web-style markup

Gmail, Outlook, Apple Mail, Yahoo, and every mobile client have their own quirks. Some strip scripts. Some flatten CSS. Some proxy images through their own servers, and some hide images until the reader asks for them. Outlook on Windows is the usual culprit, because parts of it still render through Microsoft Word's engine.

Can I Email tracks support for hundreds of HTML and CSS features across clients (Can I Email); check it before you commit to a newer layout pattern. CSS grid is the usual temptation, and the usual mistake. A few clients handle it, enough clients don't, and a hybrid table layout costs you an hour and survives the whole matrix.

Scripts are a separate question with a shorter answer. Most clients block JavaScript outright for security reasons, so interactivity belongs on a landing page or, where it's supported, in AMP for Email.

A layout that survives contact with the inbox

Here is a minimal announcement built the boring way:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center">
      <table role="presentation" width="600" cellpadding="0" cellspacing="0">
        <tr>
          <td style="font-family:Arial,sans-serif;padding:24px;">
            <h1 style="font-size:24px;margin:0 0 12px;">New report is ready</h1>
            <p style="font-size:16px;line-height:1.5;">
              Your deliverability report for June is ready to review.
            </p>
            <a href="https://www.mailneo.co"
               style="display:inline-block;padding:12px 18px;background:#111;color:#fff;text-decoration:none;">
              View report
            </a>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Nothing about that is glamorous, and that is the point; it will outlive a web-style layout with nested flex rules. Add complexity from there, one pattern at a time, only when the client matrix supports it.

Around that skeleton, a solid template still needs preheader text that extends the subject line rather than repeating it, one primary heading, a body width near 600px, inline CSS on anything that matters, buttons built from real HTML instead of a background image, descriptive alt text, and a footer with the unsubscribe link and postal address your sends require. For layout patterns that hold up under conversion pressure, see email templates that convert; for pairing the subject and preview line, the email preheader previewer shows the inbox view.

Testing before the send

Test in real clients, not in your builder's preview pane. At minimum: Gmail web, Gmail mobile, Outlook desktop, Outlook web, Apple Mail or iOS, and one dark-mode view. Check links, alt text, the plain-text part, the unsubscribe path, and spam risk while you're in there.

Keep the test notes beside the template rather than in a QA thread nobody reopens; client-specific fixes get deleted by the next person who tidies the markup and doesn't know why a spacer cell is there.

The responsive email tester covers layout and mobile behavior, the email accessibility checker catches contrast and structure problems, and the spam checker flags the obvious filtering risks. A missing plain-text part and broken markup both nudge your spam score upward, though markup is a small lever next to authentication and list quality; the email deliverability guide covers the levers that actually move placement.

Testing is slower than guessing. It is also much cheaper than discovering a broken template after 40,000 sends, and the click rate you lose to an unreadable render never shows up as an error anywhere in your reporting.