When you ask visitors to surrender their e-mail addresses to you, make your case well or you’ll end up with too many duds. You should always provide a clear and immediate benefit to your visitor as to why you need this. If the real answer is “We need it for CRM reasons”, you shouldn’t be asking at all.

Reasons your visitors are less likely object to

• It’s your login name
• We need it if you forget your password
• We need it notify you when other users interact with you
• We need it to send you a receipt of your payment

Of these, the first three allows you to ask for an e-mail address early in your relationship, whilst the fourth is on a need to know basis.

Two Damme Tough
When it comes to validation, it’s far from uncommon to add double fields for e-mail input. The idea is to reduce the risk for typos as visitors type their e-mail address twice, and it probably will catch one or two typos. Now take a moment to consider the other aspects of this pattern.

• Some users will type their e-mail once and then copy & paste it into the second field.
• Autocomplete may have been corrupted with a bad address and will Autofail with misspelled address in both fields (this is usually a transient problem but also the cause for much chagrin until diagnosed).
• Some Users simply have their e-mail address wrong in their heads.
• It’s One More Field to be completed before the visitor can move on to what they’re actually after. One more obstacle on the path to instant gratification.

How to validate properly
First of all; Make sure your developers are happy and rested. Secondly, Don’t let anyone waste their time on defining the perfect e-mail validation regular expression – according to RFC 2822, almost anything is a valid address. Read this post if you’re curious for more.

Instead, do this;
Validate the domain part of the e-mail address by making sure there are MX records configured for the domain. This won’t ensure the validity of the recipient, but chances improve drastically. You can take it even further, and basically query the actual mail server if will accept an e-mail for a specific alias. There are several companies that offer this as a service.

Challenge-response confirmation
This is very common, especially when using e-mail addresses as usernames. You send an e-mail, and the user confirms their control of said address by clicking the link in the e-mail or copy-pasting the unique token into a form on your website.

The pattern sometimes fails and common culprits include spam-filters and network congestion. Challege-response confirmation is relatively onerous to your users and requires patience from both parties. Again, there should be a clear reason and obvious benefit to the user for this to be viable.

Feedback confirmation
Sooner or later, collected addresses are going to be used. The feedback from this should be taken into account. A bounce could void previous positive confirmation and the user will be asked to revalidate, or the address simply marked. LinkedIn does this well in theory; If an e-mail sent to my primary address bounces, they’ll e-mail all my secondary ones telling me about it and also asking me to revalidate. In practice however, it’s not very cool – they’ve asked me to revalidate approximately twice every month for some time now, and I’m quite sure my address has been operational throughout.

If you’re going to take one thing away from this post
You can ask for and collect virtually any information, as long as you provide a clear reason and obvious benefit for the user.