“The email arrived” is not a sufficient test result.
A signup message can reach the inbox with the wrong recipient, an expired link, a broken mobile layout, a production hostname, or a subject line that makes no sense in another language. Good email testing follows the whole user journey and leaves enough evidence to diagnose a failure.
Temporary inboxes are useful here because each run can start with a clean address. The inbox should be disposable; the test result should not be.
Build a small, deliberate matrix
Start with the flows that can block a user:
- new-account verification;
- password reset;
- team or workspace invitation;
- change-of-email confirmation;
- sign-in link or one-time code;
- security alert after a sensitive action.
For each flow, test the happy path, one expired or reused credential, and one recipient-side error. That catches more real defects than sending dozens of identical happy-path messages.
Use one inbox per scenario
Reusing a single address creates ambiguity. An old reset message can be mistaken for the newest one, and parallel tests can consume each other's links.
Generate a unique address for every test case or test run. Record it alongside the build number, environment, locale, and scenario. If a test fails, the address becomes part of the evidence and can be inspected before retention expires.
Do not use real customer addresses in staging. It risks unwanted messages, pollutes analytics, and makes automated cleanup difficult.
Assert the envelope before the body
Before clicking anything, verify:
- The message went to the exact address created for this test.
- The sender domain is the expected one for the environment.
- The subject identifies the action without exposing sensitive data.
- Only the intended number of messages arrived.
- The timestamp is later than the action that triggered it.
These checks catch routing and duplication problems before a body parser hides them.
Test the content as a user sees it
Open the message on both a narrow and wide viewport. Check that the primary action is visible, the plain-text fallback is understandable, and long addresses or URLs do not break the layout.
For a code-based flow, verify that the newest code works once and fails after use. For a link-based flow, confirm the host and environment before opening it. A staging message that points to production is a release blocker even if the link technically works.
Also check the less glamorous details: reply-to behavior, support contact, expiry wording, locale, and the account or workspace name shown in the message.
Negative cases that earn their keep
Useful negative tests include:
- requesting a second code and confirming the first is invalidated;
- opening an expired link;
- opening the same link twice;
- changing the account state before using the message;
- inviting an address that already belongs to a member;
- entering an unsupported or malformed address;
- delaying delivery long enough to cross the expiry boundary.
These tests expose race conditions and misleading error messages that a simple inbox check will never find.
Separate product failure from delivery delay
When a message is missing, preserve timestamps for the user action, application enqueue, provider handoff, and inbox arrival when those signals are available. A screenshot of an empty inbox proves only that the message was not visible at that moment.
Use the diagnostic sequence in Verification Email Not Arriving: Find the Broken Step before filing a vague “email broken” issue.
What to automate
Automate stable contracts:
- generate a unique address;
- trigger the product action;
- poll with a bounded timeout and backoff;
- match the expected sender and subject;
- read the newest matching message;
- validate the code or link against the product;
- save useful failure evidence;
- clean up.
Keep visual review, copy quality, and unusual client behavior in a focused manual pass. Automation is good at repetition, not taste.
Reliable Temporary-Inbox API Automation covers the API side, including polling and cleanup.
A useful failure report
A report that developers can act on contains the scenario, environment, address, trigger time, expected sender, messages observed, last polling time, response status, and a screenshot or sanitized body excerpt. Never attach live secrets or reusable verification links to a public issue.
The goal is not to prove that email is unreliable. It is to identify which contract failed and leave a reproducible path to the fix.