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. It’s a great primer for transactional email in general and will help make sure you get the most value from this guide too.
Password reset emails are probably the most ubiquitous kind of emails in the world. It’s virtually impossible to build a software application without an email notification for resetting a password. In a way, this fact is exactly what makes the design and content of a password reset email tricky. They’re so common that they’re easy to take for granted, but there are quite a few subtle details that can influence whether your password reset emails are great or not so great.
A note on technical considerations #
This guide focuses exclusively on the design and content of your password reset emails. There are dozens of important technical decisions about how you handle passwords as well as the process and interface for enabling people to change their password. Those tactics are of the utmost importance, but they’re outside the scope of this guide. If you’re looking for a detailed guide for your technical implementation of your password reset functionality, you should start with Troy Hunt’s article, “Everything you ever wanted to know about building a secure password reset feature.”
“Smart” password reset emails #
One technical consideration about the process of resetting passwords is how to avoid leaking usernames. This topic is addressed in Troy's article we mentioned above, but since it relates to email, it’s very relevant to what we’re discussing here.
Ideally, you would never want to confirm or deny the existence of an account with a given email or username. This happens most frequently when a site displays a confirmation on whether a username or email address exists when a person tries to login or reset their password. You may have seen an error message somewhere that looks something like: “We couldn’t find a user with that email address.” The corollary to this is that if an email address does exist, the absence of this message implicitly confirms the existence of the user account.
The problem is that if you don’t do something to let the user know whether you successfully found their address, it creates a usability problem. What if they have an account but registered with a different address? You wouldn’t want to just always say that an email is on its way. So what can you do? Fortunately, the solution is simple. You always send an email to the email address provided. However, the content of that email changes based on whether a user exists with that email address. Your confirmation message displayed on the web page would simply say “An email has been sent to (provided email address) with further instructions.”
With this approach, it means you’ll need two different emails, one for each scenario. The first would be the primary reset email with a URL and the normal instructions. The other email would be an explanation that the user account wasn’t found and suggest alternative approaches or ways to contact support for help.
If the user exists, you send your normal password reset email. If the user doesn’t exist, you send a different email explaining that user account was not found and suggesting that they try a different email address. The downside of this approach is that the feedback isn’t quite as immediate as displaying a “user not found” message right on the web page, but it makes it impossible for anyone other than the email address owner to enumerate a list of user accounts for a given service.
This way, your application won't leak the existence of specific usernames or email addresses. Only the owner of the email address will receive any details about the password, and anybody looking to uncover existing users will always see the same message and never know whether the account exists or not.
What are the goals of password reset emails? #
Password reset emails are some of the most succinct emails you can send in terms of goals. Generally speaking, they have one goal: to help users securely re-establish access to their account. In most cases, that will be through the password reset link, but in other cases, it may be more complicated. What if the link expired? What if they’re having problems entering a new password? What if they’re on a mobile device? What if they didn’t make the request to reset the password?
So, while the primary goal is simple, the edge cases around helping people aren’t quite as simple. 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 they initiated the request, help them re-establish access to their account #
In this context, the only goal that matters is getting them to the page that enables them to reset their password. It’s also handy to provide easy-to-access options for getting support either by letting them reply to the email, or following a link to a form for kicking off a support request. If they have problems resetting their password, the next step is likely to get help, and the easier it is for them to get help, the happier they’ll be.
It is worth noting here that if they can reply directly to the email, the original password reset URL will be included in that email, and the receiving customer support agent could abuse that. Hopefully, your support team is trustworthy enough not to abuse that, but it’s worth keeping in mind. This may be one of the only cases where considering a no-reply address is warranted depending on the importance of security for your application.
2. If they didn’t initiate the request or aren’t sure if they initiated it, help them understand what that means and whether they should be concerned #
With password reset emails, it’s very realistic that someone will receive a notification even though they didn’t request it. This could be caused by a typo or someone genuinely trying to gain access to an account they don’t own. In these cases, a properly engineered password reset process should make these notifications harmless.
As a recipient of these emails, it can still be disconcerting—especially if you know nothing about how the system is engineered. If the link doesn’t expire automatically or is otherwise insecure, it can be necessary to take steps to prevent 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” could help with this.
Beyond that, less technical users may be confused or generally concerned about the email. In these cases, it’s important to clarify that if they didn’t request the email, it’s safe to ignore it. And finally, make sure there's an easy way for them to contact support or get help if they're concerned about the security of their account.
What are some key considerations or common mistakes with password reset emails? #
Sending passwords in emails #
This is more of an implementation detail 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 how passwords are being managed in the 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 for users to change their password.
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. So, where possible, make sure to include some relevant information to help your emails stand out from phishing attempts.
And, if you know that you have a widespread phishing problem due to the nature of your business, make sure you’ve implemented a DMARC policy to address the problem and give your customers reason to be more confident emails from you are actually from you.
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, something’s wrong, and your provider may not be living up to their end of the bargain. This slowness can impact your reputation and create extra work for your team, which is why we publish our delivery speeds to the major email providers right on our status page. Fast delivery times to the inbox are a core piece of great deliverability.
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. When people request a password reset, they expect it to arrive almost instantaneously. If it takes longer than a minute or two, they’ll either move on, and maybe not come back, or they’ll email support. Both outcomes hurt your business. You may be able to get away with slow sending in some cases, but if sending is slow, support requests around password resets will be one of the first signs you have problems.
What information should be included in reset password emails? #
As simple as a password reset email is in theory, there are quite a few details to get right. Your exact implementation may vary depending on your audience and product, but these are the key bits to make sure that you get right.
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 important 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.
The link to reset the password #
In most cases, the link to perform the password reset is by far the most important piece of the email. It should be highly visible and easy to click. Since the URL will inevitably be clunky with the expiring token, it’s best if the link is included as the href attribute of a link rather than embedded directly in the email.
Expiration information #
If the link expires—and it should—include a sentence to let the recipient know that it expires and how long until the link expires. And, 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 it’s possible the link will expire before the recipient has an opportunity to check their email and reset their password. So it’s important to clearly communicate both the fact that the link expires as well as when the link will expire.
How to contact support #
When people request a password reset, it’s driven by the fact that 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. If all goes well, the automated processes will be all the help that they need, but if something doesn’t go well, they need other options. At a minimum, they need direct access to a support channel for getting help, but ideally they’d have access to several options for support to use the one that works best for them.
Who requested the reset? (IP Address? User Agent?) #
Another consideration that would require some extra engineering but can be a great security feature is to provide the recipient with some 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 even go so far as using an IP address lookup service to approximate the location from which the request was made. While this wouldn’t be universally helpful, for the right products and audiences, it can be a great tool to help build trust.
The “Address not found” email #
Finally, if you take the approach we mentioned earlier of sending an email to inform someone a user account wasn’t found, you’ll need a dedicated email just for that scenario. In this context, the attempt may or may not have been malicious. You’ll want to let the recipient know that the request was made as well as whether they should be concerned. If they did make the request and the email address or username wasn’t found, then they’ll need advice to try a different email address.
The checklist #
And here's a quick summary checklist to help remind you of the individual points once you start designing and building your template.
- Relevant and readable subject and "From" name
- The link to reset the password
- Expiration information for the link (5 minutes? 24 hours?)
- Support contact information
- Who requested the reset? (IP address? User agent?)
Postmark's password reset 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 just give you guidelines. Which is why we've created an open-source password reset template you can use for any project.
There are a few password reset templates in our collection. All together these password reset emails 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 in their Github repository.
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 how we can improve 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 email.
- 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