Mark the version
Add the template version or build number to the end of the subject so messages from an old queue aren’t mistaken for the current result.
Don’t just ask whether it looks right. Check everything from the inbox list to the plain-text fallback to find issues with subjects, layouts, links, and accessibility.
Each layer matches a real interface users encounter. Change one variable at a time so results remain comparable.
A test email should include a unique ID, a clear trigger time, and verifiable expected results. Don’t change the template, recipient address, and sending configuration at the same time.
Add the template version or build number to the end of the subject so messages from an old queue aren’t mistaken for the current result.
Record the send job ID, destination address, and trigger time so you can check the queue and bounces if delivery is delayed.
Specify the subject length, button destination, mobile wrapping, and plain-text content in advance. Don’t close the issue with “good enough.”
Beautiful HTML can hide broken links, missing preheaders, or verification codes that can’t be copied. Check the facts first, then assess the visual hierarchy.
Real emails come with their own styles. Placing the body in a restricted frame prevents site CSS from rewriting the template and stops email scripts from running directly.
“The button is broken” won’t help the next tester. Record the client width, actual link, reproduction steps, and template version.
In a 390px reading area, the primary button text wraps to two lines and compresses the spacing above and below.
Record the email subject, template version, screenshot, and button destination URL.
Shorten the call-to-action copy, increase the button’s horizontal padding, and send a new version.
Use a new address to receive a uniquely numbered sample and confirm that older emails haven’t entered the results.