Guide · updated October 2026
The email QA checklist: every check before you send
Email is the only marketing channel with no undo. A landing page typo is a quick edit; a sent email is permanent, at list scale, with a legal team reading it. That is why banks, insurers, car makers and any agency that signs off for them run a real QA pass before every send. This is that pass, written down in the order teams actually run it, with a checklist you can work through line by line and the checks that get missed most.
It is written for the person who signs off: a QA lead, a producer, an account manager who owns the client’s inbox. If you only have ten minutes, do passes 2, 4 and 5. Those are where the expensive mistakes live.
How to use this checklist
Run it on the final build, not a draft, and run it per version: every language, every segment, launch and reminder. Keep the three sources of truth open beside the email: the approved copy deck, the approved creative, and the links table. Every check below is a comparison against one of those or against a rule, which is also why most of it can be automated. Record each finding with its evidence (the deck line, the email line, the screenshot), because the developer fixing it at 5 PM needs the exact words, not “headline is wrong”.

1. Setup: what the inbox sees first
- Subject line matches the approved subject in the deck, character for character, including punctuation and the trademark symbol.
- Preheader is set, is not the first body line by accident, and is not the hidden-text trick that shows “View in browser” on an iPhone.
- The
<title>tag carries the subject (it is what some clients and all screen readers announce). - The
langattribute matches the email’s language, anddir="rtl"is set for Arabic or Hebrew. - From name and reply-to are the approved ones for this client and this campaign.
- Nothing in the HTML says test, draft, v2, lorem or a developer’s name.
2. Copy against the deck
The copy deck is the approved source of truth. The email must say what it says: headline, body, offer terms, dates, rates, calls to action, legal lines, footer. Check both directions: every deck line is present in the email, and no email line exists that the deck never approved. Read, do not skim. The misses are one word long.
- Headline, subheads and body: word for word against the deck, in order.
- Numbers: rates, dates, amounts, percentages, minimums, product codes. A single digit is a compliance incident.
- Calls to action: the button text in the deck is the button text in the email.
- Legal and disclosures: present in full, in the right version for this product and province or state.
- Copy drawn inside images (a headline in the hero, a tile) is checked too; it is still copy.
- On bilingual sends, run the pass separately per language. The most common miss is a French email carrying an English fragment, or the reverse.
- Nothing extra: no placeholder paragraph, no module the deck does not have, no leftover from the previous campaign.

