The 10-Point Email QA Checklist Most Senders Skip

If you generate a polished, on-brand template in seconds, the temptation is to hit send and trust the output. But an email QA checklist still matters, because a template that looks right in the studio can still break in an inbox, and the failure points aren’t the ones most operators think to check. The real split is between what a system should catch automatically (rendering, links, compliance basics) and what only a human eye can judge (does this actually sound like your brand, is the offer clear). Stop hand-checking the mechanical stuff, and don’t skip the judgment calls just because the template looked finished on screen.

This list is for the small business owner or solo operator who already has a generated or coded template loaded up and is one click from scheduling it. Ten checks follow, covering everything from Outlook rendering to whether the CTA actually earns a click, so you know exactly what to look at before you commit to a send.

TL;DR: The Two-Layer QA Split

The fastest email QA checklist splits into a mechanical layer a system verifies deterministically and a human layer only judgment can own.

• Automatic (let the system own it): contrast, inline styles, bulletproof buttons, dark-mode backgrounds, compliance footer, width math, sub-clipping size
• Human (your final mile): brand copy nuance, real asset swaps, edge-case client test, ESP proof read, links/UTMs, unsubscribe

The mechanical column is a solved-and-repeatable problem. A rendering rule either passes or fails, so it belongs in a system that checks it the same way every single time, not in a person’s memory of “does this look off.” This is exactly the layer EmailTemple builds correctly into every generated template from the first draft.

The human column is where judgment can’t be automated away. No system knows if your brand voice sounds right, whether the real logo you’re about to swap in actually fits the layout, or if the link you pasted points at this month’s landing page instead of last month’s. That’s the final mile, and it’s where your seven remaining minutes of QA time should go once the mechanical layer is already handled.

How We Grouped These Checks

Every check below got sorted using the same four criteria, so the list reads as one consistent system rather than ten unrelated tips. That consistency is what separates a real checklist from a pile of loosely related warnings.

Deterministic vs judgment

A check is deterministic if it has exactly one correct answer that a tool can verify without a human opinion: contrast ratios, HTML file size, whether a button renders in Outlook. A check needs judgment when the correct answer depends on context a machine can’t see, like whether a subject line matches your brand’s actual voice. We flag which is which for every entry, because that flag decides whether the check belongs to a system or to you.

Impact on inbox rendering

Some failures break the email visibly across multiple clients: a layout that overflows in Outlook, a dark-mode invert that swallows your logo, an image that never loads because of a bad src. Others are cosmetic and client-specific, affecting a small slice of opens rather than the whole send. We weigh each check by how many inboxes it can wreck if skipped.

Compliance and deliverability weight

A handful of checks carry legal or inbox-placement stakes beyond how the email looks: a missing unsubscribe link, an absent mailing address, an email that trips Gmail’s clipping threshold and hides your unsubscribe link entirely. These checks get extra weight because failing them risks more than a bad look. It risks the send not landing, or landing you in legal trouble.

How easy it is to miss manually

Some checks get skipped specifically because they’re boring or invisible when you’re rushing to hit send: sub-clipping file size, a UTM parameter pasted wrong, a stray test link left in from last week’s draft. We call out which items fall into this trap so you know where to slow down even when everything else looks fine.

These four criteria apply consistently across every entry below, which also means they double as the lens for each entry’s strengths and weaknesses. One thing most manual QA checklists get wrong: they lump every check into a single flat list and ask a human to eyeball all of it, including the checks that have one correct answer and never needed a human eyeballing it in the first place. If a check is deterministic, it belongs in a template’s built-in rendering rules, not on a person’s mental checklist.

1. Contrast Passes WCAG AA (4.5:1)

Overview

Body text in your email needs to clear a 4.5:1 contrast ratio against its background under WCAG AA, and this is a deterministic check with one correct answer, not a judgment call.

Best for: any operator sending an email where body copy, muted labels, or legal text share a background color close to the text color.

What to check

