The Email Design QA Checklist Before Sending a Campaign
Email QA is not a final glance. It is the last chance to catch mistakes that only appear in the inbox.
In this article
Read the email on a phone first
Most design issues are hierarchy issues. On a phone, the hero, offer, proof, and CTA should appear in a sensible order without relying on tiny text or desktop columns. If the reader has to pinch, scroll past repeated imagery, or decode a vague button, fix the structure.
Check every functional element
Click every link and button. Confirm UTM tags, product URLs, cart links, unsubscribe and preference links, social links, and any reply-to behavior. For dynamic content, preview at least one profile that has data and one that does not.
Review accessibility and rendering
Alt text should explain the useful information in images. Text should not be trapped inside images when it carries the offer. Contrast should hold in dark mode. Buttons should be large enough to tap. Plain-text fallback should still make sense.
Finish with ESP-specific checks
The final QA pass should happen inside the sending platform. Confirm audience, exclusions, subscription type, send time, throttling rules, personalization tokens, and whether the email is used inside a workflow or sent as a campaign.
QA has reader, operator, and platform layers
The first checklist named important QA items, but it did not separate the kinds of failure. Reader QA asks whether the message is understandable on mobile. Operator QA asks whether links, merge fields, UTMs, exclusions, and sender settings are right. Platform QA asks whether the ESP will render and send the email as intended. Lumping those together makes the checklist feel longer but less useful.
A better pre-send review moves through the layers in order. First read the email as a subscriber. Then inspect every functional element. Then review platform settings. This order matters because a technically correct email can still be unclear, and a clear email can still fail if the send settings are wrong.
A QA miss that only appears after import
Imagine a generated launch email that looks good in preview. After import, the ESP strips a custom style, the two-column feature section stacks awkwardly, and a personalization token has no fallback for part of the list. None of those issues are visible in a copy doc. They show up when the asset moves into the send environment.
The article now makes that handoff explicit. Test the email in the environment that will send it, not only in the generator or design preview. Review one profile with complete data, one with missing data, and one excluded profile if the platform makes that possible. That turns QA from a final glance into a real send-safety step.
Keep evidence of what was checked
Recurring campaigns improve when QA is recorded. A simple note that says links checked, mobile checked, fallback checked, segment checked, suppression checked, and test send reviewed can prevent the same mistakes from repeating. The record also helps when performance looks strange after the send because the team can separate content issues from setup issues.
This is especially important when AI helps create the draft. Google's AI guidance emphasizes accuracy, quality, and relevance. In email production, that means checking the generated asset against real campaign constraints before it reaches subscribers. The checklist should make that review routine rather than optional.
Review the failure state, not only the ideal state
A campaign preview often shows the cleanest version of the email. Real inboxes show edge cases. A product name can wrap onto three lines, a merge field can be empty, an image can fail to load, or a dark-mode client can invert colors. The checklist should force the team to look at those failure states before the send.
One useful habit is to create a bad-data test profile. Give it a long first name, missing optional fields, an older preference status, and a product with a long title. If the email still reads well for that profile, the template is safer for the real list. If it breaks, the fix belongs in the template rules, not in one-off QA memory.
The same test should be repeated after major template changes. A QA checklist is only useful if it catches the messy cases that the team is most likely to miss when the deadline is close.
This also keeps QA from becoming personal taste. When a reviewer can point to the failing state, such as a clipped headline or empty personalization line, the fix is tied to subscriber experience rather than opinion.
Continue with