Guide
How to turn a brand guide PDF into email QA rules
The copy deck is the first contract; the brand guide is the second. It runs forty pages, it was written for print and web, and everyone read it once — the week they were onboarded. Email is where it gets violated most, because email templates get cloned, fonts fall back, and logos get swapped by whoever built the last campaign. The fix isn’t re-reading the PDF. It’s extracting the rules once and enforcing them on every build.
What a brand guide actually says about email
Most of the document is irrelevant to an email build. The parts that matter are small and precise, and they’re the parts that drift:
- Palette. Primary, secondary and background colors as exact hex values. An email inherits a “close enough” blue from a cloned module and nobody sees it until the client does.
- Typography. Families, the weights that are actually licensed, sizes, and the web-safe fallback stack. A headline that renders in a fallback weight passes every visual read-through and still isn’t the brand.
- Logos. Which variant goes on which background, minimum size, and dual-logo lockups for co-branded sends — the header and footer are where the wrong file hides.
- Trademarks. Where ® and ™ appear, that they render as true superscripts rather than inline text, and the bold and line-height treatment that keeps them from breaking the line.
- Layout and spacing. Template width, module padding, CTA button dimensions — the numbers that make two campaigns look like the same brand.
- Copy conventions. Capitalization rules and approved CTA wording. “Learn More” versus “Learn more” is a brand decision, not a typo.
Why the PDF can’t be the rulebook
A rule only protects you when it’s an explicit value something can test against. “Use the primary palette” is guidance; #C41F3E is a rule. “Body copy in Whitney” is guidance; Whitney 400 with an Arial fallback, 16px, 1.5 line height is a rule. Extraction is the act of turning the first kind into the second — and doing it once, so every campaign is checked against the same numbers instead of each reviewer’s memory of the document.
Provenance, or it didn’t happen
The failure mode of automated extraction is confidence without evidence: a palette of six hex values and no way to know which page they came from or whether one is the designer’s example rather than the spec. Every extracted value should carry three things — the page it was read from, the quoted source text, and a confidence level — and it should sit in a review list, not in production, until a human confirms it. A value you edit by hand should leave the review list, because you’ve now taken responsibility for it. Nothing saves until the whole change list is reviewed.
From rules to checks
Once the rules exist, they stop being a document and start being checks that run on every email: brand color compliance against the palette, font family and weight verification, dual-logo and logo-placement checks, superscript and trademark placement, CTA wording and capitalization, template width and spacing. Two properties matter here:
- A check with no rule should say so. Brand color compliance with an empty palette would silently pass everything. It should show as “Not configured” and point you at the exact section to fill in.
- Rules are per client. An agency runs a separate rulebook for each brand, copies a configuration to bootstrap a new client, and sets each check to On, Warn or Off per client — because one brand’s hard rule is another’s preference.
Done by hand vs done by machine
repeat for the next reviewer, and the next campaign
machine ··· extract once with page-level provenance, review, save;
every build is checked against the same values
This is what SendLint’s Brand Rules import does. Upload the client’s brand guide PDF (real guides run 20 to 40 MB and that’s fine) and it proposes palette, typography, widths and spacing with the page and quoted text behind each value; you review the list, confirm, and from then on those rules run as checks on every email for that client. Logo, trademark and CTA conventions live in the same rulebook and take a few minutes to enter once. Your brand review becomes a review of findings instead of a re-read of the guide.
Frequently asked questions
- What is brand rule extraction from a brand guide PDF?
- Reading the brand guide (usually a long PDF written for print and web) and turning the parts that govern email into explicit, machine-checkable rules: color palette, typefaces and weights, logo variants and lockups, trademark and superscript treatment, widths and spacing. Each rule then runs as a check on every email instead of living in someone's memory.
- Which brand rules matter most for email QA?
- The ones that fail quietly: an off-palette color inherited from a cloned template, a fallback font weight, the wrong logo variant on a dark background, a registered mark rendered as plain text instead of a superscript, and spacing that drifts between modules. A read-through rarely catches these; a rule engine catches them every time.
- How does SendLint extract rules from a brand guide?
- You upload the client's brand guide PDF on the Brand Rules tab. SendLint rasterizes the spec pages, reads them with a vision model, and returns a proposal: each extracted value with the page it came from, the quoted source text, and a confidence level. Nothing is saved until you review the list and confirm, and any field you edit by hand drops out of the review list.
- Can brand rules differ per client?
- Yes. Rules are stored per client, so an agency keeps a separate rulebook for every brand it produces email for. You can copy one client's configuration to another to start quickly, and set each check to On, Warn, or Off per client.