• Primary body copy: confirm your main paragraph text hits at least 4.5:1 against its background, light mode and dark mode both.
• Muted or secondary text: grey-on-light and grey-on-dark variants (timestamps, captions, disclaimers) fail this ratio more often than primary copy because they’re deliberately dimmed for hierarchy.
• Legal and compliance copy: footer text, unsubscribe language, and physical-address lines often shrink in size and mute in color at the same time, which stacks two risk factors on one line.
• Dark-mode variants specifically: muted dark-mode text must be tested against the dark background it will actually render on, not against the light-mode value you started from.

This check excludes text baked into an image, since that’s a separate accessibility problem covered later in this list.

Why it’s easy to miss

Muted greys look fine to the eye at normal reading distance, which is exactly why they slip through a visual pass. A designer picks a “soft grey” that reads comfortably on a bright monitor, then that same grey drops below 4.5:1 the moment it’s tested numerically, and drops further once a dark-mode client recolors the background underneath it.

Human vs automatic

This is Automatic. A system can calculate the exact contrast ratio between any two hex values in under a second, so there’s no reason to eyeball it and every reason to let a tool verify it every time. EmailTemple’s generation pipeline runs this exact check as part of its final self-check before a template ships, and treats a failing ratio as a blocking anti-pattern rather than a warning to note and move past.

If you want the mechanical layer handled before you ever open a QA checklist, an AI can generate the HTML with contrast verification built into the output instead of left for you to catch after the fact.

2. Critical Styles Are Inlined

Overview

Every load-bearing style in your email, meaning font size, weight, color, line-height, and layout, needs to live as an inline style="" attribute, because a number of major clients strip out <style> blocks entirely.

Best for: any operator sending HTML built or edited outside a tool that automatically inlines CSS, including hand-coded templates and exports from design tools.

What to check

• Typography styles: font size, weight, color, and line-height on body copy, headings, and CTA text all need to sit inline, not in a <style> block selector.
• Layout styles: padding, spacing, and width values that control how the email holds together also belong inline, for the same reason.
• What’s allowed to stay in a <style> block: media queries, CSS resets, dark-mode overrides, and hover states only. Anything in that block still needs an inline fallback so the email holds up if the block gets dropped.

Why it’s easy to miss

This one passes your own eyeball test almost every time, because you’re usually previewing in a client that renders <style> blocks just fine. The failure shows up downstream: Gmail webmail strips <style> blocks in specific contexts (a CSS error inside the block, a block over roughly 8KB, or mail pulled through a non-Gmail account in the Gmail app), and the email that looked finished on your screen loses its typography and spacing the moment it lands somewhere that strips the block. You won’t catch that by looking at your own test send unless you happen to test in the exact client and account type that triggers the strip.

Human vs automatic

This is Automatic. Whether a style is inline or trapped in a stripped-out block is a structural fact about the HTML, not a judgment call, so a system should verify it on every send rather than you scrolling through markup looking for stray <style> rules. EmailTemple’s studio emits already-inlined CSS on every generation instead of leaning on an ESP’s auto-inliner to catch it after the fact, which is exactly the kind of thing an AI tool built for HTML email should handle before you ever see the output.

3. Every Standalone Button Has the Outlook VML Fallback

Overview

Any call-to-action sitting on its own line needs to render as a bulletproof button, which means a VML fallback for Outlook on Windows, since Outlook renders with Microsoft Word’s engine instead of a browser engine and can’t draw rounded corners or gradients with plain CSS.

Best for: any send with a standalone primary CTA button, which covers nearly every marketing email except pure plain-text formats.

What to check

• The VML shape: each standalone button needs a v:roundrect VML element wrapped in an [if mso] conditional, specifically for Outlook on Windows.
• The live fallback: a real <a> tag renders the button for every other client, so Gmail, Apple Mail, and mobile clients all see a normal, clickable, styled link.
• The background color redundancy: the button’s <td> should carry a bgcolor attribute so the button’s fill survives dark-mode recoloring, the same double-declaration pattern that protects zone backgrounds elsewhere in the email.
• What’s excluded: arrow-links inside paragraphs or cards (“Learn more →”) are styled text, not buttons, and don’t need the VML treatment. Only CTAs that stand alone on their own line get the bulletproof pattern.

