From “Not Received”
to the Exact Stage

The bottom line: one occasional timeout does not mean the email system is down, and repeatedly clicking Send does not prove the issue is gone. In 2026, the more reliable approach is to treat each OTP trigger as a short transaction and describe it with a correlation ID, stage timestamps, and a clear outcome.

1. Build a five-stage delivery model

The first stage is the user-triggered request. Confirm that the page actually submitted, the API returned an acceptable status, and the frontend did not display a failed request as successful. The second stage is the business system generating the OTP and creating an email task; if template rendering fails, the message may never enter the sending queue.

The third stage is the email service accepting the task and attempting delivery. The fourth is the recipient system receiving and displaying it. The final stage is the user opening the message and submitting the OTP. Once the chain is separated, “the email never arrived” can become “the task entered the queue at 14:03:21, was received at 14:03:58, and appeared in the frontend list at 14:04:20.” That is something you can fix.

2. Record four timestamps using one clock

Use one new address per run, and record the trigger, API response, message visibility, and OTP submission times. When teams collaborate across time zones, record everything in UTC and retain the local-time-zone note in screenshots. Second-level precision is usually enough; there is no need for millisecond screenshots.

If you use RelayTmp for a short test, first copy the current address from the disposable inbox, then start the registration flow. Don’t change addresses midway through a test; messages from older tasks will not move to the new inbox. Create the next identity only after the current case is complete so the results remain easy to match.

Minimal timeline example

Stage	What to record	Question it answers
Trigger	Action, time, case ID	Did the user actually send the request?
Response	Status, correlation ID, duration	Did the business system accept the task?
Visible	Subject, sender, arrival time	When did the message enter the inbox view?
Use	Submission time, pass or fail	Is the code still valid?

3. Set an explainable resend wait window

The wait window should come from the product target, not the tester’s patience. If the team expects 95% of OTPs to be visible within 60 seconds, record a not-yet-arrived status at 60 seconds and make the final determination at 120 seconds. You may manually refresh the inbox during the window, but do not trigger another send.

Start the resend case only after the previous window ends. For each resend, make the system rule explicit: does the old code expire immediately, do both codes remain valid briefly, or is only the latest code accepted? Then submit the old and new codes in arrival order and confirm that the UI error text matches the backend rule. If messages arrive out of order, testing only the latest one can hide the real risk.

• Normal path: trigger once, receive the message within the target window, and use the code successfully.
• Delayed path: the first message arrives after the target window; does the code still have enough time left before expiry?
• Resend path: submit the first code before and after the second code arrives to verify the expiry rule.
• Repeated-click path: the frontend should show cooldown feedback instead of silently creating multiple tasks.

4. Package evidence into a handoff-ready bundle

A high-quality bug report does not need an entire screen recording. A minimal evidence pack should include the environment, case ID, redacted inbox address, four timestamps, visible subject, expected result, and actual result. If you can obtain a business-side correlation ID, include it with the test ID so engineers can search across logs.

Do not copy real account details associated with the OTP, and do not paste the full email body into a public ticket. Hide unrelated identity information in screenshots. Disposable email is useful for isolating low-risk tests, but it is not a compliance shortcut for handling production user mail.

5. Which metrics matter in 2026?

Averages alone hide the long tail. At minimum, track the latency from task creation to provider acceptance, provider acceptance to receipt by the target system, and receipt to user visibility. Review each by p50, p95, and p99. Segment failure rates by template, language, target domain, and sending channel; otherwise an outage affecting one region or template will disappear in the totals.

Also track the resend rate and the share of first codes that are already expired when they arrive. A rising resend rate may indicate unclear countdown feedback rather than slower delivery. A high rate of expired first codes points to a conflict between validity periods, delivery latency, and resend policy. Metrics should narrow the investigation—not replace real test cases.

6. Know what a disposable inbox can prove

A disposable inbox can show whether a test address receives a message, when it becomes visible, and whether its body and links are readable. It cannot prove that every email provider behaves the same way, nor can it bypass a sender’s restrictions on temporary domains. If a sender actively rejects the address, record that as a policy outcome instead of repeatedly changing addresses to evade it.

Payment accounts, medical accounts, work primary accounts, and any identity that must remain recoverable long term should never be tied to a temporary address. If you need to regression-test the same public identity across multiple weeks, open the email forwarding console and create a manageable alias. Keep the disposable inbox for low-risk tests that finish within a few hours.

Start a clean test run

Create a separate address and record the first timeline

Open an inbox instantly, copy the address, and refresh and read real test messages on the same page.

Open inbox