Password reset emails are one of the most common kinds of email. It’s almost impossible to build a software application without an email notification for a forgotten password.
In a way, this is exactly what makes the design and content of a reset password email tricky. They’re so common that they’re easy to take for granted, but there are subtle details that affect whether your password reset emails are convenient and useful or whether they cause confusion.
Editor’s note: This guide builds on the tips from our transactional email guide that covers both content and technical best practices that apply to all of your transactional emails. That guide is a great primer for transactional email in general, and will help make sure you get the most value from this guide too.
The goals of password reset emails #
Password reset emails are some of the most succinct emails you can send. Generally speaking, they have one goal: to help users securely re-establish access to their accounts.
In most cases, that will be through sending a password reset link.
There are a few scenarios that could complicate things, though:
- What if the link expired?
- What if they’re having problems entering a new password?
- What if they’re on a mobile device?
- And what if they didn’t request to reset the password?
So, while the primary goal is simple, the edge cases around helping people aren’t quite as much. Since many of the edge cases are loosely related, we’ll group the purpose of the email into two primary goals based on the context of the request.
1. If a customer initiated the request, help them re-establish access to their account #
In this context, the only goal that matters is getting people to a page to reset their password.
It’s also handy to provide easy-to-access options for getting support. The easier it is to resolve problems resetting their password, the happier they’ll be. This can be as simple as including your support phone number or email, like in the example below.
It’s worth noting that if users can reply directly to the email, the customer support agent would have access to the original password reset URL. Hopefully, your support team is trustworthy enough not to abuse that, but it’s worth keeping in mind. If security is crucial for your application, a no-reply address may be a better option.
2. If a customer didn’t initiate the request (or aren’t sure they did), help them understand what that means and whether they should be concerned #
With software being used in so many areas of life, it's more common now to receive a password reset notification without requesting it. That can be due to a simple typo or someone genuinely trying to gain access to someone else's account.
It can be confusing—even alarming—to receive these emails. A good password reset process (and the resulting email message) should reassure the user that they can take action to resolve the problem.
In high-security systems, you may even want to provide a way for the recipient to automatically invalidate or immediately expire the password reset URL with a single click in the event they didn’t initiate the request. A secondary action for “I didn’t make this request,” like the one from Airbnb below, can also help.
Finally, make sure there’s an easy way for users to contact support or get help if they’re concerned about their account's security.
Now that we've covered the two primary goals of these kinds of emails, let's talk about the most important aspect of this guide.
Password reset email best practices: 6 must-have design elements #
In theory, password reset emails are simple. In reality, there are quite a few details to get right. Your exact implementation may vary depending on your audience and product, but these are the 6 key details you need:
1. Relevant and readable subject and “From” name
2. The link to reset the password
3. Expiration information
4. How to contact support
5. Who requested the reset (IP Address? User Agent?)
6. The “Address not found” email
1. Relevant and readable subject and “From” name #
When someone needs to reset their password, chances are pretty good they’re heading straight to their inbox as soon as they submit the request. While the subject and sender aren’t the most critical pieces of information, they are the first things a recipient will see. A clear “From” name and subject can help them quickly identify the correct email and take action.
2. The link to reset the password #
In most cases, the link to perform the password reset is the most crucial piece of the email. It should be obvious and easy to click. Since the URL will inevitably be clunky with the expiring token, it’s best if the link is the HREF attribute of a link rather than embedded directly in the email.
3. Expiration information #
If the link expires—and it should—let the recipient know how long until the link no longer works. For convenience, include a direct link to where they can initiate another password reset request if the link has expired.
Well-engineered password reset processes will automatically expire or invalidate the password reset URL after a period of time. In some cases, the expiration window may be aggressive, and the link may expire before the recipient has an opportunity to check their email and reset their password. So it’s essential to communicate both the fact that the link expires and when the link will expire.
4. How to contact support #
When people request a password reset, they need access to something. In some cases, they may have forgotten their password. In others, they may have forgotten their username.
Regardless of the context, they need help, and password resets don’t always go smoothly. At a minimum, users need direct access to a support channel for getting help. Ideally, they’d have access to several options for support to use the one that works best for them.
5. Who requested the reset? (IP Address? User Agent?) #
Another security feature is to provide the recipient context around who (or what) initiated the request. Depending on how tech-savvy your audience is, this could be as simple as information about the operating system or browser used to make the request or as advanced as the IP address.
Alternatively, you could use an IP address lookup service to approximate the location of the request. While this wouldn’t be universally helpful, it can be a great tool to help build trust for the right products and audiences.
6. The “Address not found” email #
Some teams will want to send an email stating you didn't find a user account under that address. In this context, the attempt may or may not have been malicious. Let the recipient know about the request and whether they should be concerned. If they did make the request, they’d need the recommendation to try a different email address.
A checklist to make password reset email design easier
#
And here’s a quick summary checklist to help remind you of the individual points once you start designing and building your template (or, if you'd like to use ours, jump to the relevant section).
- A clear subject line and “From” name
- Identify who the password reset is for
- A clear call to action to resolve the problem
- Reassuring statement if the user did not initiate the password reset
- Support contact information
- Expiration information for the password reset URL (5 minutes? 24 hours?)
Best password reset email examples #
We could talk about email best practices all day, but sometimes it's better to "show" than "tell." Below are some of our favorite password reset email examples, plus what we liked and would improve about each one.
Stripe #
Subject line: Reset your Stripe password
Image via Really Good Emails.
- Yes: Clear subject line
- Yes: Identify who the password reset is for
- Yes: Clear call to action
- Yes: Reassuring statement if password reset wasn’t intended
- Yes: Reply-to goes to a real person or support address
- No: For security, the password reset link expires after a period of time
Wistia #
Subject line: Out with the old (Wistia password), in with the new!
From: Wistia
- Yes: Clear subject line
- No: Identify who the password reset is for
- Yes: Clear call to action
- Yes: Reassuring statement if password reset wasn’t intended
- Yes: Reply-to goes to a real person or support address
- No: For security, the password reset link expires after a period of time
Gusto #
Subject line: Reset password instructions
From: Gusto
- Yes: Clear subject line
- No: Identify who the password reset is for
- Yes: Clear call to action
- Yes: Reassuring statement if password reset wasn’t intended
- No: Reply-to goes to a real person or support address
- Yes: For security, the password reset link expires after a period of time
Ulta #
Subject line: Your Ulta Beauty password reset request
From: Ulta Beauty Notification
- Yes: Clear subject line
- Yes: Identify who the password reset is for
- Yes: Clear call to action
- No: Reassuring statement if password reset wasn’t intended
- Yes: Reply-to goes to a real person or support address
- Yes: For security, the password reset link expires after a period of time
Patreon #
Subject line: Patreon Password Reset
Image via Really Good Emails.
- Yes: Clear subject line
- Yes: Identify who the password reset is for
- Yes: Clear call to action
- Yes: Reassuring statement if password reset wasn’t intended
- No: Reply-to goes to a real person or support address
- Yes: For security, the password reset link expires after a period of time
Society 6 #
Subject line: Reset Your Society6 Password
From: Society6
- Yes: Clear subject line
- Yes: Identify who the password reset is for
- Yes: Clear call to action
- Yes: Reassuring statement if password reset wasn’t intended
- No: Reply-to goes to a real person or support address
- No: For security, the password reset link expires after a period of time
A disastrous password email #
This example shows a welcome email for a new account. Despite that fact, it’s still a fine example of what not to do in password reset emails. The email’s subject and greeting are good, yet it sends my account’s password in plain text. When we first saw this email, we were surprised to see security handled so poorly. Businesses should know better. Never send users a password in plain text because it’s a huge security vulnerability. Speaking of which:
How to make sure your password reset emails are secure #
The challenge with password resets is finding the right balance between security and usability. You need to give users enough information to know what’s going on when they initiate a password reset, but you risk playing right into a hacker’s hands if you give up too much.
Ideally, you would never confirm or deny the existence of an account with a given email or username.
Sometimes, you’ll come across an error message that looks something like this: “We couldn’t find a user with that email address.” If you use this method, then the absence of this message implicitly confirms the user account's existence.
You can’t just leave a user hanging, though. What if they have an account but registered with a different address? If you don’t do something to let the user know whether you successfully found their address, it creates a usability problem. Fortunately, the solution is simple.
You always send an email to the email address provided.
Your confirmation message displayed on the web page would simply say, “An email has been sent to (provided email address) with further instructions.” However, the content of that email changes based on whether a user exists with that email address:
- If the user exists, you send your standard password reset email with a URL and instructions.
- If the user doesn’t exist, you send a different email explaining that the user account was not found and suggesting that they try a different email address.
The downside of this approach is that the feedback on the web page isn’t quite as immediate as displaying a “user not found” message. This is a sacrifice worth making, though, since no one other than the email address owner can identify a list of user accounts for a given service. Only the owner of the email address will receive any details about the password, and anybody who is looking to uncover existing users will always see the same message and never know whether the account exists or not.
3 common mistakes when designing a password reset email (and how to avoid them) #
1. Sending plain text passwords in emails #
Plain text emails deal with the underlying password management, but it’s common enough and significant enough that it warrants addressing here.
If a password email ever contains a password, something is implicitly wrong with the password management system. Period. Solving the problem will likely require engineering changes, but it should be a huge red flag if you ever see a password in an email.
In place of passwords, the emails should only send temporary and secure URLs.
2. Accidentally looking like phishing emails #
Password reset emails are the quintessential phishing emails. In some cases, phishing emails do a great job of imitating the sender’s brand. But other times, they’re poorly formatted and sloppy.
If you’re sending a password reset email that includes some sloppy text and an awkward URL with a randomly generated token, it’s easy for people to be hesitant about whether they can trust it.
Of course, if they just requested the email, they won’t worry, but that doesn’t always happen. Where possible, include relevant information to help your emails stand out from phishing attempts.
If you know that you have a widespread phishing problem in your industry, make sure you’ve implemented a DMARC policy. This will help you address the problem and give your customers reason to be more confident that emails from you are actually from you.
DMARC monitoring for humans
See who's sending email using your domains and protect your brand from phishing attacks with DMARC Digests.
3. Slow sending or poor deliverability #
One final culprit that can create problems with password reset emails is slow sending speeds. As a rule of thumb, if it takes an email more than 20 seconds to arrive in an inbox, it’s slow. If it takes more than a minute, your customers might move on (and maybe not come back), or they’ll email support. Both outcomes hurt your business.
Because slow sending can impact your reputation and create extra work for your team, it’s important to find an email provider that can deliver your password emails fast and reliably. On the surface, email service providers may seem like they’re providing a commodity service, but once you dig into performance, reliability, and deliverability, you’ll discover that’s rarely the case.
Here at Postmark, we publish our delivery speeds for transactional email to the major email providers right on our status page. Fast delivery times to the inbox are a core piece of great deliverability.
You may be able to get away with slow sending in some cases, but when people request a password reset, they expect it to arrive almost instantaneously. So keep a close eye on your delivery times and support requests around password resets because they are one of the first signs you have problems—and your provider may not be living up to their end of the bargain.
Postmark’s password reset email template #
The tips we covered in this guide give you great guidelines for building an amazing password reset email, but we wanted to do more than give you guidelines. So we created an open-source password reset template you can use for any project. It gives you the HTML and CSS you need to jump-start your app’s password reset process.
There are two password reset templates in our collection: one for a straightforward password reset template for users who forgot their password, and one for a password reset help template for users who are using the wrong email to reset their password. Both build on all the best practices you’ve just learned and include an email for the smart password reset workflow we covered earlier. These can all be used with any email service provider, not just Postmark. You’ll get the HTML template you see here and a nicely formatted plain text equivalent.
You can grab the password reset templates and learn more about the rest of our template collection on our Transactional Email Templates website.
If you like Postmark’s templates, you should check out MailMason. It’s a tool we’ve built to streamline every aspect of creating and maintaining your transactional email messages. Every Postmark template is included out of the box with MailMason. On top of those templates, MailMason gives you the power of a Grunt-based email design workflow and makes it simple to maintain all of your transactional emails. You can use Mustachio to tightly integrate with Postmark’s template engine or adapt MailMason to your workflow for another email service provider.
We want to help you send incredible transactional email messages, even if you choose to use a different email service provider. If you have any thoughts on improving MailMason, we’d love for you to share them in the MailMason repository on Github.
Read all of our transactional email best practice guides #
We’ve assembled a series of guides on best practices for multiple types of transactional emails.
- Transactional email best practices
- Welcome email best practices
- Receipt and invoice best practices
- User invitation best practices
- Trial expiration email best practices
- Comment notification email best practices
Send lightning-fast transactional emails
Forgetting your password is frustrating for users, which is why delivering a password reset quickly and reliably is vital. Postmark helps thousands of teams do just that.