Why it’s easy to miss

A button built with plain CSS border-radius and a gradient background looks flawless in Gmail, Apple Mail, and every modern webmail client you’re likely to preview in. The failure is invisible until someone opens it in classic desktop Outlook, which almost nobody keeps installed just to spot-check a send, so a button that quietly turns into a square gray box with no visible fill goes out to your entire B2B segment before anyone notices.

Human vs automatic

This is Automatic. Whether the VML markup exists alongside the live <a> tag is a structural fact about the HTML, not something that benefits from a human squinting at a rendered preview, since the bug only shows up in a client most previews skip anyway. EmailTemple emits this dual v:roundrect plus live <a> pattern on every standalone button by default, so corners, fill, and padding survive Outlook without you needing to know VML exists. If you’d rather the mechanical layer just be correct from the first draft, generating the HTML with an AI built specifically for email rendering skips this check entirely.

4. Dark-Mode Backgrounds Are Set Twice

Overview

With roughly a third of email opens happening in dark mode, every zone background in your template needs to be declared twice, once as a bgcolor HTML attribute and once as an inline background-color style, so a recoloring client respects at least one of them.

Best for: any multi-zone template (hero, body, footer, alternate sections) where a client might force dark-mode recoloring on top of your design.

What to check

• Double-declared backgrounds: every zone, promo strip, and footer should carry both the bgcolor attribute and the matching inline background-color on the same element, not just one or the other.
• No pure white or pure black: large surfaces and body text should avoid absolute #FFFFFF and #000000. Near-tones invert to something usable under forced dark mode; pure extremes invert harshly and crush the hierarchy you built.
• Logo stability: a dark-on-transparent logo needs an explicit background cell behind it so it doesn’t vanish when the surrounding zone recolors.

This check excludes baking color or copy into an image as a dark-mode workaround. That’s a separate anti-pattern worth flagging on its own, not a fix for this one.

Why it’s easy to miss

Your default-mode preview looks exactly right, because that’s the mode you’re viewing it in. Dark mode doesn’t announce itself in a standard test send; it only shows up when the recipient’s client is actually set to dark, and clients handle it three different ways (no change, partial invert, full invert), so an email that looks fine in one client’s dark mode can still crush its own contrast or swallow a logo in another.

Human vs automatic

This is Automatic. Whether a background is declared once or twice is a markup fact a system can grep for, not something that needs a human toggling dark mode on and off across a dozen clients to catch by eye. EmailTemple treats dark mode as a first-class design mode on every generation, declaring every zone background twice by default and avoiding pure white or pure black on large surfaces, so this check passes before you ever open a preview pane. To see how your own template holds up before you send, run it through a free dark mode email tester.

5. Compliance Footer: Unsubscribe and Physical Address

Overview

Every marketing email needs a visible unsubscribe link (never hidden, never zero-opacity) and a physical mailing address in the footer to meet CAN-SPAM and GDPR requirements, and this one carries legal weight beyond a rendering glitch.

Best for: any marketing send, since transactional emails carry different (lighter) compliance expectations but this checklist is built around promotional and lifecycle sends.

What to check

• Unsubscribe link presence and visibility: the link needs to actually be there, and it needs to be readable, not set to zero opacity or buried in a color that matches the background.
• Physical mailing address: a real address in the footer, not omitted or swapped for a generic placeholder.
• Legal copy formatting: footer and compliance text should sit in sentence case, not an all-caps wall, and should be left- or center-aligned rather than justified, since justified legal text creates uneven word spacing that’s harder to read at small sizes.

Why it’s easy to miss

