Most pre-send checklists fail for one reason: nobody reads item 23. A checklist that catches real errors is short enough to finish in ten minutes, written for the type of campaign you're actually sending, and owned by one named person rather than by the team in general.
The ten checks that catch the most damage:
- Every link, clicked
- UTM parameters, consistent
- Personalization fallbacks
- Subject line and preview text as a pair
- Rendering on your real top clients
- The plain-text version
- Sending domain and reply-to
- Seed list, opened on real devices
- Scheduling timezone
- Audience count and suppression sanity check
Below: what each check looks like in practice, how to adapt the list for promo, transactional, and journey sends, and why ownership matters more than the list itself.
Why do generic checklists fail?
The 47-point checklist you inherited from an agency handover is a compliance document, not a working tool.
It exists so someone can say the process was followed. Ask the person who ticked it what item 31 said and they won't know, because at item 12 they switched from reading to scrolling.
Three patterns show up again and again.
Length kills attention. Past roughly 15 items, completion becomes performative. People tick in batches, and the technical items at the bottom, DMARC alignment or plain-text rendering, get the least attention precisely because they sit at the bottom.
Generic items don't map to real risk. "Check the email looks good" is not a check. "Open in Outlook 365 on Windows, where 38% of this list reads" is a check. A useful item names what to look at, where, and what failure looks like.
Shared ownership means nobody does it. When anyone can complete the list, the QA happens twice or not at all. Two people each assume the other caught the broken CTA in the footer.
A fourth pattern starts earlier than the checklist. If the campaign brief never specified the segment, the offer expiry date, or who signs off, pre-send QA turns into a research project. You can't verify a spec that doesn't exist. Half the errors caught at 4:55 PM on send day were created three weeks earlier by an ambiguous brief.
What are the 10 highest-value pre-send checks?
1. Every link, clicked. Not skimmed in the editor. Clicked in a real test send, including the logo, the footer, the unsubscribe link, and the preference center. Staging URLs are the classic escape: a hero CTA pointing at staging.acme.com/spring-sale looks correct in a screenshot and returns a 403 for your list.
2. UTM parameters, consistent. Source, medium, and campaign match the convention you already use, in the same case. If your analytics contains Newsletter, newsletter, and news-letter as three separate sources, nobody trusts the attribution for this send. Confirm the parameters survived any shortener or redirect in the chain.
3. Personalization fallbacks. Send a test to a record with empty fields. Hi {{first_name}}, renders as Hi , for every contact with no first name, and on most lists that's between 5% and 20%. Check every dynamic block, not just the greeting: conditional offers, city names, loyalty tier, last purchase. For the verified fallback syntax across SFMC, HubSpot, Braze, Klaviyo, and Mailchimp, plus the five test rows that catch a broken one, see email personalization fallbacks.
4. Subject line and preview text as a pair. Read them together, in that order, as one line of text. Preview text that repeats the subject wastes the only other line you get in the inbox. Leave it blank and most clients pull whatever comes first in the body, usually "View this email in your browser." Check the pair at mobile width, where it truncates around 35 characters.
5. Rendering on your real top clients. Not 40 clients in a rendering grid. Pull the client breakdown from your last two campaigns and test the top three or four by hand. For most B2B lists that's Outlook on Windows, Gmail in a browser, and the Gmail app on Android. For B2C it usually includes Apple Mail in dark mode, where a black logo on a transparent PNG disappears. See why your email looks broken in dark mode for the other six failure patterns and how to fix each. For the full method (building that list from your own open data, and which clients earn a permanent slot regardless of share), see which email clients you should actually test.
6. The plain-text version. Auto-generated plain text breaks in ways nobody looks at: raw merge tags, alt text mixed into sentences, a wall of URLs. It matters for deliverability and for the recipients who get it. Read it once, top to bottom.
7. Sending domain and reply-to. Confirm the send goes out on the intended subdomain, that SPF, DKIM, and DMARC are aligned for it, and that the from-name is one this audience recognizes. Then check reply-to. A promotional send pointing at an unmonitored no-reply@ address quietly discards replies from your most engaged readers.
8. Seed list, opened on real devices. Send to internal seeds and open the email on a phone, not only in the platform's preview pane. Preview renderers don't reproduce image blocking, dark mode inversion, or the way Gmail clips a message over 102KB and hides your footer behind "View entire message."
9. Scheduling timezone. "9:00 AM Tuesday" is not a schedule until you know whose 9:00 AM. Check the platform timezone against the audience's, check whether local-time sending is on, and check the date twice near a daylight saving change. This is the error that produces a Sunday 3:00 AM send to your best segment.
10. Audience count and suppression sanity check. Look at the number. If the segment resolves to 412,000 and your engaged list is around 180,000, someone picked the wrong audience. Then confirm suppressions are applied: unsubscribes, hard bounces, customers who already bought the product you're promoting, and anyone in an active journey that would collide with this send.
Ten items, ten to fifteen minutes for a standard send. Short enough to finish, specific enough to fail on.
How do you adapt the checklist by campaign type?
The ten checks above are the promotional baseline.
Change the campaign type and the risk profile moves.
Promotional sends carry commercial and legal risk. Add three checks: the offer terms in the email match the landing page exactly, including expiry date and minimum spend; the discount code has been tested in the cart by someone other than whoever created it; and the compliance note from the brief has been applied, not just read.
Transactional sends carry trust risk, and they run without you watching. The checks shift from content to trigger logic: fire the trigger with a real test record and confirm it arrives once, not twice; confirm every variable populates from live data rather than a hardcoded sample; confirm the subdomain is separated from marketing traffic; and confirm what the recipient sees if a variable is null, since a shipping confirmation with a blank tracking number becomes a support ticket.
Journeys and automated flows carry timing risk. Check entry and exit criteria in both directions, so someone who converts at step two stops receiving steps three and four. Check wait steps against a calendar, because "wait 3 days" from a Friday entry lands on a Monday. Check for collisions with other active flows and scheduled campaigns. And check what happens to someone who enters on day one of a version change.
Journeys are where this stops being a pre-send task and becomes a pre-launch review of a structure. That review needs the shape of the flow visible in one place, not reconstructed from a list of assets.
Who owns the pre-send checklist?
One named person per campaign. Not "the team," not "QA," not whoever happens to be online at 5 PM.
Shared responsibility is the most reliable way to produce an unchecked send. With two owners, each does a slightly lighter pass, assuming the other is thorough. With five, nobody is.
Ownership works when three things are true. The owner is named in the brief, before production starts, so it isn't decided under time pressure. The owner is not the person who built the email, because you can't proofread your own merge tags. And the completed checklist is recorded with a timestamp and a name, so that when someone asks in three weeks why the SMS went out with a broken link, the answer is a record rather than a conversation. Rotate the role across the team, but never split it within one campaign.
That record is the part most teams skip, and the part that matters when a client asks who approved the 20% subject line. Tooling built for campaign production management handles it by attaching QA and sign-off state to each asset in the campaign. In LaunchSign, each asset carries its own production status and named approver, and the campaign can't be marked ready until the required approvals exist. See managing a campaign from brief to sign-off for how that model works end to end. This email list is one channel of the multichannel pre-send checklist; the same discipline applies to SMS, WhatsApp and landing pages. The point isn't the software. The point is that the checklist leaves a trace, and the trace has a name on it.
Get the checklist
Three one-page versions, for promotional sends, transactional sends, and journeys, with the extra checks for each type included.
Download the pre-send checklist
FAQ
How long should an email pre-send checklist be?
Ten to fifteen items. Long enough to cover links, data, rendering, deliverability, and audience. Short enough that the last item gets read as carefully as the first. If you need more coverage, split the list by campaign type rather than adding items to one master list.
Who should do the final check before sending an email campaign?
One named person who did not build the email. In-house, usually the CRM or email manager. At an agency, the account manager or a second producer. Whoever wrote the copy and built the template has read it too many times to see the error.
What are the most common errors caught in pre-send QA?
Broken or staging links, missing personalization fallbacks, wrong audience selection, inconsistent UTM parameters, and timezone mistakes in scheduling. Four of those five are configuration errors rather than content errors, which is why proofreading the copy alone is not QA.
Should the checklist be different for automated flows?
Yes. For a one-time send you're verifying fixed content. For a flow you're verifying logic that runs unattended for months: entry and exit criteria, wait timing, collisions with other flows, and behavior when a contact's data is incomplete.
