Verification Code Testing: Track Three Key Times

First, set the scope: test only authorized flows

Test only signup or login flows you own or are explicitly authorized to assess, and use a test environment and dedicated accounts where possible. Don’t create accounts in bulk, bypass rate limits, or use temporary email to evade a site’s address rules. If a service explicitly blocks disposable email, record that restriction instead of trying other addresses to get around it.

Write down the question you’re testing first: “Can the email be received?” or “Does resending invalidate the previous code?” Change only one condition per test. A temporary email can help you observe the user-side result, but it can’t replace the sender’s queue records, SMTP receipts, or server-side verification logs.

What to record for each of the three times

Use the same device clock throughout, and record the date, time zone, and seconds. If you use multiple devices, check that their clocks are synchronized first. T1, T2, and T3 are labels for your records; they don’t mean the backend completes every step in that order.

T1 Request submitted

Record when you click Send, then note whether the page accepts the request. A successful click doesn’t mean the server has handed the message to its email system. If you’re authorized to inspect the interface, you can also record the response time and request ID.

T2 Email first appears

Record when you first see the email in your inbox. Don’t use the date in the message body or the sender’s Date field instead; neither necessarily indicates when the receiving system got the email.

T3 Code expiry boundary

Record the expiry stated by the sender and the actual result of submitting the code separately. If you don’t know whether the timer starts at request, generation, or sending, write “start time unconfirmed” rather than guessing.

T2 minus T1 can be called the “user-side time until first visible,” but it shouldn’t be labeled “SMTP delivery time.” An expired-code message usually only shows that the submission wasn’t accepted; it doesn’t pinpoint the exact second the code expired.

Preparation: one session, one complete address

Open your temporary inbox, copy the complete address actually generated, and check that there are no extra spaces or missing characters in the signup form. The Microsoft and Uber emails on the homepage are demos, not results from a test you initiated, so don’t include them in delivery records.

• Keep just one signup tab open and label the session A. Don’t start the same action on your phone at the same time.
• Check how much time is left on the temporary inbox, leaving enough time to wait, verify, and organize your records.
• Turn off autofill or automatic retries that could change the test conditions, and set a maximum wait time in advance.
• Record the environment, browser, and goal for this test. Don’t save full verification codes or access credentials in shared documents.

New Fwdsky temporary inboxes are valid for 3 hours by default. Each successful extension adds another 3 hours; use the countdown shown as your guide. This is the inbox availability window, not the expiry period for codes from the sending site. Use our validity planner to check whether a temporary address is suitable for your test.

First test: send once to establish a baseline

Label the first request A-R1. Click Send once, and record T1 and the page response. If nothing arrives, wait as planned instead of clicking repeatedly. When the email appears, record T2, the subject, and any redacted details that can help identify it. Then submit the code on the same signup page and record the submission time and the original result category.

The example below is fictional. All times are from the same day and device, using China Standard Time. In an actual test, enter your own data.

This test supports the conclusion “first visible after 12 seconds; one submission then succeeded.” It doesn’t show that “the mail server took exactly 12 seconds to deliver the email.” To test expiry rules, start a separate test. A one-time code that has already worked can’t be used to determine on its own whether it expires after a timeout.

Seven-second polling isn’t a delivery stopwatch

Fwdsky checks the inbox automatically every 7 seconds. If one check finds no email and the next one does, the email may have become visible at any point between those checks; the page alone can’t tell you exactly when. Request processing, human reaction time, and browser background throttling can all add observation error.

Log manual refreshes too

If you refresh manually between two polling checks, note the time. Refreshing may show an email that’s already there sooner, but it doesn’t make the sender deliver it faster. Don’t directly compare a few seconds’ difference between one test that used a manual refresh and another that relied on automatic checks.

Recommended: “14:00:12 — first observed on the page; automatic checks were used in the meantime.” Avoid: “Email delivered to SMTP precisely at 14:00:12.”

For precise verification delivery testing, correlate the request ID, queue time, sender records, and receiving logs in an authorized environment, and confirm that the clocks across systems are synchronized. The user-facing page provides only part of the evidence.

Test resend behavior in a second round

Save the baseline findings first, then start a fresh record for round two. Label the first request B-R1 and, after the sender’s cooldown period, resend and label it B-R2. Record when you click, when the request is accepted, and when each email first appears. A resend may generate a new code or reuse the original one; a changed code alone doesn’t prove that a new email was sent.

Link each code to its request, not its position in the list

Don’t assume the top email always belongs to the latest request. Asynchronous tasks may finish out of order. If the message has no request ID or other reliable identifier, note “request association unconfirmed.” Use logs to correlate messages when you’re authorized to access them; don’t assign a cause without evidence.

• Check the product rules first: does resending immediately invalidate the old code, or can both remain valid briefly?
• When checking old and new codes, remember that successful verification may consume a code or end the challenge. If needed, test them in separate rounds.
• Record each verification result and follow attempt limits. Don’t keep trying codes to find the exact second they expire.

If the page only says “invalid or expired,” keep that combined category. The cause could be a timeout, prior use, replacement after a resend, or a session mismatch. Don’t automatically conclude that “the new code replaced the old one.”

Handle multiple tabs and late emails separately

Tab A might start signup while tab B starts login. Even with the same email address, these could be different challenges. Distinguish the page, purpose, and session in your records before matching emails. Don’t enter a code from B in A and then classify a failure as an email delivery problem.

If an old email arrives after a test round ends, mark it “late; from the previous round or association unconfirmed.” Keep the original request time; don’t restart the timer. If your test setup allows it, you can use a different address for a new round. But changing addresses destroys the old inbox, so you won’t be able to use it to observe later messages for the old request.

A shared browser login state can also make two tabs affect each other. If you need separate sessions, use an approved isolated test setup and record any environment changes. Simply opening another tab doesn’t create an independent session.

Classify failures before deciding what to do next

“Nothing arrived” isn’t a specific enough conclusion. Record where the failure occurred so you don’t keep refreshing at the wrong step.

Temporary inbox validity, code expiry, and the page’s resend cooldown are three separate clocks. Extending the inbox won’t extend a code that’s already been sent, and refreshing the inbox won’t make an expired code valid again.

When you’re done, save findings—not secrets

Save a redacted record of the environment, request IDs, times, waiting method, and result categories. Hide the full address, codes, session IDs, and private message content in screenshots. Don’t put inbox access tokens in tickets, chats, or shared documents. Deleting test emails doesn’t undo a third-party account you’ve already created.

After testing, clear the emails and use the tested system’s process to delete the test account or change it to an address you can keep using. Don’t rely on a temporary address for password recovery, refunds, or security notices. Clearing browser data doesn’t delete server data; see the Privacy Policy.

Next: choose an address for your email needs

For a one-time signup email, you can return to the inbox and start another test. For ongoing notifications, account recovery, or future order emails, use a dedicated long-term inbox or sign in to create a forwarding address. Aliases forward incoming messages to your real inbox, but you still need to manage account access and the alias itself.

Not sure which to use? Start with the difference between temporary email and email aliases. The goal isn’t to finish the test faster; it’s to make sure the next reviewer knows what you saw—and what you don’t have evidence for.