Layer 1: Inbox list
The subject, sender, and preheader determine whether users open an email. Check that the subject is not squeezed by environment prefixes, the sender name looks trustworthy, and the preheader does not expose template tokens or repeat the first sentence.
Add a unique identifier to the test subject so you can confirm the list shows the current version. Once the real email arrives, the demo placeholder should no longer remain mixed into the list.
Layer 2: Header and branding
Turn off images or assume remote images have failed: the brand and email type should still be clear. Logos need meaningful alternative text, and the background and body must not rely on images alone for contrast.
The header must not take up most of the reading area on a narrow screen. The brand name, notification type, and sender domain should agree; do not use visual branding to conceal a suspicious source.
Layer 3: Content order
Read the title, key facts, action, and supporting details first; the order should feel natural. Important values such as verification codes, amounts, dates, or device locations must not be buried in decorative modules.
Use a reading area around 390px wide to check wrapping and ensure tables, long URLs, and order numbers do not break the container. The body should keep its logical order even when text is enlarged.
Layer 4: Call-to-action buttons
Button copy should explain what happens after the click, rather than simply saying “Click here.” Verify the actual href, including its domain, protocol, environment, and required parameters; never infer link correctness from the button’s appearance.
Make primary and secondary actions distinct. Show a recoverable response when a button is disabled or a link has expired. Emails should not fake system buttons or trick users into submitting secrets.
Layer 5: Images and long content
Images need a maximum-width constraint and meaningful alternative text. Decorative images can use an empty alt value, but information about orders, verification codes, or steps must not exist only in an image.
Long words, tracking links, and continuous numbers should wrap instead of making the page overflow horizontally. Large attachments and remote media also require separate checks against product capacity rules.
Layer 6: Plain-text fallback
The plain-text version should include the subject facts, the complete URL for the main action, support details, and any necessary legal notices. It is not garbled text left after stripping HTML tags.
Check blank lines, lists, and link placement in reading order. Even when a client does not display HTML, users should understand what happened and complete the key action.
Reach a reproducible conclusion
Record the template version, send job, address, arrival time, client width, and actual links. Change only the necessary variables for each fix, then send a new sample with a new identifier.
Acceptance criteria should cover factual consistency, readability, usability, and fallback completeness. A polished desktop screenshot is only one part of the review and cannot replace a complete conclusion.
Open isolated preview
Use a temporary inbox to receive the new version and check its layout in a real message view.