[handrous]

Lots of these kinds of things—at least for companies that aren't just copying others' patterns blindly—are the result of multiple support calls/emails/tickets. The tickets, in this case, would be users complaining about your service being broken when in fact they messed up their email address and don't realize it. There are also some cases in which you want to use the address immediately to reduce friction (as with sending receipts or shipping data for an order by a "guest" user without an account) without first sending a verify-address email.

My personal preference is to let the user know why you think the email address looks wrong and give them some way to override your judgement and submit anyway. It's more work, but it gives you all the benefits of rejecting "bad" addresses while minimizing the harm of false-positives from your bad-address-spotting code (it's very slightly annoying to people with odd-looking addresses, but not that big a deal). This also lets you go beyond validating the form of the email address, to alert on common typos that might be legitimate (and which can sneak in even if you make the user type the address twice). "gmial.com looks like it might be a mistake; are you sure you got that right?" Or "yaho.com". Or even just Levenshtein-distance check a bunch of common email domains and alert any that are close, but not exact. You annoy whoever has an actual address at those domains, but save a bunch more people who screwed up.

[cge]

This has been common for mailing addresses: with a parsing and validation system, the site will tell the user "We think you entered ... as your address; we think your address should be this: ...", along with options to keep the original entry or use the suggestion. This has the advantage of catching mistakes, not making unusual addresses unusual, and letting the user know if the site is interpreting what they entered in a way that won't actually work (eg, leaving off something important, or ordering components badly).