Test signup verification codes without real inboxes
Give every environment a private test inbox, run signup as many times as you need, and check every code, link, and expiry before a real user hits the flow.
Free plan includes 500 emails a month. No credit card.
- 1SenderMatches your brand and a monitored address
- 2SubjectClear, no spam-trigger wording
- 3CodeFresh on every resend, correct length
- 4ExpiryStated, short, and enforced
Why signup verification emails are hard to test
A verification code is single-use and short-lived, so the usual workarounds for a test address get in the way.
A personal inbox
Every test signup adds another account tied to your own address, and a real mail provider will eventually flag the volume as suspicious.
Plus addresses
[email protected] and [email protected] still land in one inbox, so two people testing signup at once step on each other's codes.
Temp-mail sites
A public inbox can be read by anyone who guesses the address, and it can expire mid-test, so a slow CI run never sees its code arrive.
How to test signup verification in four steps
The same flow works for a single manual test or a CI job running dozens of signups a day.
- 01
Create one inbox per environment
Add an inbox such as [email protected] for each project or environment you test signup in.
- 02
Sign up with that address
Run your signup flow in local development, staging, or a CI job using the test inbox as the account email.
- 03
Watch the code or link arrive live
The verification email appears the moment it is sent, so a scripted or manual test does not need to poll or refresh.
- 04
Confirm the flow completes
Enter the code or follow the link, confirm the account activates, and check that resending issues a fresh one.
What to check in every verification email
Getting a code delivered is the easy part, these are the details that break under real use.
Code length and format
Commonly 4 to 8 digits, or a single-use link. Confirm it matches your spec and is not truncated in the email client.
Expiry window
Most codes expire in 5 to 15 minutes. Test that an expired code fails with a clear message, not a silent hang.
Resend behaviour
Requesting a new code should either invalidate the old one or clearly state both remain valid, and be rate limited.
Link destination
A confirmation link must open the environment it was sent from. A staging email linking to production is a common slip.
Mobile rendering
Open the Preview tab and check the layout does not collapse, and that the code or button is easy to tap.
No collisions under load
Run two or three signups back to back with different inboxes and confirm each one gets only its own code.
Common signup verification bugs
If you see one of these, the flow is not ready to ship.
| Bug | What you will notice |
|---|---|
| Same code on resend | Requesting a new code returns the exact same digits. |
| Link opens production | A staging confirmation link lands on the live site. |
| Duplicate emails | Two identical verification emails arrive for one signup. |
| Race with account state | The email arrives after the account is already marked verified. |
| No plain-text fallback | Clients that block HTML show a blank message. |
| Broken mobile layout | The code or button is cut off or not tappable on a phone. |
Test signup verification with Inceptmail
A private test inbox for every project, built for checking exactly what your app sent, even under parallel test runs.
One address per project
Private, permanent inboxes mean parallel test runs never collide over a shared address.
Live delivery
Codes and links show up the instant they are sent, no polling and no refreshing.
Preview and raw HTML
Check the rendered email and the underlying markup, side by side.
Shared with QA
Give teammates access to just the inbox they need, without a shared mailbox.
Also testing password resets? See password reset email testing, or read how it works with staging environment email testing.
Signup verification email testing FAQ
How do I test the signup verification email flow?
Create a private test inbox, sign up using that address, and inspect the verification email as it arrives. Check the code or link, confirm it activates the account, and test that an expired or reused code fails safely.
How do I test verification codes in Playwright or Cypress?
Put a stable Inceptmail address in your test fixtures, run the signup flow, then check the inbox for the message and extract the code from its content to continue the test. There is no public API yet, so this step is manual today.
Can multiple test signups run in parallel without codes colliding?
Yes, as long as each test run uses its own inbox address. A private address per project or per test worker means one signup's code never ends up in another test's way.
What is a reasonable expiry time for a verification code?
Most products use 5 to 15 minutes for a one-time code and up to an hour for a confirmation link. Whatever you choose, test that the expired case fails with a clear message instead of a generic error.
Does this work if I send verification emails through SendGrid, Postmark, or SES?
Yes. Inceptmail addresses receive mail from anywhere, so it does not matter which provider or service actually sends the email, only that it is addressed to your test inbox.
Is Inceptmail free for testing signup emails?
Yes. The Free plan includes 500 emails a month, 3 inboxes per project, and 7 days of message history, with no credit card needed.
Give your test email a proper home.
Create your first inbox in under a minute. The Free plan covers a whole project.
Get started free