The footer is the last thing anyone looks at when building an email, and it’s the first thing skipped when a send is rushed. It’s also structurally at risk: if the total HTML runs too large, Gmail clips the message and hides everything past the cut, which very often means the unsubscribe link and address disappear behind a “view entire message” link the recipient never clicks. This check overlaps directly with the file-size check later in this list, and a failure on one quietly causes a failure on this one too.

Human vs automatic

This is mostly Automatic for presence and formatting. A system can confirm the unsubscribe link and address exist, are visible, and sit in sentence case without justified alignment. The one piece that needs a human eye is confirming the unsubscribe link actually resolves once it’s live in your ESP, which belongs to the proof-read check later in this list rather than this one. EmailTemple makes a visible unsubscribe link and physical address mandatory in every generated footer by default, so the presence check is already handled before you open the template. For more on how the mechanical layer of a send gets built correctly from the start, see how AI can generate compliant HTML email.

6. Layout Math and Font Fallbacks

Overview

Every horizontal row in your email has to add up to 600px or less, and every font-family declaration needs to end in a web-safe fallback, so the layout holds together in Outlook and the typography doesn’t collapse when a web font fails to load.

Best for: any template with multi-column rows (image-plus-text layouts, stat bars, feature grids) or a custom brand font.

What to check

• Row width math: outer padding, plus the inner table width, plus cell padding times column count, plus the column widths themselves, all need to total 600px or less for the widest row in the email. Padding should apply once per row, never doubled on both the outer wrapper and the inner cell.
• Font fallback stacks: every font-family declaration needs to end in a safe fallback like -apple-system, Helvetica, Arial, sans-serif, not just the brand font on its own.

Why it’s easy to miss

A wrapper cell with 32px of padding on each side, containing an inner table whose cell also carries 32px of padding, sums to roughly 664px once you add the actual column widths, which quietly overflows the 600px container and breaks in every version of Outlook while looking fine anywhere the browser engine is forgiving about overflow. The font side of this fails just as invisibly: skip the fallback stack and most clients will substitute Times New Roman the moment your custom font doesn’t load, and you won’t see it happen because your own preview almost certainly has that font installed.

Human vs automatic

This is Automatic. Row math is arithmetic a system can walk before the email ever ships, and a missing font fallback is a simple string check, neither of which benefits from a person eyeballing a preview that happens to render correctly on their own machine. EmailTemple walks the widest row in every template before output and attaches a web-safe fallback stack to every font declaration by default, so this check is already satisfied by the time you’re looking at the result. If you want this handled at the generation step instead of the QA step, an AI-written HTML email that accounts for layout math from the start removes the need to check it later.

7. Total Size Stays Under the Gmail Clip Threshold

Overview

Gmail clips any email whose HTML exceeds roughly 102KB, hiding everything past that cut behind a “View entire message” link, so the safe move is keeping your total document comfortably under that ceiling.

Best for: any content-dense send, newsletters, product updates, or anything with several image-heavy modules that can push file size up without you noticing.

What to check

• No base64 data-URI images: an image encoded directly into the HTML as base64 bloats the file fast and is always a bug, not a style choice.
• No unbounded repeated markup: watch for anything that duplicates a block, a divider, or a spacer without limit. Extra repetition adds size without adding value.
• Images referenced by hosted URL: every image should point to a real hosted link, not be embedded as raw data.
• Critical content positioned above the likely clip point: the CTA and the unsubscribe link should sit early enough in the document that they’re never at risk of falling below Gmail’s cut.

Why it’s easy to miss

The email sends and looks completely normal in your own inbox, because your test send is almost certainly under the threshold or your client doesn’t clip visibly the way Gmail does. The failure is silent on your end and invisible to you unless you specifically check file size: a recipient on Gmail just sees “[Message clipped] View entire message” and, in practice, almost never clicks through, which means your footer, your unsubscribe link, and your final CTA effectively don’t exist for that portion of your list.

Human vs automatic

