New guide: how to warm up a dedicated IP without hurting your reputation. Read now →
Log in
MigoSMTP
SecurityUpdated 18 Oct 2026

Password Reset Email Best Practices: Template, Security and Magic Links

How to design a password reset email that arrives quickly and keeps accounts safe: a copyable template, the password changed confirmation, secure single-use token design, how magic link emails differ and how to deliver them reliably.

DW
Written by Daniel Whitfield
IP Reputation and Warm-up Lead
Reviewed by Tomasz Kowalski
  • Published15 Oct 2026
  • Read time7 min
  • Length1,367 words
Share this guide

The password reset email is one of the most important messages your application sends. It reaches people at a stressful moment, when they cannot get into their account, and it carries a secret that gives access to that account. If it arrives late, looks suspicious or is built insecurely, you lose users and you may lose control of accounts. This guide covers password reset email best practices, a template you can adapt, the "password changed" confirmation, and how magic link sign-in emails differ and why they need extra care.

Speedsend it at once, from a separate transactional stream
Safetysingle-use, short-lived tokens that you store hashed
Clarityone button, plain words, no surprises

What a password reset email must do

A reset email has three jobs. It must reach the inbox quickly. It must make it obvious what to do. And it must keep the account safe even if somebody tries to abuse the flow. Treat it as part of your security design, not as a marketing message, because it is a transactional message that people expect to receive within moments.

Best practices for the email itself

  • Use a clear subject line. "Reset your password" is better than a clever line. People search their inbox for it, and filters recognise it.
  • Name your product in the sender name and the body. A person who made a request twenty seconds ago should know at once who is writing.
  • Put one main button, labelled "Reset password", near the top. Add the plain link below it, for email apps that block buttons.
  • Say why they received it: "We received a request to reset the password for your account."
  • Say what to do if it was not them: "If you did not ask for this, you can ignore this email. Your password will not change."
  • State when the link expires, so that nobody is surprised by an error later.
  • Keep the design simple. A short message with little imagery loads fast in every email app and looks less like phishing.
  • Include a plain-text version alongside the HTML.
  • Do not put the password in the email, ever. Not a new one, and not the old one.

Password reset email template

Adapt this wording to your brand and keep it short.

Subject: Reset your [Product] password

Hello [first name],

We received a request to reset the password for your [Product] account. Use the button below to choose a new password. This link works once and expires in [time period].

[ Reset password ]

If the button does not work, copy this link into your browser: [link]

If you did not ask for this, you can ignore this email and your password will stay the same. If you are worried about your account, contact us at [support address].

The [Product] team

Password changed confirmation message

After a password changes, send a second email. It tells the real owner of the account when something has happened that they did not do. It also gives you a record that the change was delivered to the registered address.

Subject: Your [Product] password was changed

Hello [first name], the password for your [Product] account was changed on [date and time]. If you made this change, no further action is needed. If you did not, please reset your password at once and contact us at [support address].

The on-screen message after a successful change, such as "Your password has been changed successfully", should be short and should take the person to the sign-in page. Do not sign someone in automatically on a reset flow unless your security review allows it, and consider ending other active sessions after a reset.

Secure design of the reset token

The link in the email contains a token. Your protection depends on how it is made and handled. The OWASP cheat sheet on forgotten passwords is a good independent reference, and the points below follow its common advice.

  • Make it unpredictable. Generate it with a cryptographically secure random generator, with enough length that it cannot be guessed. Never build it from the user ID, the time or the email address.
  • Make it single-use. Invalidate it once it works, and invalidate older tokens when a new one is requested.
  • Give it a short life. Choose an expiry that suits your users, such as a few minutes to an hour, and show it in the email.
  • Store a hash, not the token itself, so a database leak does not expose live reset links.
  • Do not reveal whether an account exists. Show the same message, "If that address is registered, we have sent an email", whether or not the address is known. Otherwise your form lets people discover who has an account.
  • Rate-limit requests by address and by IP, so the form cannot be used to flood someone's inbox.
  • Keep tokens out of logs and analytics. Reset links in URLs can leak through referrer headers and third-party scripts, so send people to a page that does not load external resources.

For more on keeping credentials safe in your own systems, see API key security, permissions and rotation.

A magic link is a sign-in link sent by email. There is no password. The person clicks the link, and the site signs them in. It follows the same pattern as a reset email, except that the link is the whole login, so everything above applies with more force.

  • Expire quickly and allow one use. A magic link works as a password, so it should be valid for a short time and only once.
  • Bind it to the request. Where possible, require that the link is opened in the same browser or device that asked for it, or ask for a short code shown on the original screen.
  • Beware of link scanners. Some email security tools open every link in an incoming message to check it. A one-time link can then be used up before the person clicks it. A common fix is to make the link open a page with a confirm button, and to sign the person in only when they press it. A short code is another option.
  • Make it clear in the email. "Click to sign in to [Product]. This link works once and expires in [time period]." Add a line saying what to do if the request was not theirs.

Delivering reset emails reliably

An excellent reset flow still fails if the message lands in spam or arrives after the token has expired. A few steps help.

  1. Authenticate your domain with SPF, DKIM and DMARC. Our guide on authenticating your sending domain shows how.
  2. Send reset mail on a transactional stream, apart from campaigns, so that a marketing problem does not delay it. See separating transactional and marketing streams.
  3. Send immediately, and do not batch. Use a queue with fast workers, and retry on temporary failures.
  4. Watch the delivery log. When a user says "I never got the email", you need to see whether it was accepted, deferred or bounced. Read about message logs and the delivery lifecycle.
  5. Verify addresses at sign-up, so that reset mail goes to a real mailbox. Our email validation catches typos and invalid domains before they become a support ticket.
  6. Keep the message light: few links, no tracking pixels that could trigger filters on a security message, and a plain-text part.

If you are unsure why a reset email is slow, our guide to queued and deferred email lists the usual causes.

Testing the flow

Test the whole path before launch: the form, the email, the link, the expiry, reuse of an old link, a request for an unknown address and a request made many times in a row. Use a staging environment and a sandbox so that you do not send real mail while testing; see test email and staging environments.

Checklist

  • Clear subject, sender name and button
  • Single-use, short-lived, hashed token
  • Same response whether or not the account exists
  • Confirmation email after the change
  • Authenticated domain on a transactional stream
  • Delivery log and alerts for slow or failed sends

Send reset emails that arrive in seconds Use a dedicated transactional stream with logs for every message.

See the email API

References and further reading

Frequently asked questions

What should a password reset email contain?

A clear subject, your product name, one reset button with a plain link below, the reason for the email, an expiry time and a line saying what to do if the request was not theirs.

How long should a reset link be valid?

Keep it short and single-use. A few minutes to an hour suits most products. Show the expiry in the email, and invalidate older links when a new one is requested.

Should the email say whether an account exists?

No. Show the same message whether or not the address is registered, so the form cannot be used to discover who has an account.

What is a magic link email?

It is a sign-in link sent by email in place of a password. It needs a short life, single use and protection against link scanners that open links before the person does.

Why do users not get password reset emails?

Common causes are an unauthenticated sending domain, a mistyped address, a delayed queue or spam filtering. A delivery log and address validation at sign-up make these easy to find.

Topics#password reset#magic link#transactional email#account security#email template
Was this guide helpful?Your answer helps us improve our documentation.

Start sending in minutes.

Create an account, add your domain and send your first email.

Get started Talk to sales