HTML preview isn't email QA:
build an evidence pack for transactional emails

Templates change faster in 2026. Screenshots still aren't enough.

Signup verification emails often come in multiple versions: the copy changes, more languages are added, and components get updated. In 2026, teams may change a button, a variable, and an expiration notice all on the same day. A screenshot that “looks fine” won't tell you which build it came from or what inputs were used.

By the time an issue gets handed off, the test address may have expired, and developers may be unable to reproduce that unusually long username.An email testing evidence pack isn't about saving more screenshots. It's about keeping the minimum material needed to reconstruct what you observed. Record the inputs and version first, then save the results. It's usually faster than chasing details afterward.

Separate the three levels of verification

For transactional email QA, document these three things separately. “Delivered” doesn't mean “content is correct,” and “looks fine in a browser” doesn't mean “passes in the target email client.”

A more precise finding would be: “The Chinese verification email for staging build A arrived. The button is visible in the browser preview. Desktop email client testing is still pending.” That's much clearer than “Email looks good.”

The minimum evidence pack: five essentials

Create a folder for each test case, identified by its case number. Don't use real email addresses or verification codes in filenames. At a minimum, keep:

• Template version: Template ID, commit or build number, and language version.
• Test variables: Redacted inputs such as username, product name, and fallback fields; preserve their original lengths and types.
• Request details: Trigger time, time zone, request ID, test environment, and response.
• Email content: Redacted HTML, plain text if available, and any necessary metadata.
• Observed results: Expected and actual behavior, screenshots, test environment, and anything not tested.

Get template version details from the sending system or release records. If the inbox doesn't show the version, don't try to infer it from the email's appearance. Mark it as “unknown” if you can't retrieve it; don't guess.

Document a signup verification email test

Fix the inputs first; then check content and layout separately

For example, case signup-zh-longname: in staging, use a deliberately long username, copy a temporary email address, and trigger signup. Record the request ID and time. Don't edit the template right after sending, or it may be hard to tell which version produced the email.

Once the email arrives, check that variables were replaced correctly before reviewing how it looks. If the body still contains {{display_name}}, investigate variable passing or template compilation first. If the name is correct but pushes the button out of place, check width, wrapping, and layout. Both issues can occur at once, but document them separately.

Next, keep the same template version and retest with a shorter username. Change only one input to see whether the long text caused the issue or whether it affects all emails. Verify code acceptance separately with a controlled test account; a screenshot can't confirm it.

Save the email and essential metadata—not just a screenshot

Screenshots capture visual issues, but miss hidden text, actual links, and plain-text content. Save the HTML source provided by the inbox, and get the plain text and raw email from the sending system or an email client that supports export; don't mistake the previewer's generated page DOM for the original MIME email.

Record the subject, redacted recipient address, sender address, observed arrival time, and actual Message-ID if available. The Date header and your local observation time mean different things. Note each time's source and time zone; don't treat them as end-to-end delivery time.

If an image is missing, first identify why

The same blank image can have very different causes. Check the image URL type first, then record the conditions under which it loads.

• Remote images: Check the HTTPS URL, response status, access permissions, and whether the resource is still available. Email clients may block remote images by default. Don't upload image URLs with identity-related parameters to third-party tools for testing.
• CID-embedded images:cid: references MIME attachments included in the email. Tempcase temporary email doesn't store attachment data, so these images can't be displayed. A missing image here alone doesn't mean the template is broken.
• Previewer restrictions: Security policies may remove scripts, forms, or potentially dangerous resources. Compare the preview with the original email body and results in the target client; don't disable isolation just to “show everything.”

“CID image unavailable in this previewer” and “remote image returned an error” are different findings. Don't lump them together as “email image is broken.”

Check links without clicking

Verification, unsubscribe, and password reset links may trigger one-time actions. Clicking isn't a harmless way to check them; even opening a page may consume a token or change the account's state.

Inspect links as text first: check that placeholders are replaced, the domain belongs to the current environment, the protocol is correct, parameters are complete, and the expiration matches the copy. A button label in a screenshot doesn't tell you where it leads. To verify an expiration time, check the business rules and sending logs instead of guessing from the parameters.

If you need to test a redirect, use a resettable test account in an authorized environment and record what happens. Remove sensitive parameters before sharing attachments. Never post a full one-time link to a public bug tracker.

HTML and plain text: same meaning, different structure

Don't test only the polished version of an HTML email. If the system sends a multipart email, its plain-text part should also convey the essential information; some inboxes won't display rich text.

If you can't get the plain-text part, mark it “Not available; awaiting the sending team.” Don't pass off HTML with its tags stripped as the plain text that was actually sent.

Test in real email clients—and document the setup

Browser previews are useful for quickly checking variables and basic layout. For formal QA, choose real email clients based on your audience—for example, the desktop client, mobile email app, and webmail your team uses. There's no need to aimlessly test every possible combination.

For each result, record the operating system, client and version, light or dark mode, remote-image setting, display width, and zoom level. A narrow browser preview isn't the same as a mobile email app; font fallbacks, CSS support, and automatic resizing can all differ.

For cross-client comparisons, use controlled test emails triggered with the same template version and inputs. Don't mistake emails with different variable values for client-specific differences.

Compare template changes by changing one condition at a time

Prepare four purposeful input sets: long text, missing values, different language lengths, and narrow screens. First test the baseline inputs on the old and new versions, then change one set at a time. Keep screenshot width and zoom fixed so viewport changes aren't mistaken for template regressions.

• Long text: Check whether usernames, product names, or order IDs stretch the container or obscure actions.
• Missing values: Check whether empty optional fields leave stray punctuation or blank space.
• Language length: Check whether longer French or Portuguese sentences squeeze buttons, or Japanese line breaks affect meaning.
• Narrow screens: Check for horizontal overflow in the body or code, and make sure key actions remain clear.

When you find a difference, keep both the input and email-content diffs. Pixel diffs alone can be affected by font anti-aliasing and don't replace checking whether the content still means the same thing.

A bug report others can reproduce

The person taking over should be able to repeat your observation without accessing your temporary inbox. A short record like this is more useful than a long chain of chat screenshots:

When closing the bug, add the retest version and results without overwriting the original failure evidence. If you redacted or changed anything to reproduce it, note what you changed and whether the issue still reproduces.

Organize your evidence before the temporary address expires

Tempcase temporary addresses are valid for 3 hours by default. Extend them while they're active to add 3 hours per request, up to a total of 24 hours per address. The limit still applies; repeated extensions won't keep an address forever.

Securely save anything needed for handoff before it expires, following your team's retention policy. An extension only gives you more time for the current test; it isn't an archive. Once expired, the address and emails are deleted and can't be recovered. Switching to a new address also destroys the old one, so don't do that before organizing your attachments.

To keep receiving email across multiple days, you can create a long-term forwarding alias with passwordless sign-in to forward messages to your real inbox. But long-term forwarding and limited archiving still don't replace your own bug records and retention policy.

Next: carry your findings into the next test

If the email has arrived, rerun the test with fixed inputs in the email template preview workspace and add the results to the same evidence pack. If it hasn't arrived yet, start with verification email delivery troubleshooting to check the address, request, and delivery logs. Don't jump from “no screenshot” to “the template is broken.”

For repeated triggers and out-of-order emails, continue with verification code resend testing. An evidence pack isn't valuable because it has lots of attachments; it's valuable because every finding can be traced back to its inputs and observations.