Email Verification Testing Checklist for Developers and QA Teams
By OTPINB Team · Published 2026-11-03 · Reviewed 2026-11-03
An email-verification test should check the complete path: your application accepts the address, submits a message, the mailbox receives it, and the correct request can be verified. Seeing a code in an inbox covers only part of that path.
Use this checklist for an application you own or are authorized to test. Public temporary mailboxes can make test recipients easier to separate, but their messages must contain fictional, non-sensitive data.
Define the expected result before sending
Write down the action, the expected recipient, the expected message and the application's expected verification response. For example, a resend test should say whether your application keeps or invalidates an earlier code.
Do not make the receiving inbox responsible for a rule that belongs to your application. OTP Inbox can show a delivered message and recognize supported codes; your application decides expiry, reuse, session binding and verification success.
Prepare a small set of test recipients
Create separate mailboxes for a first request, a resend scenario and an expired-code scenario. Record their purpose in your private test notes. Copy addresses from successful creation results rather than inventing addresses and assuming a mailbox exists.
Use fictional accounts with no customer records, real passwords, payment information or recovery credentials. Keep test messages simple enough that another reader seeing them would not gain access to anything valuable.
Current Free account limits are 5 held mailboxes and 10 new creations in a rolling 24 hours. Premium allows 100 held and 100 new. Plan the test batch around both limits; deleting old addresses does not immediately reset creation history.
Check the first verification request
- Confirm the form accepts the intended address and shows the expected next step.
- Check your application's provider response or delivery status, where you have authorized access.
- Confirm the message arrives at the exact recipient rather than another test address.
- Review subject, sender identity, text, links and the action described in the message.
- Complete the request using the corresponding code or link and check the application's response.
Treat provider submission, mailbox arrival and successful verification as separate observations. If delivery fails, the troubleshooting guide can help identify which observation is missing.
Test resend and arrival order
Request an initial message, then perform the resend action under your test plan. Record the order of the requests without putting live codes in the report.
Check which request each message belongs to and whether your application accepts the old code according to its documented behavior. If you control the test environment, exercise delayed delivery so that an older request's message can arrive after a newer one.
The most recently displayed message is not always the most recent request. A harmless test-case label can help distinguish them. Avoid labels containing real account identifiers.
Test expiry and reuse in your own application
Use your application's test clock or configured test environment to reach its expiry boundary. Verify the expected response before and after expiry, and test reuse only as permitted by your test plan.
Keeping the email in a mailbox longer does not keep its code valid. A displayed code can be copied correctly and still be rejected by your application because the request has expired.
Include an alternate request or session only when your authorization covers it. Confirm that a code for one test account cannot complete another account's action according to your application's intended security design.
Check extraction and reading separately
| Test condition | Mailbox observation | Application observation |
|---|---|---|
| Supported numeric code | Message arrives; code display identifies a candidate | Corresponding request accepts or rejects it as specified |
| More than one number | Reader can inspect the message context | Only the intended verification value is accepted |
| Confirmation link | Message remains readable without a numeric extraction result | Correct action and destination are used |
| Older message after a resend | Arrival order can differ from request order | Resend policy still holds |
| Expired request | Message may still be visible | Expired verification is rejected as specified |
Do not mark the whole verification flow as failed merely because automatic extraction found no code. A readable link-based email can be the correct output for that test.
Keep evidence useful and non-sensitive
Record the case name, environment, request order, whether mail arrived and the resulting application state. Redact recipient identifiers where needed, and use synthetic screenshots for public reports.
Do not paste OTPs, signed links, access tokens or customer email bodies into issue trackers. Inspect a screenshot's previews and browser URL as well as the main message; access information can appear outside the visible code field.
When a request outcome is uncertain, investigate before submitting it again. Repeated resends can make the evidence harder to interpret and can trigger the sending application's limits.
Close the test batch deliberately
Review failures by layer: address creation, submission, delivery, reading, extraction or application verification. Keep conclusions tied to the environment you actually tested; a synthetic workflow is not a production delivery-rate measurement.
Turn off test notifications you no longer need and remove test data using the controls your plan permits. Do not use mailbox deletion as a shortcut for resetting quotas or as proof that another reader never saw a message.
For larger batches, use the multiple-inbox workflow. To begin, open OTP Inbox and run one synthetic case end to end before expanding the batch.