How to Build Responsive HTML Emails for Outlook, Gmail & Apple Mail

Why responsive HTML email is different

Responsive HTML email is not simply a smaller version of a website. Email clients can use different rendering engines, remove unsupported CSS, rewrite parts of the markup, block images, change colours and handle media queries differently.

The practical goal is therefore not to make every client behave identically. The goal is to create a resilient structure, provide sensible fallbacks and verify the final rendered result in the clients that matter for the campaign.

1. Start with a resilient email structure

A dependable email usually starts with a full-width outer table, a centered content container and nested tables for individual modules. This structure is less elegant than modern web layout, but it gives email developers a predictable foundation across clients.

Keep each module understandable: header, hero, content block, CTA, secondary content and footer. Reusable modules make campaign production and QA faster because the same patterns can be tested repeatedly.

2. Build a fluid outer wrapper and controlled content container

A common pattern is a fluid outer table with a centered inner container around 600–640px. The exact width depends on the design, but the important principle is that the outer layer can follow the viewport while the inner content remains readable on desktop.

<table role="presentation" width="100%" border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td align="center">
      <table role="presentation" width="600" style="width:100%;max-width:600px;">
        ...email content...
      </table>
    </td>
  </tr>
</table>

Use presentation roles for layout tables and keep meaningful content semantics in the text, links and controls that users interact with.

3. Make columns stack on mobile

Two-column desktop layouts often need to become one-column layouts on smaller screens. Give columns clear classes and use a mobile media query to set them to block-level width where the target clients support the rule.

@media screen and (max-width: 600px) {
  .stack-column,
  .stack-column-cell {
    display: block !important;
    width: 100% !important;
    max-width: 100% !important;
  }
}

Do not stop at stacking. Check the order of content, horizontal padding, CTA width, image scaling and the amount of text visible above the fold. A technically stacked email can still be uncomfortable to read.

4. Control typography and spacing deliberately

Email typography needs explicit values. Define font family, font size, line height, colour and spacing rather than relying on browser defaults. A fallback stack should be included because custom web fonts are not universally supported.

font-family: Arial, Helvetica, sans-serif;
font-size: 16px;
line-height: 24px;
color: #222222;

• Keep body text comfortably readable on mobile.
• Use predictable line heights for multi-line copy.
• Keep heading sizes consistent across modules.
• Use spacing that survives clients which interpret CSS differently.

5. Make images responsive and resilient

Images should have explicit dimensions and meaningful alternative text when they communicate information. For fluid layouts, a common pattern is to constrain the image with a maximum width while allowing it to shrink with its container.

<img src="hero.jpg"
     width="600"
     style="display:block;width:100%;max-width:600px;height:auto;border:0;"
     alt="Product launch announcement">

Also design for image blocking. Important promotional copy should not exist only inside an image. When an image fails to load, the user should still understand the purpose of the message and the primary action.

6. Plan for Outlook instead of fixing it at the end

Outlook compatibility is one of the main reasons email development differs from browser development. Depending on the Outlook environment, rendering behaviour can differ substantially from modern webmail and browser engines.

For production work, test the components that commonly expose differences: buttons, background images, widths, padding, line-height, columns and conditional content. VML can be used for certain Outlook-specific requirements such as bulletproof buttons and background images.

Read the Outlook HTML Email Development guide →

7. Plan for Gmail and mobile Gmail

Gmail has its own HTML/CSS processing and can behave differently across web and app environments. Avoid building the campaign around unsupported CSS features and test the actual Gmail surfaces that matter to your audience.

Pay attention to message width, image loading, clipping, link behaviour, responsive rules and dark-mode transformations. A successful desktop test does not prove that the same email is correct in Gmail mobile.

8. Plan for Apple Mail

Apple Mail generally supports more modern HTML and CSS than many legacy email clients, which makes it useful for progressive enhancement. That flexibility should not become a reason to abandon a robust baseline structure.

