如何在不使用真實用戶資料的情況下測試電郵驗證流程

Every signup flow you ship depends on emails your team rarely tests properly: the verification message, the password reset, the magic link. And the way most teams test them is broken by design — they use their own inboxes.

Your own inbox can only sign up once. The second run needs a +alias, the third needs a colleague, and by the fourth everyone quietly stops testing the flow end to end. Meanwhile the flow keeps changing: a template edit here, a new sending provider there, a redirect that now lands on a staging URL. Nobody notices, because nobody is standing at the receiving end.

Here is the testing setup that fixed this for me, and the checklist I now run before any release that touches auth or onboarding.

The setup: a fresh inbox for every run

The rule is simple: every test run gets an address that has never been used before.

That is what a real first-time user looks like to your system. No previous account, no warmed-up spam filter, no "we have seen this address before" shortcuts in your code. If your verification email is going to land in spam, arrive late, or carry a broken link, a fresh address is how you find out before your users do.

I use TempFreeMail for this — full disclosure, it is the service I built, precisely because I kept hitting this problem. It gives you a working temporary inbox instantly, with no signup, and the inbox stays alive as long as you need it, so a slow verification email or a reset link that takes ten minutes still has somewhere to land. Any disposable-inbox tool with those two properties (instant, persistent) works for this workflow; the tool matters less than the habit.

The checklist

Run these three journeys, in order, on every release that touches email:

1. Signup and verification

• Register with the fresh address. Start a timer.
• How long until the verification email arrives? Under a minute is the bar; users start abandoning after that.
• Open it on a phone, not just your desktop browser. Click the link there.
• Does the link land on production — not staging, not localhost, not a 404?

2. Password reset

• Request a reset from the same address.
• Time the arrival again. Reset emails are the most time-sensitive mail you send; a user staring at a locked account will not wait.
• Check the expiry: open the link after 30 minutes. Does it fail gracefully, with a clear way to request a new one?

3. The quiet failures

• Trigger the flow twice in a row. Do you get two emails, one, or a rate-limit with no message at all?
• Check the sender name and subject in a crowded inbox list. Would a stranger recognise it as yours?
• Try an address from a different provider than your company mail. Your own domain's delivery is artificially perfect; your users' providers are not.

What this catches

In my own testing this routine has surfaced: verification links pointing at a staging domain after a deploy, reset tokens expiring in five minutes because of a config default nobody chose, and a welcome email whose main button was an image with no fallback text — invisible to anyone with images off. None of these showed up in dashboards. All of them showed up in a fresh inbox within one run.

The habit

Automate what you can, but keep one manual run with a fresh address in your release process. It takes fifteen minutes, and it tests the exact experience your next user is about to have — which is the one test that actually matters.

Written by Temp FreeMail, founder of TempFreeMail. Drafted with AI assistance and edited by the author.