How to Test OTP Emails: Codes, Expiry and Resend Flows
Test OTP emails by sending codes to a throwaway inbox, then check delivery time, readability, expiry, resend and wrong-guess limits. Step-by-step QA checklist.
To test OTP email codes, send each one to a throwaway inbox you control, then check four things: how fast it arrives, whether the code is easy to read, whether it stops working after it expires, and what happens when someone asks for a new one. A fresh temp address per test keeps each run clean.
The longer answer
An OTP email test isn't only "did the code arrive". The bugs that reach real users tend to sit in the edges: an old code that still works after a resend, a code that never expires, or a lockout that never kicks in after ten wrong guesses.
Manual testing with a temporary inbox covers the full path, from your app to your email provider to a real mail server on the internet. A local mail catcher on your laptop skips that path, so it usually won't show you delivery delays or authentication problems.
Each test case gets its own address. You never reuse one, so leftover codes from an earlier run can't confuse the result, and your staging database doesn't fill up with the same three team inboxes.
What to test, and what should happen
| Test | What you do | What you want to see |
|---|---|---|
| Delivery | Request a code and note the time | The email lands in a reasonable time for your users |
| Readability | Open the message | The code appears in the body as plain text a user can read or copy |
| Correct code | Enter it once | You're verified and the flow moves on |
| Reuse | Enter the same code again later | Rejected. The code should work only once |
| Expiry | Wait past your code's lifetime, then enter it | Rejected with a clear message and a way to get a new code |
| Resend | Request a second code, then try the first one | Whatever your design says. Many apps make the old code invalid |
| Wrong guesses | Enter a wrong code several times | A limit or delay kicks in at the number you configured |
| Resend spam | Press resend many times fast | Your rate limit stops it, and the screen says when to try again |
| Pasting | Paste the code with a space before or after it | Accepted. Your form should trim spaces before checking the code |
Write the expected result down before you test. "Both codes work after a resend" might be fine for your app. Decide which behavior you want and put it in the test case.
Step by step
- Open TempMailFast. An address is created as soon as the page loads.
- Copy the address with the copy icon next to it, and paste it into your sign-up or login form in staging.
- Trigger the OTP and write down the time.
- Watch the inbox. The inbox refreshes by itself every 30 seconds, so press Refresh if you're timing delivery. Otherwise your number can be up to 30 seconds late.
- Open the message and check the subject and the code. Look at the message the way a tired user on a phone would: is the code obvious in a second?
- Run your edge cases from the table, one per address where you can.
- Click New address before the next test case. You get a brand-new address with its own 20 minutes.
Keep a short note per case (address, time sent, time received and result) so a developer can reproduce a failure.
What can go wrong (and how to fix it)
No email shows up. Check your app's logs and your email provider's dashboard first, because the problem is usually on the sending side. If the message was sent, look at your domain's authentication setup (SPF, DKIM and DMARC are the usual suspects). The verification email troubleshooting checklist covers the rest.
Your own app rejects the address. If you block disposable domains at sign-up, that's a test result too: check the error message is clear. To test the OTP itself, allowlist the domain of the address you're using for that run. Domains rotate over time, so expect to update the list.
Time runs out mid-test. A TempMailFast address on the website lasts 20 minutes from creation. Plan each case to fit. If your code lives longer than 20 minutes, note the code and the send time while the inbox is still open, then test it later.
A teammate can't open your inbox. Only the browser that created the address can read it. Share a screenshot or your screen instead of the address.
You want to automate it. TempMailFast has no public API, so the guide to testing email flows in staging is the better place to plan automated runs.
How TempMailFast fits OTP testing
The website is free and needs no account, which suits quick QA passes. Each address lasts 20 minutes, the inbox refreshes every 30 seconds (or on Refresh), and New address gives you a fresh one whenever you start a new case. Only your browser can open the inbox, so it's not a public inbox like Mailinator-style services.
Know the website's limits before you plan. TempMailFast only receives mail, so you can't test reply flows. You'll see the subject and body, and attachments aren't supported. Website addresses can't be extended, and an expired inbox can't be recovered. A new address may be on a different domain, which helps if you're checking how your app treats several domains, but there's no way to pick one on the website.
The mobile apps help when you want named test addresses. In both free and premium mode, you can pick a domain (premium adds extra domains) and set a custom username, such as qaresend01. Usernames are letters and numbers only. A username can't be reused on a domain where that address existed before, even after it expires, so add a run number. The custom username guide has the full rules.
Premium addresses in the apps last longer than 20 minutes, which helps when your code's lifetime is longer than the free inbox.
Frequently Asked Questions
Can I use temp mail to test OTP emails in production?
Yes, for manual checks, as long as your production sign-up accepts disposable domains. You see the same delivery path your users get, but each test creates a real account, so plan to clean those up.
How long should an email OTP stay valid?
That's your call, and it depends on how sensitive the account is. Pick a lifetime, put it in the email text, and test that the code is rejected once it's over.
Should a resend invalidate the old code?
Many teams do that, because it means only the newest code works and users don't get confused. Whatever you choose, test it on every release.
Can I read OTP emails from TempMailFast in an automated test?
No. TempMailFast has no public API. Use a mail catcher in your test environment for automated runs and keep temp mail for manual testing.
