Anatomy of a Reset Password Email

Or: More than you needed to know about account recovery


Posted 2.1.21

For a lot of applications, reset password functionality is an afterthought, slapped on shortly before launch and never revisited. "Oh yeah, we need a forgot password form! Let's toss that onto the scrum board." As a result, reset password flows are often clunky, unfriendly experiences.

At Mailclerk, we want to help companies implement a first-class user experience throughout all of their application email. This post provides some data-driven best practices by looking at examples of how different applications handle resetting passwords and account recovery.

Contentful reset password email

To collect data for this post, I attempted to reset my password on 105 different applications and websites. I don't claim these are perfectly representative of all websites out there; developer-focused SaaS companies (e.g. Contentful, NewRelic, npm) are overrepresented because I already had a lot of accounts with them. But I've also included retail websites (e.g. REI,, transportation applications (e.g. Uber, City Bike NYC), utility companies (e.g. Con Edison, T-Mobile) and other industries to widen my perspective. I've included some of the largest presences on the internet (Google, Wikipedia) as well as some much smaller ones (DSTLD, Lichess).

Throughout this post, I include some screenshots of things we at Mailclerk think are great examples of email UX, and some that aren't quite as good. If you're reading this from an organization we critique, please don't take it personally; this is all in pursuit of helping the world send beautiful and usable email! (We'd also love to help you out with your emails. Drop us a line at 😉).

You can jump to the end of this post to see our summary of best practices plus the raw data, or here if you just want to see some excellent examples.

Reset Method

The most common way to let someone into their account when they've forgotten their password is to send them a link with a unique token that allows them to set a new one. We call this the "reset link" method. This is the classic. Since it's so common, you can be fairly sure your users won't need much coaching for this to work. Of the 105 applications we looked at, 83 used this method. Eventbrite is a well-executed, simple example:

Eventbrite reset password email

But this isn't the only method! Increasingly common is the use of one-time passwords (or OTPs, different from the usage in fanfiction 💕), where people are sent a short code or PIN by email or SMS that they enter into the application. This serves the same basic purpose as reset links: it confirms you still control the email (or phone number) you signed up with.

17 applications sent OTPs by either email or SMS. Four of these (PayPal, Lyft, Uber, Lemonade) sent OTPs by text message only, taking them out of the scope of this (email-only) analysis.

It is notable that Google, Facebook, Twitter, and LinkedIn, some of the largest social networks and identify providers, all use the OTP method. Here is how Twitter does it:

Twitter reset password email

A handful of applications made their own path:

  • One application (CircleCI) only allows access via SSO, which means they can completely sidestep password management.
  • Another (Metabase) doesn't allow password resets at all; people are prompted to ask their admins to reset their passwords for them.
  • Apple/iCloud sends a push notification to one of your Apple devices. If you happen to make a device with the same reach as the iPhone, you should consider this method!

Finally, Wikipedia sends a new randomly generated password by email that Wikipedians can log in with:

Wikipedia reset password email

I'm not sure why Wikipedia is going their own way with the reset password methodology here; I suspect this has something to do with the fact that emails are not actually required to sign up.

Best Practice: Either a reset link or reset OTP will work. People may be less familiar with the use of OTPs, and so using reset links may generate less friction. However, OTPs may have some slight security benefits over password reset, as indicated by the major identity providers using it.

Subject line

So far in this post we've been referring to "resetting passwords." This phrase, or variants on it, is used in 89% of email subjects we looked at. Some common variations:

Subject Note
Reset your password 8 emails, all identical
{{APPLICATION NAME}} password reset 11 emails
Reset your {{APPLICATION NAME}} password 8 emails

The other common pattern is to call this process "account recovery" or variants on that.1 6% of subject lines do so. Examples:

Steam Account Recovery
Account Recovery - Stack Overflow
Mailgun account recovery instructions

For applications using OTPs, the email subject generally directly reference either the "code" or, less often, the "PIN". Examples:

Subject Note
Google Verification Code Code
{{NAME}}, here's your PIN LinkedIn
{{OTP CODE}} is your Facebook account recovery code Facebook (and Slack) includes the code in the subject

Finally, here are a few subject lines with a bit more personality:

Subject Note
🔑 Password Reset Duolingo, getting points for being the only email with an emjoi in the subject line
Your password reset instructions… DSTLD feels a little hesitant
Ask and you shall receive... a password reset Reddit has a better handle on the effective use of the ellipsis

Many emails included the application name in the subject. This is particularly important for applications that don't send with their organization's name tied to the FROM address. Points docked from Shutterfly, APA League, The Economist, Amtrak, and David's Tea for doing neither, making their emails very hard to identify in my inbox:

Five emails in an inbox

