Before you start, establish a clean baseline
Prepare the target environment, access to sending logs, and a new test email address. Don’t use real customer names, identity documents, payment information, or production verification codes. If the flow creates an account, first confirm you’re authorized to clean up test accounts.
Make sure the address will remain active for the full test. If the target website rejects temporary email addresses, stop and use a controlled long-term email address or the platform’s designated testing method.
Copy the full address and confirm the environment
Copy the address from your temporary inbox and check that there are no spaces around the prefix, @ sign, or domain. Enter it on the registration page, and confirm you’re using the intended test or staging environment.
Record the recipient address and the time the test begins. Don’t switch addresses across multiple browser tabs at once, or you may send the code to an inbox you’re no longer checking.
Trigger once and check the sending system
After submitting the registration form or requesting a verification code, note the time and the page response. “Sent successfully” may only mean the task was queued—it doesn’t confirm the email has arrived.
If you have log access, check the recipient address, task status, message ID returned by the sending service, and SMTP result. If the request itself failed, fix the request or rate-limiting issue first; don’t immediately blame the inbox.
Confirm the same email in your inbox
The inbox updates automatically, or you can refresh it manually. Check the subject, sender, and received time to make sure it matches the request you just triggered—not an older code that arrived earlier.
If no email arrives, check that the app is still pointed to the email sandbox and whether delivery logs show a rejection, a queued message, or a bounce. Wait a reasonable amount of time, then follow the target system’s resend rules. Don’t resend repeatedly and risk mixing up multiple codes.
Submit the latest code and confirm the status change
Use the valid code for the latest request and confirm that the registration status changes from pending verification to verified. After the success message, check the session and user profile too; don’t assume it worked based only on a page redirect.
Within your authorized test scope, also check incorrect codes, expired codes, and repeated submissions. The expected behavior is a clear error, no excessive disclosure of account information, and no reuse of a one-time code.
Clean up test data and keep redacted evidence
Delete or deactivate test accounts, and clean up queues and test records as your team requires. If the account needs to remain active, switch it to an email address you control long-term before the temporary address expires, then verify the new address.
Keep only the necessary timestamps, error categories, and redacted identifiers in bug reports. Don’t include full sign-in links, valid verification codes, or email access credentials.
Make it easy for a teammate to reproduce
Use one record for each send request, and log sending, receipt, and verification separately. The table below shows a sample format—not actual system test data or a guaranteed email delivery time.
| Record | Details | Why it helps |
|---|---|---|
| Environment and version | Staging / build number / page path | Avoids mixing results from different environments |
| Send request | Trigger time, redacted recipient address, request ID | Shows whether the app actually initiated sending |
| Delivery result | Queued / accepted by service / rejected / bounced | Distinguishes sending failures from delays |
| Receipt result | Received time, subject, sender domain | Matches the email to a specific request |
| Verification result | Success / expired / mismatch; don’t record the code | Checks whether the verification and email statuses match |
Not receiving test emails? Check these three stages
The request wasn’t sent
Check form validation, API errors, and sending rate limits. If the app didn’t create a send task, changing the recipient address usually won’t help.
The service hasn’t delivered it yet
Check the queue and SMTP response. A bounce and a temporary rejection aren’t the same thing; check the error category before deciding whether to retry.
The email arrived, but verification failed
Check which account, request, and expiry time the code applies to. Resending may invalidate the old code; don’t mistake a business-logic validation issue for a missing email.