This is Automatic. Total HTML size is a number a system checks in an instant, and there’s no judgment involved in whether a document is 60KB or 130KB. EmailTemple targets under roughly 80KB per generated document and bans base64 data-URI images outright, which keeps every template well clear of Gmail’s clip point by default rather than leaving it as something you discover after a send. That’s the kind of check you can hand to a free HTML email tester, not a person scrolling through markup counting kilobytes.

8. Review Brand Copy Nuance and Swap Real Assets

Overview

This is where the human final mile starts: only you can judge whether the copy actually sounds like your brand, and only you know which images are the real ones you intend to send.

Best for: any send where the template was drafted with placeholder content, generated stand-in copy, or generic stock imagery before the real assets were ready.

What to check

• Tone and voice: read the copy the way a subscriber would, and ask if it sounds like you, not like a generic template filled in with the right nouns.
• Phrasing a spell-checker misses: awkward sentence construction, an accidentally repeated word, or a phrase that’s technically correct but reads wrong. Spell-check catches typos, not tone.
• Real assets in place: confirm the logo is your actual logo, the product photos are the ones you meant to send, and the hero image isn’t still the placeholder that got dropped in during drafting.

Why it’s easy to miss

Placeholder images and stand-in copy do their job too well: they fill the layout convincingly enough that a quick scroll-through looks finished, so teams ship with a generic hero shot or a half-written subject line still sitting in the template because nothing structurally looks broken. The mechanical checks earlier in this list won’t catch it either, since a placeholder image renders perfectly fine. It’s just the wrong image.

Human vs automatic

This is Human. No system can decide whether a sentence sounds like your brand or whether the photo you dropped in three drafts ago is actually the one you want going out, because those calls depend on judgment a machine doesn’t have access to. This is exactly the kind of check EmailTemple hands back to you: the studio gets the mechanical layer (Outlook-safe structure, dark-mode-safe zones) right on the first pass, specifically so your seven minutes of manual QA go toward reading your own copy and checking your own assets instead of hunting for a missing VML fallback.

9. Send Yourself an ESP Proof and Read It Everywhere

Overview

Send a real proof from your actual ESP, not just the in-builder preview, and read it on your phone, your laptop, and in dark mode before you trust it enough to send.

Best for: any send you’re about to schedule, and especially any high-stakes campaign (a launch, a big promo, a sequence opener) where a rendering surprise costs more than usual.

What to check

• A real ESP-sent proof, not just a preview pane: the builder’s live preview and an actual test email that traveled through your ESP’s sending infrastructure are not the same thing. Send the real proof.
• Read it on your phone and your laptop: mobile and desktop rendering can diverge even within the same client, and roughly half or more of opens happen on mobile, so skipping that read means skipping the majority experience.
• Toggle dark mode on the device you’re reading from: confirm nothing crushes or disappears once the device forces its own color scheme on top of your design.
• For high-stakes sends, run an edge-case client test: a tool like Litmus or Email on Acid checks rendering across a wide spread of clients at once, which catches the odd Outlook version or webmail quirk a two-device manual read can’t cover.

This check is about real-inbox behavior, not a repeat of the rendering rules already covered earlier in this list.

Why it’s easy to miss

The in-builder preview looks finished, so it’s tempting to treat it as proof the email is ready. It isn’t: a preview pane doesn’t always reflect how your ESP’s actual sending infrastructure renders the message, and it definitely doesn’t show you dark mode unless you toggle it on the device itself. People skip the real-inbox read specifically because the preview already looked convincing, which is exactly the moment a mismatch slips through.

Human vs automatic

This is Human. The last read before a send is a judgment call. It’s not about checking a fact against a rule; it’s about a person looking at the actual result and deciding if it feels right to go out. No system replaces that final look, and it’s the one step in this checklist that deserves your full attention precisely because the other nine have already been narrowed down to what actually needs a human. If you’d rather spend that attention on the proof read instead of also hunting for structural bugs, starting from HTML built for email rendering means this step is the only thing standing between you and send.

