Responsive email QA checklist: what to test before every send

Pull the email-client breakdown from your ESP or analytics, then decide which clients are must pass, which are should pass, and which are acceptable degradation. A B2B list is often Outlook-heavy. A consumer list is often Apple Mail and Gmail on mobile. Testing everything equally wastes time; testing nothing in Outlook costs you the most.

• Single-column layout holds at 320px, 375px and 414px wide, and the desktop layout holds at 600 to 700px.
• Text is at least 14px on mobile, with enough line height and tap spacing.
• Tap targets (buttons, links) are comfortably large, roughly 44px high.
• Stacked columns stack in the intended order, and no horizontal scroll appears.
• Tables, padding and spacing hold in Outlook desktop (Word rendering engine), which ignores much of modern CSS. Use ghost tables and VML for rounded or background-image buttons if the design needs them.
• Fonts fall back sensibly when web fonts are not supported.

• Every image has meaningful alt text, and decorative images have empty alt.
• With images blocked, the email is still understandable: key message in live text, buttons built as HTML rather than image buttons.
• Images have explicit width and height and are sized for retina where it matters.
• Background colors behind images match the design so blocked images do not leave white holes.
• File sizes are reasonable and the total HTML stays under Gmail's clipping threshold (about 102KB; verify the current number).
• Animated GIFs show a sensible first frame, since some Outlook versions show only that.

• Test in Apple Mail, Gmail (app and web) and Outlook dark mode. They each invert or adjust colors differently.
• Logos with dark text need a light-safe version, a transparent PNG with an outline, or a swap using dark-mode media queries where supported.
• No pure-white image backgrounds that will glow on a dark canvas.
• Text and button contrast hold after inversion.
• Declare color-scheme and supported-color-schemes meta tags and test that they behave as expected.

• Set lang on the HTML element and a meaningful title.
• Layout tables use role="presentation".
• Headings and reading order make sense when read linearly.
• Link text describes the destination ("View your order"), not "click here".
• Color contrast meets WCAG AA for text and buttons.
• Do not convey meaning through color alone.

Most embarrassing sends are data problems, not rendering problems. Test with a seed list of deliberately awkward records:

• Blank first name, very long name, name with an apostrophe or accents.
• Missing product image, missing price, out-of-stock item.
• Empty arrays (no items in cart, no recommendations).
• Non-English characters and right-to-left text if you send them.
• Date, time zone and currency formatting for each locale.

Every merge field needs a fallback, in AMPscript, Liquid or whichever language you use. See how this fits into a rollout in the Braze implementation checklist and the SFMC migration checklist.

• Every link resolves and goes to the right page, with correct UTM or tracking parameters.
• Unsubscribe and preference-center links work and land on the right state.
• Physical address and legal footer are present.
• The plain-text version exists and reads sensibly.
• From name, subject line and preheader are correct, with the preheader not pulling in stray text from the body.
• Authentication passes (SPF, DKIM, DMARC) and the message does not trip spam filters.

Checklists catch mistakes, but the best way to reduce defects is to build from tested components. If your header, button, product card and footer have all been through QA once, a new email only needs its new parts tested. That is the core argument in the benefits of email component libraries and design systems.

A practical routine:

1. Developer self-check against this list.
2. Rendering tests in a testing tool across the must-pass clients.
3. Seed-list send with awkward data records.
4. Second-person review of copy, links and legal.
5. Final proof of the real send, not just the template preview.