Test password-reset email flows
A forgot-password flow has more moving parts than it looks: the mail has to arrive, the tokenized link has to work once, and it has to stop working after it expires or is used. Perenmail gives you a private inbox on a real domain — point your app's reset email at it, watch the message land live, open the reset link in one tap, and come back to the same inbox to retest the expired-token and re-request cases, because it doesn't disappear on you.
From reset request to a new password, in one place
- 01
Spin up a private inbox on a real domain
Create a registered-only address in one click. It lives on a real domain, so your app's mail server treats it like any other recipient — the reset mail routes exactly as it would to a real user.
- 02
Enter it as the account email
Register a test account with the address, or set it on an existing one. This is the mailbox your forgot-password flow will target when you ask for a reset.
- 03
Trigger the reset
Hit "Forgot password" in the flow you're testing. Your app sends the reset mail exactly as it would in production — no special routing or provider overrides to work around.
- 04
The mail lands live
A listening indicator and poll heartbeat surface the reset message at the top of the inbox the moment it arrives — no reload, and the unread state updates in place. You watch it land in real time.
- 05
One-tap the reset link
Every link in the message is extracted for you, including the tokenized reset URL. Open it in a single click to walk the set-a-new-password screen — no copy-pasting a long token out of the body.
- 06
The inbox persists, so you retest
Inboxes are persistent by default: they never expire on their own. The reset mail you triggered ten minutes ago is still there, so you can come back and confirm what happens when its token has expired or been used.
Reset flows are mostly the unhappy paths
The happy path — request a reset, click the link, set a new password — is the easy five percent. The behavior worth testing is what happens the second and third time: an expired token, a link that has already been used, a resend that must invalidate the previous one. All of that depends on messages that stick around and delivery that behaves like production.
Expired-link retests
To confirm a token really expires, you have to keep the original mail and re-open its link after the window closes. On an inbox that self-destructs the message is gone before you can test it; here it stays put, so an expired-token check is a link you can click again on demand.
Rate-limited resends
Testing resend logic means firing several reset mails in a row and confirming only the newest link works. With every message kept, you can line the reset URLs up side by side and verify the earlier ones are correctly invalidated.
Delayed delivery
A queued job or a slow upstream provider can push the reset mail out minutes after you asked for it. A persistent inbox on a real domain is still there when it finally lands — a late reset is a message you read, not a test run you start over.
The real token, every time
Because the address is on a real domain, your app builds the link the same way it does in production. One-tap link capture pulls the tokenized URL straight out of the body, so you exercise the genuine reset path rather than a stubbed one.
Because inboxes persist by default and mail streams in live, you can request a reset, step away to check your app's logs, and come back to find it waiting at the top of the inbox. If a reset mail never shows up, open the raw source and check the synthesized SPF, DKIM and DMARC results on your own outbound mail to tell a delivery problem from an authentication one. (Raw source and headers are a Personal+ feature.)
The parts that make reset testing quick
Live delivery
The reset mail appears at the top the instant it lands, with the unread count updating in place. You never refresh to check whether the link arrived.
One-tap link capture
Every link in a message is extracted automatically, including the tokenized reset URL. Open it in a single click and step through the set-new-password screen.
Private, registered-only
Addresses are private and not publicly browsable. Only your account can read the inbox, so the reset links your app sends stay yours during testing.
Testing the neighboring flows too? The same private inbox works for OTP & 2FA codes and email-verification links. See how the free and Personal+ plans differ on pricing, or read the FAQ for the details.
Click through your next reset link, live.
Create a private inbox on a real domain, point your app's forgot-password flow at it, and open the reset link in one tap. Free forever, no credit card.