10. Confirm Links, UTMs, and the Unsubscribe Work

Overview

Before you send, click every link and image, confirm your UTMs are present and consistent, and verify the unsubscribe link actually resolves to a working opt-out page.

Best for: every send, but especially any campaign with multiple CTAs, tracked links, or personalization tokens where one destination can slip through wrong.

What to check

• Every hyperlink and CTA: click through each one and confirm it lands where you meant it to, not a leftover staging URL or last month’s landing page.
• UTMs present and consistent: tracking parameters should be on every link that needs them, using the same naming convention, so your analytics don’t fragment the same campaign into five different labels.
• The unsubscribe link resolves: don’t just confirm it’s visible (that’s the automatic check earlier in this list). Click it and confirm it actually lands on your opt-out page.
• Phone numbers and dates: if a phone number is listed, call it. If a date appears anywhere in the copy, confirm it matches the actual send or event date.

This check sits apart from deliverability infrastructure like SPF, DKIM, and DMARC, which live at the domain level and aren’t something a template controls.

Why it’s easy to miss

A broken link or a missing UTM doesn’t show up visually. The button still looks right, the text still reads fine, and nothing about the layout signals that the destination is wrong. This is exactly the kind of thing that slips through when a send is rushed near a deadline, because the failure is invisible until someone actually clicks.

Human vs automatic

This is Human. Where a specific link should point, what UTM values this specific campaign needs, and whether this send’s dates are actually correct all depend on context only you have for this particular email. No system can verify that “this button should go to the July sale page, not the June one” without knowing your campaign plan.

That’s the real shape of a fast, reliable email QA checklist: nine checks a system verifies deterministically, and one final click-through that depends on judgment about this specific send. Get the mechanical layer built right from the start and the checklist gets a lot shorter. EmailTemple generates that layer correctly on the first pass, so the seven minutes you have left go toward the two or three checks that actually need you.

Email QA Checklist Comparison Table

The table below pulls all ten checks into one view, sorted by which layer owns them and what actually breaks if you skip one. Use it as a quick reference once you’ve read the full breakdown above, or as a final scan before you hit send.

How to Choose What to Automate vs Check by Hand

Not every item on an email QA checklist deserves the same kind of attention. The ten checks above split cleanly across three questions, and running a check through them tells you whether it belongs to a system or to your own eyes.

Is the rule deterministic

A deterministic rule has exactly one correct answer that doesn’t depend on context: a contrast ratio either clears 4.5:1 or it doesn’t, a row either sums to 600px or it overflows, a VML fallback either exists or it doesn’t. If a check has one right answer, automate it and stop spending judgment on it. Judgment is a limited resource, and burning it on arithmetic a tool could verify in a second is the fastest way to run out of attention for the checks that actually need you.

How high are the stakes

Compliance and clipping failures don’t cost you a slightly-off layout. They cost the entire send. A missing unsubscribe link is a legal exposure, and an email that trips Gmail’s clip threshold hides that same unsubscribe link behind a “view entire message” link almost nobody clicks. Checks with that kind of downside deserve a system checking them on every single send, not a mental note that’s easy to forget on the one day you’re rushing.

How often does it break silently

Some failures announce themselves. A typo shows up the moment you read the copy. Others don’t: dark mode and Outlook rendering bugs are invisible in whatever client you happen to be previewing in, which means the check only fails for someone else, somewhere you can’t see it happen. Anything that fails silently in your own default view belongs in the automatic layer, because a human checklist item you can’t actually observe failing isn’t a check, it’s a hope.

Anti-patterns to scan for

Beyond the ten checks already covered, a few structural red flags are worth a deliberate scan before send:

