How I Test HTML Emails Before Production

Introduction

An HTML email is not finished when the code looks correct in the browser.

This is probably one of the most important lessons I have learned during more than 11 years of email development. A campaign can look perfect in Chrome and still have a broken button in Outlook, a spacing issue on mobile, an unreadable footer in dark mode or an incorrect link after it reaches the inbox.

That is why I treat testing as part of development rather than as the final task before delivery.

My testing process has evolved through production campaigns, client rendering issues, accessibility checks and repeated QA. The workflow below is the practical process I use to reduce surprises before production.

My Testing Mindset

I divide email testing into several different questions rather than trying to solve everything with one rendering screenshot.

Separating these questions makes troubleshooting much easier. If a screenshot has a problem, I can determine whether it is a structural, rendering, content or accessibility issue rather than randomly changing CSS.

My Complete Pre-Production Workflow

This is the high-level workflow I follow for a production HTML email:

Figma / approved design
        ↓
HTML email development
        ↓
Code review
        ↓
Content & copy QA
        ↓
Image / asset QA
        ↓
Link / tracking QA
        ↓
Responsive testing
        ↓
Outlook testing
        ↓
Gmail testing
        ↓
Apple Mail testing
        ↓
Dark-mode testing
        ↓
Accessibility testing
        ↓
Litmus / BrowserStack validation
        ↓
Manual visual QA
        ↓
Regression testing
        ↓
Final approval
        ↓
Production

I do not necessarily perform every step in exactly the same order for every campaign. The client matrix, campaign type and delivery platform can change the depth of testing.

Step 1: I Review the HTML and CSS First

Before opening rendering tools, I inspect the actual code.

I look for:

• Broken or unclosed HTML
• Incorrect table nesting
• Missing table attributes
• Unexpected fixed heights
• Incorrect widths
• CSS that depends on unsupported behavior
• Duplicate or conflicting styles
• Missing responsive rules
• Outlook-specific code where required
• Dark-mode classes and overrides

I also check whether the HTML remains understandable and maintainable. Email compatibility can require verbose markup, but that does not mean the code should become unnecessarily complicated.

Check:

Structure
  ↓
Tables
  ↓
CSS
  ↓
Responsive rules
  ↓
Client-specific fallbacks
  ↓
Accessibility
  ↓
Assets

Catching a structural issue here is much easier than discovering it later in six different screenshots.

Step 2: I Check the Content and Copy

A technically perfect email can still fail production QA because the content is wrong.

I check the final approved copy against the HTML:

• Headline
• Body copy
• Offer or promotion
• Dates
• Prices
• Legal copy
• CTA text
• Footer information
• Personalization variables

I also check for accidental placeholder text, duplicate content, missing copy or an outdated version of the campaign.

Step 3: I Validate Images and Assets

Images are a major part of marketing emails, so I check both the asset itself and how it is referenced in the HTML.

I verify:

• Image URL
• File availability
• Image dimensions
• Displayed dimensions
• Alt text
• Retina image handling where required
• Transparent backgrounds
• Dark-mode behavior
• Mobile scaling

I also make sure that the final production image path is not pointing to a temporary development location.

<img
  src="https://example.com/images/hero.jpg"
  width="600"
  alt="September gift card offer"
  style="display:block;width:100%;max-width:600px;"
>

A broken image can completely change the appearance of a campaign, so image validation is not something I leave until after the rendering screenshots.

Step 4: I Test Every Important Link

Link QA is one of the most important production checks because an email can look perfect and still fail its main business objective if a CTA points to the wrong destination.

I check:

• Primary CTA
• Secondary CTAs
• Product links
• Logo link
• Footer links
• Unsubscribe link
• Privacy or legal links
• Tracking parameters

I also check that links are not accidentally pointing to staging, development or placeholder URLs.

Step 5: I Test the Responsive Version

Responsive email testing is more than checking whether the email fits on a phone.

I check how each major component changes between desktop and mobile:

• Hero image
• Headlines
• Two-column modules
• Product cards
• Buttons
• Padding
• Typography
• Footer

For example, a desktop layout may be:

[ IMAGE ] [ CONTENT ]

while the mobile layout should become:

[ IMAGE ]
[ CONTENT ]

I also check that text does not become unexpectedly large or small, buttons remain usable and the spacing does not create large empty areas.

Step 6: I Test Outlook Early

Outlook gets special attention because it can render HTML and CSS differently from modern browsers and other email clients.

I specifically check:

