Password reset best practices: check the link

You test resets from your own inbox, on the device where you already typed the request, and you know the domain you are on. A visitor who forgot their password is often on a phone, with the request made on a laptop hours earlier, or with a mail app that opens links in its own browser. Their link may point at a staging address you set up months ago, or at a page that expects a cookie the laptop set and the phone does not have. They see an invalid link message, and the first thing they do is ask for another email, which arrives with the same problem.

• The link in the email starts with the live domain, and with nothing from a test address.
• The link opens in a fresh browser on another device, not only the one that asked.
• The request page gives the same message for a known address and an unknown one.
• An expired link shows a short reason and a button to request a new one.
• After the new password is saved, the visitor can sign in with it straight away.

A reset link is a web address the server assembles, and the server takes the domain from a setting. If that setting still holds a staging or preview address, every link in every email points there, whatever domain the visitor used on the form. The fault is easy to miss, because your own tests may run on the same staging site. Open a reset email and read the link before you click it. The domain should be the one on your sign in page. A staging name, a localhost address or a preview name means the setting is wrong, not the visitor. Fix the setting, then send one reset from the live site to see the new link.

Some reset flows store a small piece of state in a cookie on the request device, then check it again on the reset page. A visitor who asks on a laptop and opens the mail on a phone has no such cookie, so the page treats the link as stale. A common design puts the reset token in the link itself, which lets any browser complete the reset. Test it as a visitor would: request on the laptop, open the mail on the phone, and tap the link. If the page asks for a new link, the reset depends on the first device, and that is a fault to fix.

A request page that says no account exists for that address tells a stranger whether the address is one of your customers. A common alternative says that, if an account exists, a reset link is on its way. The message should match for both cases, and the wait before it appears should not reveal which case it was either. Test it with an address you know is in the system and one that is not, then compare the words and the wait. The report shows the request page and the screen after it for each address, so you can compare them.

Once the link works, the new password screen has its own rules, and a common fault is a rule that refuses a password the visitor just used, with an error that does not say why. Check that the screen names its rules before submit, as the visitor types. After the password is saved, the visitor should either land signed in or see one clear line that says to sign in with the new password. A screen that returns to the old sign in form with no message looks like the reset failed. Test that path after the link, with a password that differs from the old one.

A reset flow depends on the domain setting, the mail sender and the redirect after the new password. Moving domains, changing the sender or adding a preview can change one of them without touching the form. After each of those changes, request a reset from a new visitor's inbox, open the link on a phone, and read its domain first. With paid credits, visitors can open a preview address behind a site password.