• Button soup: three or more competing primary buttons in one email, which destroys the single-action hierarchy a good send needs.
• Weak hierarchy: no clear path for the eye from headline to CTA, so the reader has to hunt for what they’re supposed to do.
• Broken placeholder image URLs: leftover via.placeholder.com or similar stand-in links that never got swapped for real hosted images.
• Pure white body text on a dark background: technically visible, but harsh enough to strain the eye on any long read.
• Pure black dark-mode backgrounds: crushes visual hierarchy instead of giving zones room to read as distinct.
• Three or more typefaces: a template that never settled on a two-tier type system reads as unfinished, not intentional.
• Modules that break when hidden or reordered: a section that depends on a neighboring block to make sense structurally, which becomes a problem the moment someone edits the send later.

The throughline across all of this: the mechanical layer, contrast, inlining, VML, dark mode, layout math, file size, compliance, should never depend on a person remembering to check it. EmailTemple builds every one of those rules into the template on generation, which is exactly why an AI can be trusted to write HTML email correctly from the first draft, freeing your actual QA time for the handful of checks only you can make.

Frequently Asked Questions

What is email QA?

Email QA, or quality assurance, is the process of checking an email before you send it to confirm it renders correctly, functions as intended, and complies with legal requirements. That covers whether templates and footers work, whether copy is error-free, whether links and buttons go where they should, and whether the email displays properly across the email clients your list actually uses.

For campaigns using personalization or dynamic content, QA also means confirming the right version reaches the right segment, and that every merge tag still reads properly when its field is empty — which a free merge tag tester will show you.

What should be on an email QA checklist?

A solid checklist splits into two layers: mechanical checks with one correct answer (contrast, inlined styles, Outlook-safe buttons, dark-mode backgrounds, compliance footer, layout math, file size) and human checks that depend on judgment about this specific send (brand voice, real assets, a proof read across devices, and confirming links and tracking resolve correctly). The ten checks covered above walk through both layers in order.

The mechanical checks should already be true before you open the email to review it. The human checks are where your actual attention belongs.

How long should email QA take?

The mechanical layer takes no time at all if it’s built into the template from the start, since a system verifies contrast, rendering, and file size instantly rather than you checking each one by hand. The human final mile, reading your copy, confirming your assets, sending a real proof, and clicking every link, takes a focused pass rather than hours of scattered checking.

If QA is eating your afternoon, the mechanical layer is probably the part going wrong, not the human layer.

Do I need Litmus or Email on Acid for every send?

Not for every send. These tools are worth the cost for high-stakes or regulated campaigns, a major launch, a big promo, a compliance-sensitive send, where a rendering surprise across dozens of clients would cost more than the subscription.

For routine sends, a proof read across a couple of real devices plus dark mode covers most of what actually goes wrong, and the mechanical checks earlier in this list already cover Outlook and rendering edge cases if your template was built correctly from the start.

Why does my email look different in Outlook?

Outlook on Windows renders HTML and CSS using Microsoft Word’s layout engine instead of a browser engine, which is why it handles email markup so differently from Gmail, Apple Mail, or Yahoo. Word’s engine doesn’t support things like CSS border-radius or background-image the way a browser does, which is exactly why bulletproof buttons need a VML fallback and why layout math (row widths summing to 600px or less) matters so much.

Most rendering quirks that show up specifically in Outlook and nowhere else trace back to this one root cause.

Is one QA checklist enough for dark mode?

No, not if that checklist only covers default mode. Email clients handle dark mode in different ways, some leave your colors alone, some partially invert them, some fully invert them, so you need to check both default and dark mode explicitly rather than assuming one pass covers both.

Roughly a third of email opens happen in dark mode, which is high enough that skipping this check isn’t a minor gap.

Can email QA be automated?

The deterministic layer, yes. Anything with one correct answer (contrast ratios, inline styles, VML fallbacks, dark-mode backgrounds, layout math, file size, compliance footer presence) can and should be checked automatically rather than left to memory.

Judgment can’t be automated. Whether your copy sounds like your brand, whether this specific link should point to the July page or the June one, and whether the proof read looks right in your own inbox all depend on you.