• Buttons
• Background images
• Widths
• Heights
• Padding
• Line-height
• Two-column sections
• Vertical alignment
• Unexpected white lines
• VML components where required

Step 7: I Test Gmail

Gmail is another major part of my email testing matrix.

I check the actual email rendering rather than relying only on Chrome or a browser-based preview.

My checks include:

• Desktop rendering
• Mobile rendering
• Responsive behavior
• Images
• Links
• Typography
• Dark mode
• Long-content behavior

Gmail can also behave differently depending on the platform and environment, so I use the client matrix that is appropriate for the campaign rather than assuming that one Gmail screenshot represents every Gmail experience.

Step 8: I Test Apple Mail

Apple Mail is another important rendering environment in my workflow.

I look at typography, spacing, images, links, responsive behavior and dark mode.

I also pay attention to how the email feels on a real mobile screen. An email can technically fit the viewport and still have buttons, spacing or typography that are uncomfortable to use.

Step 9: I Test Dark Mode Separately

I do not consider dark mode automatically tested because the light-mode version looks correct.

I review:

• Outer background
• Content cards
• Text
• Links
• CTA buttons
• Logos
• Transparent images
• Footer
• Contrast

Light mode
    ↓
Dark-mode CSS
    ↓
Client rendering
    ↓
Color transformation
    ↓
Visual + accessibility review

Step 10: I Test Accessibility

Accessibility is part of my production email QA, not a separate activity that happens only when a project specifically asks for it.

I check:

• Alt text
• Decorative images
• Meaningful links
• Heading structure
• Reading order
• Color contrast
• Dark-mode contrast
• Table semantics
• Mobile readability

I have used NVDA for screen-reader testing and browser accessibility tools as part of this workflow.

Step 11: I Use Rendering and Device Testing Tools

Once the code and content are ready, I use rendering and device testing tools to validate the email across the required environments.

Two tools I have used as part of my email QA workflow are Litmus and BrowserStack.

I do not treat a tool-generated screenshot as the final approval. Tools help me find problems; I still make the final judgment based on the campaign requirements.

Step 12: I Perform Manual Visual QA

Manual visual inspection is one of the most valuable steps in my process.

I look at the email from the top to the bottom and ask:

• Does the hierarchy match the approved design?
• Are the margins and padding consistent?
• Are images aligned correctly?
• Are buttons consistent?
• Is the typography correct?
• Does mobile feel natural?
• Does dark mode remain readable?
• Does the footer look intentional?

I also look for things that a checklist may not capture, such as an awkward line break, an image that feels too large, a CTA that visually gets lost or a section that feels unbalanced.

Step 13: I Run Regression Testing After Fixes

This step is easy to forget.

Suppose I fix a button in Outlook. That does not automatically mean the job is finished. The change may affect another client, mobile spacing or the dark-mode version.

So after a meaningful code change, I revisit the relevant parts of the matrix.

Fix Outlook button
       ↓
Re-test Outlook
       ↓
Check Gmail
       ↓
Check mobile
       ↓
Check dark mode
       ↓
Final visual QA

I do not necessarily rerun every test for every tiny content change, but structural changes deserve broader regression testing.

My Final Pre-Production Checklist

I use this as a practical checklist rather than assuming that every campaign requires exactly the same depth of testing.

Common Email Testing Mistakes

1. Testing only in Chrome. Browser preview is useful during development but does not represent the final inbox experience.
2. Testing Outlook only at the end. High-risk components should be tested earlier.
3. Checking only desktop. Mobile email is a major part of the recipient experience.
4. Ignoring dark mode. A light-mode email can have serious readability problems in dark mode.
5. Skipping accessibility. Visual correctness does not guarantee usability.
6. Not validating actual links. The CTA can look perfect and still point to the wrong destination.
7. Approving screenshots without manual review. Automated rendering is a tool, not the final decision.
8. Fixing one client and not regression-testing. A change for Outlook can affect another environment.
9. Testing the wrong version of the content. QA must use the actual production copy and assets.

FAQ

Conclusion

Testing HTML emails before production is not one final screenshot check. It is a process of reducing risk across code, content, rendering, accessibility and user experience.

After more than 11 years of email development, I have found that the most effective QA process is the one that starts early and tests the areas most likely to fail.

I check the code first, validate the content and assets, test links, verify responsive behavior, check Outlook, Gmail and Apple Mail, review dark mode, test accessibility and then use rendering tools and manual QA before final approval.

The goal is simple: when the campaign reaches production, I want to know that the email has been tested against the environments that matter, the content is correct, the links work and the recipient gets the experience we intended to build.