If you don't have easy control over the "from" names on your application emails, Mailclerk can help with that. 😉

Best Practice: Be very clear in the subject line what the email is for (resetting your password/recovering your account). If it fits your application's tone, consider a small splash of humor. Make sure to include the name of your application as either the sender name or in the subject line.

Reset Buttons vs. URLs

Modern, effective email design usually calls for a prominent call-to-action (CTA) button. This minimal reset email from is almost nothing but a CTA:

Freedom reset password email

For minimally-styled emails which emulate the style of email clients like Gmail, URLs written out in text of the email also look natural, like this one from Citi Bike:

City bike reset password email

However, a surprisingly large number of templated emails include URLs in plaintext, instead of or in addition to a button. Of the 66 templated emails in our dataset that use the reset password method, 10 have reset URLs in plaintext instead of a button. The result is often jarring, like this email from Twilio:

Twilio reset password email

15 include both buttons and hyperlinks. This can end up looking even stranger, as if someone decided at the last minute to add the URL. See Carta:

Carta reset password email

Why do so many emails have plaintext URLs? At the dawn of templated emails, this was a good practice because not all email clients were able parse HTML emails, and so buttons wouldn't have displayed or been clickable. These URLs (and the advice to copy and paste them into a browser) was for their benefit.

Here in 2021, very few (if any) of your customers will be using email clients that can't display HTML emails. For those that are, they're best served by your sending plaintext versions of your emails in addition to the styled HTML version, which you should definitely do anyway for deliverability reasons.2 The plaintext version should convert the button to a plaintext URL automatically. Here's what the plaintext version of that minimal email looks like:

Freedom reset password email

We think the main reason this practice persists is people blindly copying other’s email design. Application email rarely gets the attention it deserves. (We are trying to change this!) Pointless email patterns perpetuate via people mimicking existing emails without pausing to think.

If you feel like you must include a plaintext link but still want to use a heavily-styled email template, consider adding the link to the footer of the email. We like how the Washington Post handles this:

Washington Post reset password email

In general though, we don't think it's necessary to include links in plaintext or instructions to copy URLs into a web browser.

Best Practice: If you're sending email using a styled HTML template, use a button instead of a URL for password reset CTAs. Plaintext URLs are okay in minimally styled templates. Always make sure to provide a plaintext alternative to HTML.

Expiration Time

With both the reset password and OTP methods, it is imporant to make links and OTPs expire after a certain amount of time has elapsed. Otherwise, passwords could be changed long after they were sent, perhaps after the account in question was transferred to someone else (and the associated email changed) or perhaps if someone screenshot the emails in question and put them into a blog post.3

Just because you make your links expire doesn't mean you need to tell people they do in the email though. 62% of the applications we looked at don't specify an expiration date in reset password emails. We expect that the vast majority of these companies do in fact implement links and code expiration. They just think it is distracting or unnecessary to draw attention to the expiration.

Patreon splits the difference, coyly telling you the link will expire at some point but not telling you when:

Patreon reset password email

Enough applications DO specify an expiration time in their email that we can try to see if there is a consensus on how long to wait for expiration. Turns out there isn't one:

Graph of time till expiration for different applications

Times until expiration varies from 15 minutes (Blueshield of CA) up to 7 days (Wikipedia). Furthermore, there isn't a clear pattern based on the sensitivity of data or level of regulation. Blueshield of CA and CityMD accounts both contain sensitive health user data, but are on wildly different extremes for expiration time. MongoDB and Segment grant access to potentially sensitive application data, but links for MongoDB expire 12x faster than Segment's.

We don't like what Zapier does:

Zapier reset password email

Two big issues with this:

  • Midnight in what timezone? Pacific Time (where Zapier is based?). Eastern Time, where my account is set to? Central European Standard Time, where I'm on vacation?
  • What if I requested this link right at 11:57pm? Do I need to race the clock to reset my password?

Best Practice: It's very important to make both reset links and codes expire. There's no precise science to picking the specific time, but both 1-3 hours and 1-3 days seem like reasonable choices. If you go with a shorter expiration time, you should notify users about it in the email.

Did not request

If someone malicious types in random email addresses into a forgot password form, they can trigger emails to people who didn't request them. This may seem like pointless way for someone to spend their time, but it does happen; some companies put reset password forms behind CAPTCHAs for this reason. It was apparently common enough at Wikipedia that they actually include instructions on how to reduce the volume of unwanted reset password emails (see the image in the Reset Method section above).

Many reset password emails include instructions about what to do with reset password emails people didn't request. Of the emails we looked at, 61 (out of 98) include instructions like this. Most (44) just tell people to ignore the email, which we think is almost always the correct action to take. Our favorite treatment is Spotify's, which makes a small joke out it:

Spotify reset password email