There is a full method for this pass in how to QA an email against the copy deck.
3. The creative, block by block
The email your developer built and the creative your client approved drift in small ways: different padding, a cropped hero, a missing module, cards in a different order, a weight that went from bold to regular. Compare the rendered email to the approved design one module at a time, not as one long scroll. If a module in the creative has no counterpart in the email, that is a finding, not a style choice.
- Every module in the creative is in the email, in the same order.
- Nothing is in the email that the creative does not show (an extra product card is the classic).
- Hero image, logo and product shots are the approved assets, not stand-ins.
- Spacing, alignment and font weights match within reason; note what differs and let the designer decide.
- Mobile layout: stacked columns stack in the right order and nothing is cut off at 375 pixels wide.
4. Every link, and where it really goes
Click-tracking wrappers hide destinations, which is exactly why link QA fails silently: a link can carry the right label, return a 200, and still land on the wrong page. Follow each tracked link through to its final URL and compare that destination to the links table. Do it on the final build, because tracking is applied late.
- Every link in the links table is in the email, and every email link is in the table.
- Each link is followed through its tracker to the final page, and that page is the one the table names.
- UTM parameters follow the campaign convention (source, medium, campaign, content), with no typos between versions.
- Unsubscribe, preferences and view-online links resolve, and the unsubscribe is present in every language.
- No link points at a staging host, a localhost, a placeholder (
#,%%URL%%) or a page that returns an error. - Images that look clickable are clickable, and the logo links to the right home page.
- Links open the right language of the site for the language of the email.

SendLint’s email link checker follows every link in a pasted email to where it lands, trackers included.
5. Accessibility (WCAG 2.1 AA)
AA is the level procurement and regulators ask about by name, and it is now law for anyone selling into the EU. The checks are mechanical, which is good news: they can be run the same way every time.
- Contrast of at least 4.5:1 for normal text and 3:1 for large text, on every text and background pair. Legal text and footer links are the usual failures.
- Every content image has alt text that describes it; decorative images have an empty
alt=""; no image hasalt="image"or a file name. - Alt text is in the email’s language.
- Layout tables carry
role="presentation", so a screen reader does not announce rows and columns. - One heading structure, in order; links say where they go (no “click here”).
- Body copy is 14px or larger; legal copy is never under 10px.
- Nothing relies on colour alone, and nothing flashes.
The full list, mapped to the WCAG criteria, is in the email accessibility checklist.

6. Rendering, especially Outlook
What renders in your browser is not what lands in Outlook, which still lays email out with Word’s engine. Look at a real screenshot at desktop and mobile widths, then look for the Outlook risks specifically.
- Desktop and mobile renders match the creative; nothing overflows or overlaps.
- Outlook: no
width="600px"with a unit (Outlook ignores it), fixed widths on every table, line heights set withmso-line-height-rule, no background images without a fallback colour. - Animated GIFs degrade to a sensible first frame.
- Dark mode: logos survive inversion, text stays readable, nothing turns invisible.
- Web fonts fall back to a named system font, and the fallback was looked at.
- The plain-text version exists and says the same thing.
7. Spam and deliverability signals
- Image-to-text ratio is sane; the email is not one big picture.
- No trigger phrasing in the subject or preheader (all caps, FREE!!!, misleading “Re:”).
- Every link domain is one the brand owns or trusts; no URL shorteners.
- The sending domain authenticates: SPF, DKIM and DMARC are in place and aligned.
- Unsubscribe is one click and the list-unsubscribe headers are set.
8. Personalization and dynamic content
- Every merge tag has a fallback, and the fallback has been seen rendered (“Hi there”, not “Hi %%FirstName%%”).
- Dynamic blocks are checked per segment with real test records, not the default record only.
- Per-version values (product name, points, rate) are the right ones for this version.
9. The send itself
- Audience and exclusions match the brief; the seed list is on it.
- Send time and time zone are right; throttling, if any, is set.
- A test send to a real inbox was opened on a phone, in a desktop client and in webmail.
- A second person has looked at the final build, not the one before the last fix.
- Sign-off is recorded against this exact build, so a later edit cannot ride on an earlier approval.
What humans consistently miss
- Line-level copy drift on the second language of a bilingual send.
- Link destinations behind tracking wrappers: the label looks right, the page is wrong.
- Contrast on fine print and footer links.
- Alt text that exists but says nothing, or is in the wrong language.
- The reminder email reusing a stale module from the launch version.
- An image width written as
600pxinstead of600, which Outlook ignores. - Anything checked at 4:55 PM on a Friday.
The time this takes by hand
copy diff vs deck ········· ~15 min
creative, block by block ·· ~10 min
links + destinations ······ ~10 min
accessibility pass ········ ~15 min
renders across clients ···· ~15 min
one email, one pass ······· ~70 min
Multiply by languages, by launch and reminder versions, and by a round two after fixes, and one campaign becomes a working day of checking. That arithmetic is why this checklist is the thing SendLint automates: passes 1 to 7 run in one pass against the deck and the creative, every finding carries its evidence, and the report is the list you hand your developer.

Related: pre-send verification in Salesforce Marketing Cloud, bilingual email QA, and proving the sent email matches what was approved.
Frequently asked questions
- What should an email QA checklist cover?
- Nine passes: the setup (subject, preheader, title, language), the copy against the approved deck, the creative against the approved design, every link followed to where it lands, accessibility to WCAG 2.1 AA, rendering with real attention to Outlook, spam and deliverability signals, personalization and dynamic content, and the send settings themselves.
- How long does email QA take by hand?
- Done honestly, about an hour per email: 15 minutes for the copy diff, 10 for links, 15 for accessibility, 15 for renders, and a few more for setup and personalization. Multiply by languages, by launch and reminder versions, and by a second round after fixes, and one campaign is a working day.
- What do people miss most often when QA-ing an email?
- Copy that drifted on the second language, links that carry the right label but land on the wrong page behind a tracking wrapper, contrast on legal text, alt text that describes nothing, and a reminder email that reused a module from the launch version.
- Is a test send enough?
- No. A test send shows you one inbox, once. It does not compare the email to the deck, follow the links, measure contrast, or tell you what Outlook on Windows did to the layout. A test send is the last step of the checklist, not a substitute for it.
- Can this checklist be automated?
- Most of it. Copy against the deck, links, accessibility, rendering, spam signals and setup are all mechanical checks, and that is what SendLint runs in one pass. What stays with a person is judgment: whether the creative drift matters, whether a waived finding is acceptable, and the final sign-off.
Keep reading
- The email accessibility checklist: WCAG 2.1 AA for HTML emailWhich criteria actually apply to email, the checks for structure, text, contrast, images, links and motion, what fails most in real campaigns, and how to test with a screen reader.
- How to QA an email against the copy deck, line by lineThe shapes a deck arrives in, both directions, per version and per language, the parts everyone skips (subject line, alt text, links, tokens), what counts as different, and what to do when the deck is revised mid-campaign.
- How to prove the email you sent is the email that was approvedApproval usually lives in a screenshot and a thread. Here's how to bind it to the exact bytes instead, and verify any file against it later.