Email QA Checklist: Test Campaigns Before You Send

Overview

An email QA checklist is the launch gate between a finished draft and a campaign that thousands of people will actually receive. It covers copy, rendering, links, personalization, accessibility, unsubscribe behavior, tracking, audience selection, and operational readiness. The goal is not to make sending slow; it is to catch the mistakes that are expensive after the message leaves your system.

The best checklist is short enough to use every time and strict enough to stop a risky send. Treat campaign email like a release: define who reviews it, what must be tested, what evidence is required, and which failures block launch. A beautiful template still fails QA if it links to staging, greets people as `Hi undefined`, hides the unsubscribe link, or sends to the wrong segment.

Start with the message promise and recipient context

Before checking pixels, confirm the email should exist. The subject line, preheader, opening line, offer, and call to action should all match the expectation that got the recipient onto the list. A campaign that surprises the reader in a bad way creates unsubscribes and complaints even when the HTML is perfect.

Use a two-person content review for high-volume sends: one person reads as the recipient, and one checks brand, product, legal, and support accuracy. Do not let the same person who wrote the message be the only person who approves it. They are least likely to notice missing context or a misleading promise.

• Read the email once with images off and once on mobile
• Verify every date, price, feature name, discount, and deadline
• Make the preheader a continuation of the subject, not leftover template text
• Remove secondary CTAs unless they help the primary action

Test rendering, fallback content, and accessibility

Email clients still disagree on CSS support, image blocking, dark mode, and spacing. If you build with MJML or a component system, compile and test the actual HTML that will be sent, not only the source template. Outlook, Gmail, Apple Mail, and mobile clients deserve special attention because they expose different failure modes.

Accessibility is part of QA, not a nice-to-have. The W3C accessibility principles apply to readable contrast, meaningful link text, logical headings, alt text, and keyboard-friendly structure. Even when an email client limits perfect semantic markup, you can still make the message understandable when images are blocked or a screen reader reads the content linearly.

• Compiled HTML is the artifact to test
• Mobile viewport issues are launch blockers, not cosmetic bugs
• Alt text should explain the image's job, not just say 'image'
• Dark mode QA should include logos, borders, dividers, and buttons

1. Send a test to real inboxes across Gmail, Outlook, Apple Mail, and at least one phone.
2. Open the compiled email with images blocked and confirm the message still makes sense.
3. Check dark mode for invisible logos, low contrast text, and broken button treatments.
4. Confirm every meaningful image has useful alt text and decorative images do not carry noisy copy.
5. Verify the plain-text part exists and contains the same core CTA and unsubscribe path.

Validate links, merge tags, and audience data together

Many embarrassing email mistakes are data mistakes wearing a template costume. A link checker can confirm URLs return 200, but it cannot know that a personalized billing link points to the right workspace, that a coupon is scoped to the right plan, or that a first-name merge tag has an acceptable fallback.

Build a test matrix from real edge cases: a recipient with a first name, one without; a customer and a trial user; an account with multiple workspaces; a suppressed contact; and a recipient in each major locale or segment. The point is to prove the campaign handles real list shape, not only the perfect seed profile.

• Click links in the delivered test email, not only in the editor
• Use realistic seed contacts with messy data
• Check UTM naming before analytics dashboards depend on it
• Confirm suppression and unsubscribe state wins over segment membership

Make compliance and deliverability checks explicit

Compliance QA should not rely on memory. The FTC's CAN-SPAM guidance emphasizes truthful headers and subject lines, identifying the message as an ad when required, including a valid physical postal address, and providing a clear opt-out mechanism. Google sender guidelines also expect authentication, low unwanted-mail rates, and easy unsubscribe for bulk senders. Translate those requirements into visible checks before launch.

Deliverability QA is not a guarantee of inbox placement. It is a risk-reduction pass: confirm the sending domain is authenticated, the audience is permissioned and engaged, the complaint-prone segment is not included, the plain-text part exists, and the message does not contain obvious spam-filter triggers such as deceptive subject lines or broken unsubscribe paths.

• A visible unsubscribe path is safer than hiding opt-outs and getting complaints
• Reply-to should route to a monitored inbox, not a black hole
• Do not run high-risk tests from the same domain as product-critical mail
• If the audience source cannot be explained, pause the send

1. Confirm From name, From address, reply-to, and sender domain are correct for the campaign type.
2. Verify SPF, DKIM, and DMARC are already passing for the sending domain before scaling volume.
3. Check the unsubscribe link from a delivered test and confirm it updates suppression state.
4. Confirm the footer includes the required sender identity and postal information for your jurisdiction.
5. Review the audience source and exclude stale, purchased, complained, bounced, and unsubscribed contacts.

Use launch controls for scheduling, approvals, and rollback

The final QA step is operational: who can send, when it goes out, how volume ramps, and what happens if the first signals look wrong. High-volume campaigns should have an owner, an approval record, a scheduled send time, and a monitoring window immediately after launch. If the team cannot watch replies, bounces, complaints, and conversions, it is not ready to send.

For risky audiences or new templates, send in stages. Start with a seed list, then a small internal or low-risk cohort, then the main segment. Define stop conditions before launch: broken link, wrong audience, elevated bounces, elevated complaints, missing unsubscribe processing, or support confusion. A checklist is only useful if it gives operators permission to stop.

• Never schedule a major campaign when no owner is available
• Pilot sends are especially useful after template or data-model changes
• Monitor replies as qualitative QA after launch
• Document what changed if QA finds a blocker and the email is edited

Where Mailbase fits in email QA

Mailbase is relevant when QA needs to connect drafting, scheduling, segmentation, suppression, analytics, and replies in one workflow. MJML campaigns and templates make the compiled message easier to test, A/B tests and scheduled sends create natural approval gates, suppression/compliance controls help block unsafe recipients, and the shared reply inbox gives the team a place to watch post-send feedback.

AI-assisted drafts can speed up variants, but they should not skip QA. Treat AI output like any other draft: verify claims, links, personalization, accessibility, and compliance before launch. The useful workflow is not 'AI sends email for you'; it is 'AI helps draft while the checklist decides when the campaign is safe to send.'

• Use scheduled sends and A/B test drafts as approval checkpoints
• Keep suppression and unsubscribe checks in the same operating path as campaigns
• Watch replies and analytics after launch to catch issues QA could not predict
• Use MCP or internal tooling to inspect campaign state before a risky send

Common Mistakes

• Using modern CSS layout that Outlook silently breaks (use tables).
• Shipping HTML-only emails with no plain-text part — a spam signal.
• Forgetting alt text and a fallback for when images are blocked.
• Not testing on a real phone and in Outlook before sending.

Sources & Further Reading

Official docs for current setup details, pricing, and API behavior — verify specifics there, since they change.

Related guides

More on email qa checklist and the surrounding email design workflow:

FAQ

Related reading