15 emails instruct people who get unwanted reset password emails to contact the company's support team, usually be email. Three companies (Blueshield of CA, REI, and T-Mobile) go so far as ask people to call them! This seems like a big waste of both customer and call center time. (What do they do when you call about this?)

A few applications go even further. LinkedIn says "Didn't do this? Be sure to change your password right away." which feels like an overreaction. WPEngine says "If you did not make this request, please contact the owner of your WP Engine account immediately." which is both alarmist and, to the admin, a waste of their time 4.

I think this is another case of people blindly copying other applications without really considering if it makes sense for themselves. Originally, when people were unfamiliar with the reset password process, it might have been necessary. Like plaintext URLs (see above), these instructions are vestigial remnants that can safely be eliminated from your own emails.

Best practice: There is no need to reassure people about forgot password emails they didn't request. If you really want to say something, just tell them to ignore the email.

Could Use Improvement

To wrap this post up, I want to highlight some emails that do things particularly well or could use some improvement. First up, the emails that need some work:

CityMD reset password email

CityMD's reset password email suffers from clashing backgrounds and styles of text. With a very small link (relative to other elements) they've made it harder for anyone with visual impairments or other disabilites to find or click the reset link, especially on mobile. The "Recover your password" header also falsly appears clickable.

By having a less-than-professional appearance with their emails, CityMD may also make users wonder if emails genuinely originate from them. Good, consistent email design should be part of an organization's defense against phishing attacks.

Etsy reset password email

Etsy's email is filled with unnecessary text. On top of including both a button and link (see Reset Buttons vs. URLs above), almost half of this email is legal boilerplate. If all the qualifiers are absolutely necessary, the template should be reoriented to better separate the footer from the content of the email.

Namecheap reset password email

Namecheap appears to be taking the maximally lazy approach to application email design in their forgot password email. They show the user's IP address, which can be a good addition to forgot password emails for technical products, but didn't take the time to apply even minimal formatting to this email.

Purely plaintext emails do have a place, but basic efforts at formatting are still important. Fixing the spacing issues present in several places and removing the "----" header would help the email be more readable and avoid raising any doubts about the authenticity of the email.

Hall of Fame

Meanwhile, here are a few emails we really like (that haven't already been referenced above). They're not all perfect — nobody is — but they all do at least one thing really well.

Lob reset password email

Lob does a great job mixing humor and reassurance in their minimal password reset email. They avoid distracting people with any unnecessary information.

Slack reset password email

Slack's email is our favorite of the OTP examples. The code is clearly visible and copyable in the body of the email (and also the subject) and there's no other prominent links people could accidentally click on.

Uniqlo reset password email

Uniqlo's email is a bit chaotic, but it's a good example of why companies shouldn't overlook application emails as a potential revenue drivers. Including promotional information in this (and other) application emails may be a good idea. You can also include information about referral programs (as does) or anything else you think is valuable to get in front of your customers.

Adding these alternative CTAs to your emails are a tradeoff; some people may end up getting distracted from the purpose of the email. Since Uniqlo tags each of these links with UTM codes specific to the reset email, they can measure if the links drive meaningful engagment or revenue and determine if the tradeoff is worth it.

Notion reset password email

Notion's email is another minimally styled email we really like. It's a great fit for their overall simple, modern aesthetic.

Instacart reset password email

Instacart makes this list not because of the email content itself but because they proactively send it to people after a few incorrect password entries. Particularly on mobile, this has to potential to save people a lot of time.


I hope these examples and best practices have given you some ideas on how to implement or improve your own reset password emails. To summarize the advice above:

  1. Avoid including unnecessary information, like instructions on how to handle unwanted reset passwords.
  2. For reset links: Include a prominent CTA button if your email template is heavily styled. Only use URLs if the email is minimally styled or completely plaintext.
  3. For one time passwords: Make the code prominent and easy to copy.
  4. Make sure to keep links and tokens secure by expiring them after no more than three days
  5. Look for opportunities to reinforce your brand or drive valuable engagement.

If you are not satisfied with the reset password emails your application sends, consider sending your emails with Mailclerk! We'll make it easy to create a great reset password email without taking developer time.


  1. I would like to note here that "password recovery" (used by Sentry and Roll20) is not accurate, since the original password is never recovered. Or at least, it should not be – applications should never be able to retrieve plaintext copes of your password.

  2. It's important for both usability and deliverability reasons to send true plaintext version alongside HTML. If you send with Mailclerk, we'll automatically generate plaintext versions of any emails you send with us so you don't need to worry about this!

  3. Though I regret to inform you that you if you try that won't have much luck with links and codes from this blog post.

  4. Also, I AM the administrator of my WPEngine account. I need to inform myself?

Interested in early access?