Guide · updated October 2026

How to QA an email against the copy deck, line by line

The copy deck is the contract. Legal read it, the client signed it, and the email must say what it says, no more and no less. Most teams “check the copy” by reading the email top to bottom with the deck open beside it. That catches the big misses and reliably ships the small ones: a date off by a day, a rate with the wrong decimal, a legal line from the previous campaign. This is the comparison done properly, by hand or by machine.

What a copy deck is, and the shapes it arrives in

A copy deck is the approved text of every email in a campaign, in order, with the parts a reader never sees: the subject line and preheader, the alt text for each image, the links table, and the legal block. In practice it arrives in one of a few shapes, and the comparison has to read each one for what it is:

• A sectioned Word document. One heading per version (Launch, Reminder, Last chance), one row per section (Preheader, Headline, Body, CTA, Legal), English and French side by side.
• A matrix deck. One table, one row per version, columns for the copy that differs: the rate, the product name, the offer date. Twenty versions in two languages fit on one page, and the comparison has to pick the right row for each email.
• A designed PDF exported from a review tool, with the copy laid out as the email will look. The text is there, but the structure has to be recovered.
• Copy in one file, links in another. The writer delivers the copy; the links come later in a spreadsheet with a URL column and a click alias; the French arrives as its own document a week after.
• A rendition. In regulated industries the deck is a system export with approval codes and a claims table, and the comparison has to ignore the furniture.

Whatever the shape, the first step is the same: read the deck into versions, languages and sections before comparing anything. The Prepare a deck tool does exactly that, and shows you what it read so you can check it before trusting it.

Both directions, always

One direction asks: is every deck line in the email? The other asks: is every email line in the deck? Teams run the first and skip the second, which is how unapproved copy ships: a leftover module from the cloned template, a developer’s placeholder headline, a stale legal paragraph, a footer line nobody wrote. If a sentence in the email has no source in the deck, that is a finding even when the sentence is fine.

Respect the deck’s own structure

A production copy deck is not prose; it is sectioned. Compare section to module, not wall of text to wall of text, and read the deck’s own conventions before comparing:

• Version numbering is campaign-wide. Decks commonly label the launch email Version 1 and the reminder Version 2. A comparison that asks the reminder for “version 1” silently reads launch copy and floods the report with false differences. Match each email to its version by the subject line, the product code in the file name, or the copy itself, and say which one was picked.
• “Same as launch” is an instruction, not text. When a reminder section says it, the comparison must pull the launch section’s copy, not flag the literal words as missing from the email. The same goes for “TBD”, “dev to confirm” and the writer’s notes in brackets.
• Shared rows apply to every version. A legal block written once at the bottom of the deck belongs to all twenty versions; a row that names a version belongs only to it.
• The deck says which language it is. A French build compared against the English column fails every line and tells you nothing. Pick the column by the email’s own language, and stop if they disagree.

The parts everyone skips

• Subject line, preheader and title. The deck has them; the email has them in three places (the subject, the hidden preheader div, the title tag), and a reminder sent with the launch subject line is the most common miss of all.
• Alt text. Decks declare alt text per image. The email’s alt must say what the deck says: “Gift box icon” is not “Gift box bursting open with points”, and a rating scale with alt="1" through "5" is an accessibility finding hiding in plain sight. Alt text in the wrong language is a finding too.
• The links table. Decks list every link’s label and destination. Match by destination when you can; when click tracking hides the URL, follow the wrapper to where it actually lands. A correctly labelled link to the wrong page is the miss that label checking can never catch.
• Placeholders and tokens. %%FirstName%% and friends should compare as wildcards, not as literal mismatches, but a token present in the email and absent from the deck (or the other way round) is real. Values that differ per version (the rate in version 4, the fee in version 9) have to be compared against that version’s value.
• Marks and footnotes. ®, ™ and the French MD, superscript footnote markers, and the legal lines they point to. A deck that says “Rewards®” and an email that says “Rewards” differ in one character that legal cares about.
• Words inside pictures. A headline the designer drew into the hero image is copy, and the deck has a line for it. It has to be read out of the picture to be compared at all.

What “different” should mean

Case, whitespace, punctuation spacing and smart-quote substitutions are build noise; a QA comparison should read through them, and through the non-breaking spaces French typography puts before a colon or a dollar sign. A changed word, a dropped clause, a different number, a missing sentence: those are the campaign. The worst output a comparison can produce is “73% similar, verify manually”. It does the reading and leaves you the homework. A useful verdict is binary, with the deck line and the email line shown whole, side by side, and the differing words marked.

Bilingual and multilingual decks

A bilingual deck is one deck with two columns, and the comparison runs once per language with its own rules: French typography (the spaces before punctuation, the currency format, the accents), language leaks (an English sentence in the French build, usually the footer boilerplate or an alt text), and parity (a disclosure present in one column and missing from the other is a deck finding before it is an email finding). The full method is in the bilingual email QA guide, and it extends to Arabic, Spanish or any other language the deck carries.

When the deck changes mid-campaign

Decks get revised. Version 27 goes to the client, round 1 is checked against it, the client comes back with changes, and round 2 has to be checked against version 28. The mistake is to re-read every email against the new deck as if nothing had been checked. Compare the two decks first: which lines changed, in which versions, in which language. Those lines are the round’s scope; everything that passed last round and did not change in the deck should still pass, and anything that failed should now be fixed.

SendLint’s Deck compare tool does this for two deck files, per version and per language, and saves the result as a PDF for the round’s record. Inside a campaign, SendLint keeps the deck history and runs the new round against the revised deck while carrying every finding forward.

Done by hand vs done by machine

This comparison is the core of what SendLint automates. Attach the deck once per campaign, in whatever shape it arrived, and every analysis reads the right version and the right language column, honours same-as-launch markers and shared rows, compares the subject line, every section, every alt text and every link destination, treats tokens as tokens, reads words out of pictures, and reports binary verdicts with both lines shown whole. Your read-through becomes a review of findings instead of a hunt for them, and the findings carry from round to round until they are fixed.

This is pass 2 of the full email QA checklist. For the links half, see the email link checker.