User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

It's pretty much a fact that users hate having to open a new tab, go to their email service, log in, wait for the email to arrive and then click a link/paste a code.

Is it really necessary to do this though? The only reason I ask for an email address is for if the user has forgotten their password. But, my thinking is, it's up to them if they want to run the risk of not being able to reset their password.

Should I verify their email address, or should I just warn them that should they enter an invalid email then they won't be able to reset their password if they ever lose it?

share|improve this question
This question needs more context, there are many situations, from guest checkouts to ordering a driving license online to very human-centric social sites, each of which differs in the way the account email and password reset interaction is defined. Can you tell us what sort of site you are designing? Otherwise I fear the question may well be closed. – Toni Leigh Nov 17 '13 at 22:31
Judging by the amount of e-mails I get asking me to reset other people's passwords... verification is advisable if you're keeping any sensitive data. – dbkk Nov 18 '13 at 18:23
up vote 16 down vote accepted

We have spent the last months battling with what to do with email confirmation/verification - prior the user had to give all their details at sign up (way too many actually!) but couldn't actually login until they had confirmed their email address by clicking a link.

We stood back and looked at why we did this - three reasons really, one being we wanted users to be able to reset their password etc but also because we wanted to assured of the identity of anyone interacting with our application and this was one small way of doing so. Additionally, we wanted to know the country, industry, employees etc for our clients for marketing reasons but this is flawed as we have literally HUNDREDS of signups for companies called some variation of TEST with 1 employee working in accounting.

The problem we had was emails sometimes don't get delivered - whether it is for technical reasons or simply delays or people entering the wrong email address/typos and this was creating work for our support team but also making a poor first impression for the prospective client.

A few weeks ago we made two major decisions - we now allow clients to signup by just giving us their email address with no requirement for confirmation.

Upon doing so they are immediately logged in (so no waiting) and, in the background, an email is sent asking them to set their password by clicking a link.

This email, in effect, works as a verification email - if they were never serious and were just tyre kicking then they will either have entered a dummy email address or they will never confirm in which case we are no worse off. Indeed by asking for them to create a password we could be better off as only those who are serious and / or like what the application does and looks like etc will actually do so.

If they are serious then they need to create a password to be able to login next time - we are working through more notification within the application to let clients know they need to create their password etc but, as of this morning, we have had ZERO support emails in the last three week raised due to non receipt of signup emails.

There has been a drop in confirmed signups which we expected but this, in itself, is pretty meaningless as previously they would have signed up, kicked the tyres and never logged in again whereas now they signup, kick the tyres and just don't create a password. We need to work through the overall impact in terms of accounts created, number of users and other success metrics etc but, overall, it looks positive.

I still believe we have a need for some sort of email and identity confirmation - the way we now approach it is slightly different to how we did before but it gives the same outcome without being a barrier to the customers initial experience and first impressions and that was what was most important to us.


Just thought I would update this with some stats - we changed our signup process on 28/10/2013. Below are two charts - first one shows confirmed signups (i.e. those who have then gone on to create a password) and the second shows all signups which is more akin to prior data points where all accounts were confirmed before being able to login.

As you can see, there is a drop off in the first chart where almost half of those who signup do not confirm / create a password (this maps to our current stats which shows around that percentage who only login once) and the second chart shows that, at the top end, this has not impacted signups with the number of signups remaining fairly consistent pre and post making the change.

enter image description here

enter image description here

share|improve this answer
What do you do with unconfirmed sign ups? Are they removed after some period of time? – Rob Nov 18 '13 at 15:42
Historically, we have just left them in place and, under the new process, we still are having a discussion around how to deal with them. In that first usage after signing up but prior to creating a password, clients can add data to their account and may decide at a later date they want to come back and deleting them could be a problem especially as the "cost" of leaving them in place is minuscule. – bhttoan Nov 18 '13 at 15:48
Do you have any compare between new and old confirmation methods about verified signup rates? Did you experienced increase in confirmed signups? – Ali Gonabadi Dec 3 '15 at 6:51

If you're fine with not having a verified communication channel with your user. Then sure.

But I can't really think of an application where I wouldn't want that. Because not having that verified email means that a forgotten password is the end of the account.

Further there's few things I'd allow that type of unverified user to do that I couldn't just do with a guest that could store its settings in a session/cookie.

There's also simple solution.

Use OpenID. You know, like stackexchange does! Offer several choices and for most users you'll have avoided the annoying email verification step.

More work for you but should (mostly) solve the problem.

share|improve this answer
But without verification, you still can send a forgot password email can't you? If the email was wrong or is of someone else, it's the fault of the user... but mostly it will not be – Ixxzz Sep 21 '15 at 19:29
I was considering the case of an account where someone makes up an email just to try the service out. I should've been more clear. However, you will run into trouble if emails are the unique for every user since one person can claim another person's real email address. And yes, the real email owner could use reset password but then his actions are merged with the actions of the original person (which I certainly wouldnt want if I used the service). – jmathew Sep 21 '15 at 20:21
Yeah, was thinking about that... the confirmation step is necessary. – Ixxzz Sep 21 '15 at 20:41
OpenID is a really good, non-intrusive method. – Luca Steeb Mar 11 at 23:17

Verifying an email address is less trouble than all the troubles that could happen if not having one for an account. Nobody is going to join your site simply because they don't have to verify their email address.
So you should have them verify it but make it as fast and as easy as possible.

share|improve this answer

I think that as the application designer, you have the responsibility to protect the users from themselves. Hence, you must provide some way for them to restore it.

The e-mail option has its downsides as you said but so are other alternative like security questions. Common approach is to include a link which automatically verifies the account w/o the user need to cut and paste.

share|improve this answer

If you need to do email verification check, don't let that be the show-stoppable for the users to continue interacting with your site, that might just increase the drop-off rate.

Other reasons such as delay in the email sending, email going into user's spam folder, will just add more reasons for them to stop interacting with your site.

As what others have mentioned, any functionalities in the site that required some form of verification first, just alert the user about it. These could include update user profile or relating to any contests that requires personal identification.

Hope this helps.

share|improve this answer
In particular, collectors of email addresses should not send other mail to them until they have been validated. This is simply courtesy for the owner of the email address, which may not be the same person who submitted the address during registration. – iX3 Jan 29 '15 at 15:32

I think it is an important precaution for a potentially horrendous UX. A little bother in advance to prevent a lot of potential problems in the future. However, the way to make this not bother your users too much is to remove the need for them to do it right away.

If possible, let the users sign up and engage with the system, and then the next time they're on their email, they'll see a clear subject line call-to-action. If they don't validate in a while, take an action appropriate for your specific context (notification on next login, second email, etc.).

share|improve this answer

I dont think that confirming the email address is just about having a communication channel to the user. I think that confirming emails is an absolute must, if not you have to cleanup in order to ensure that no one spoofs existing emails of other users. E.g. someone can register all emails of another user to troll him. Or if he merely mistyped his email, someone else could possibly be able to reset his password, which would I think in return cause more trouble overall than confirming the email address.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.