From verification codes to receipts:
test email templates with two messages

An email arriving isn’t a pass: distinguish three outcomes

“The sending API succeeded,” “the email appeared in the inbox” and “the user can use the email correctly” are different outcomes. Acceptance by the sending service doesn’t mean the message arrived; arrival doesn’t mean the template is complete or displays consistently across email clients.

A note like “code fully readable in web preview” is more useful than a vague “email test passed.” If the email hasn’t arrived at all, first use verification email troubleshooting to check the address, expiration time and sending limits. Don’t mistake a delivery issue for a styling problem.

Prepare two test messages of your own—not real user data

Use a six-digit test code in the first message, for example 418752, along with an expiration time, a security reminder and clear context for the action. The second message should include an order number, a long product name, an amount and a payment method to reveal cramped tables and missing fields. Send both from your own test environment, use fictional orders and avoid real charges.

The PayPal and Steam demo emails on the home page illustrate how to read two types of information. They aren’t affiliated with those brands, and they aren’t proof that your sending system delivered anything. Don’t impersonate these brands when emailing others or assume that the sites they represent accept temporary addresses based on the demo layout.

Set your test conditions before changing the template

• Version the template and keep the test language, sending configuration and sample fields consistent.
• Record the test address and send time, but don’t put inbox access credentials in a ticket.
• Prepare two sets of data: typical fields and edge cases, such as a short and a long product name.
• Keep the HTML and plain-text versions generated by the sending system so you can compare them with what arrives.

Disposable addresses are kept for 3 hours by default; each extension adds another 3 hours. Use the inbox countdown as the source of truth. For longer regression tests, plan the address lifetime in advance: plan how long the address will last instead of waiting for it to expire before deciding that an email was lost.

Message one: can users find the code and act right away?

The goal of verification email design isn’t to showcase a brand; it’s to make the path from opening the email to returning to the verification page as short as possible. Start with the subject line in the inbox: can users tell whether it’s for a login, sign-up or sensitive action? Does the sender name match what they just did? Don’t crowd the subject with marketing copy and push the key information past the point where it gets cut off.

The code must be readable and easy to copy

Use real text for the six digits, not an image. Select and copy the code, then check for spaces, line breaks or other extra characters. Visual letter spacing shouldn’t change the actual code. Also test a code with a leading zero, such as 048193, to make sure the template doesn’t treat it as a number and drop the first digit.

Place the expiration time next to the code and make sure it matches the actual backend rules. If “Valid for 10 minutes” starts at issuance, users who receive the email late shouldn’t be led to think they have a full ten minutes left. For action context, show only information you actually know; don’t invent a device, location or risk assessment.

Finish by checking the security reminder: don’t share the code, and explain what to do if the user didn’t request it. Even if a code in a test screenshot has expired, hide it before sharing the screenshot publicly. The shorter and clearer the instructions in a verification email, the less likely users are to miss the information they need to protect.

Message two: do long fields stay matched with the right details?

Testing a receipt email is like checking an invoice. Use the fictional order number STM-6093-2741-58, product name Hollow Lantern: Deluxe Edition, amount $14.99 and payment method “wallet balance.” Check that each label stays next to its value. Then lengthen the order number and see whether it pushes the amount column off-screen.

Check the details before the design

Make the currency clear, and ensure the decimal places match the settlement rules. If there are taxes, discounts or refunds, the total should add up and be explainable. Never expose a full card number or payment credentials in the payment method. Omit missing optional fields or show a clear status instead of leaving “undefined” or an empty label.

If the template has a “View order” link, verify its destination, order ownership and sign-in requirements in your own test system. The fake button in the demo email doesn’t link anywhere, so it isn’t a link test. A transaction marked successful in an email doesn’t replace the order status in the payment system; use server-side records as the source of truth for real transactions.

Check narrow screens by reading again, not just shrinking the view

Start with a viewport about 390px wide, then verify on a real phone. Read the email in the order an ordinary user would: who sent it, what happened, where’s the code or amount, and what’s next? Don’t stop at a screenshot of the first screen; scroll to the bottom of the message too.

• A long order number can wrap within its field, but must not cover the label or obscure a nearby amount.
• Product names can span multiple lines; don’t truncate the part that identifies the purchased version just to keep the layout neat.
• Long button labels should wrap naturally while remaining inside the clickable area.
• After enlarging the text, check that tables, explanations and action links still appear in a sensible order.

A web inbox also has its own message list and reading pane, so distinguish overflow in the email from an issue in the page displaying it. Narrowing a desktop browser doesn’t simulate font substitution, automatic scaling or dark mode in mobile email apps.

How much useful information remains when images are off?

If images fail to load, a brand logo can disappear—but the code, amount and instructions must not. Add concise alt text to informative images; use empty alt text for decorative images so screen readers don’t announce meaningless file names. Don’t put essential information only in a background image.

Hiding images doesn’t test the plain-text fallback

An HTML email’s plain-text fallback is the text/plain content included in the email, not the result of a browser stripping out HTML tags. Check both versions at the sending end. To verify MIME structure, inspect your own sending records or use an email client that can show the original message.

The plain-text version should at least retain the purpose of the action, the full code and its expiration time—or the order number, product, amount and payment method. Give essential links enough context to make sense. Don’t just say “view the HTML version,” and make sure the text version doesn’t refer to an old amount or expiration time that has already been changed in the HTML.

If the web preview has no way to turn off images or switch to the text version, mark those checks “Not verified” and complete them in another test environment. A page that looks fine doesn’t mean you can mark both checks as passed.

Write up findings, not just “it looks a bit cramped”

A good report lets someone who wasn’t there reproduce the same issue. At minimum, include the template version, test conditions, sample details, expected result, actual result and redacted evidence. Don’t just attach a screenshot with no information about the environment.

Label results “Pass,” “Fail” or “Not verified,” and state the scope. Issues like missing content, incorrect amounts or unusable codes take priority over inconsistent margins. After a fix, send the email again; don’t close the issue just because it looks right after editing it in browser developer tools.

Where to check beyond the web preview

A web preview uses the browser’s rendering engine. Email apps such as Gmail, Outlook and Apple Mail handle HTML, styles, fonts and images differently. Security sanitization may also remove scripts, forms or other risky content; their absence from the preview doesn’t guarantee client compatibility.

Build a basic client matrix based on your actual users. For example, test Gmail on the web and in its mobile app, the specific Outlook version used in your target Windows environment, and Apple Mail on iPhone. Record the operating system and app version; “tested in Outlook” isn’t specific enough.

Check light and dark modes, restricted images, enlarged text and link behavior in each environment. If accessibility matters, verify reading order with an actual screen reader. Receiving an email in a disposable inbox doesn’t mean it passed another provider’s spam filtering, domain reputation or authentication checks. Test delivery and sender authentication separately.

Wrap up: give each test sample a clear ending

After saving the redacted records you need, delete test emails you no longer need. Deleting an individual email doesn’t immediately deactivate the whole address or erase sending logs, ticket attachments or local screenshots. Handle each copy according to its own retention rules.

Don’t use a disposable email address for production alerts, billing, password recovery or long-running regression scripts. If you need ongoing email, consider a long-term forwarding alias and check that it fits your workflow. Important accounts should still use an email address you can keep access to long term.

What matters in the end isn’t two polished screenshots, but a set of conditions you can test again: were the instructions clear, were the transaction details complete, which clients have been checked and which still need verification? For details on browser credentials and data boundaries, see the Privacy Policy.