Use Apple Mail as an opportunity to validate typography, responsive spacing, interactive states and dark-mode behaviour while keeping the base email dependable elsewhere.

9. Build accessibility into the email

Responsive layout and accessibility should be considered together. Use semantic HTML where appropriate, meaningful link text, useful alt text and sufficient colour contrast. Layout tables should be exposed as presentation structures rather than as data tables.

• Give informative images useful alt text.
• Use empty alt text for genuinely decorative images.
• Make image-only links accessible with a meaningful accessible name.
• Do not communicate important information by colour alone.
• Keep link labels understandable out of visual context.

Read the accessible HTML email guide →

10. Consider dark mode from the design stage

Dark mode can change backgrounds, text colours and image appearance depending on the client. Instead of adding dark-mode CSS at the very end, identify the elements that need a deliberate dark-mode strategy during design.

Check logos, icons, background colours, borders, text contrast and transparent PNGs. Also test whether the client's automatic colour transformation produces an acceptable result when your preferred dark-mode rules are not fully supported.

Read the Dark Mode Email Development guide →

11. Use a repeatable QA workflow

Responsive email quality comes from testing, not from assuming the code will behave correctly. A practical workflow is:

1. Review the design and identify desktop/mobile states.
2. Build the modular HTML and CSS.
3. Check links, images and content locally.
4. Render representative Outlook, Gmail and Apple Mail environments.
5. Test mobile widths and column stacking.
6. Test dark mode where relevant.
7. Run accessibility checks and screen-reader spot checks.
8. Validate personalization, tracking and dynamic content.
9. Retest after fixes and record known client differences.

Tools such as Litmus, BrowserStack and accessibility tooling can support the process, but the important part is having a consistent test matrix and clear pass/fail criteria.

Read the HTML email QA workflow →

12. Common responsive email mistakes

1. Building like a website: using modern layout techniques without checking client support.
2. Relying on one screenshot: testing one browser or one email client is not enough.
3. Ignoring image blocking: important message copy disappears with the image.
4. Making mobile an afterthought: columns stack but spacing and hierarchy remain desktop-focused.
5. Overusing CSS: complex selectors and unsupported properties make debugging harder.
6. Skipping Outlook-specific checks: a browser-perfect email can still fail in Outlook.
7. Leaving accessibility until the end: alt text and link semantics become harder to fix consistently.
8. Not retesting after fixes: a change to one module can affect another client or breakpoint.

13. Production checklist

For a larger production checklist, explore the HTML email resources and the Templates & Tools section.

FAQ

Should responsive HTML emails use tables?

Yes. Table-based structures remain a practical foundation for production email because support varies across clients. Responsive CSS can then adapt widths, stacking and typography for smaller screens.

Does responsive email CSS work in Outlook?

Some responsive CSS works in Outlook environments, but support varies by Outlook version and rendering engine. Build a resilient desktop structure and test Outlook separately rather than assuming browser-like CSS support.

How wide should an HTML email be?

A common production pattern is a desktop content container around 600–640 pixels, with a fluid outer wrapper and mobile rules that allow content to shrink to the viewport.

How do I test a responsive HTML email?

Test representative desktop, webmail and mobile clients, including Outlook and Gmail, then validate links, images, accessibility, dark mode, personalization and responsive behaviour before deployment.

Conclusion

Reliable responsive HTML email comes from combining a resilient table-based foundation with carefully scoped responsive CSS, client-specific testing and disciplined QA. Outlook, Gmail and Apple Mail do not need to behave identically for an email to be successful; each important environment needs to receive an intentional, tested experience.

If you build email campaigns regularly, document the patterns that work, reuse tested modules and keep a client matrix. That turns responsive email development from repeated troubleshooting into a repeatable production process.

For a deeper reference covering responsive email, Outlook/VML, Gmail, dark mode, accessibility, QA, SFMC and advanced production techniques, explore The Practical HTML Email Developer Handbook.