That is, you want to allow people to stroll in and start using your app.
Great.
But just don't send out any emails on their behalf unless/until they've clicked the verification link in the one email you will send to them.
This makes me think - should there be a link in the email that says, "This was not me" -- that allows the website dev to ban the offending IP?
Maybe not ban the IP but definitely remove the email from the account (after a confirmation CTA). Some services do this and if I known them I hit the link.
I get a ton of emails for others on a weekly basis with a ton of info not meant for me to see.
One specific account "I" signed up for was a playstation account that actually prevented me from signing up for my own account. It took ~1hr of live chat with Sony to actually create an account with my email address.
(And yes I am aware I can add additional periods or +keyword to the email)
But in general, always verify. You can let users in with an unverified email (better for growth), but you should still send the email and handle verification.
I’ll give you an example. Say you want to add social logins and want avoid duplicated account. You can implement auto linking. I sign up with my email, then I log in with google, if it’s the same email AND I did verify it, then you can auto link. If I didn’t verify my email, you must not.
* knowing this is a real person
* marketing communication
* security/data breach communication
* forgot password flows
* step up authentication (send a code to an email)
* user lookup if one user wants to share something with another
* putting users on teams/allowing special access based on domains
In most of these cases, you want to verify not just that someone knows an email address, but that they have access to and/or control the inbox. This is what verification proves.If you are just looking for a globally unique identifier and aren't doing any of the other stuff, you could skip verification. But in most cases you'll want to do this.
Incidentally I hope you are using a drop in auth service or a library--there's a lot out there and no need to roll your own.
That way you don't have to deal with passwords, and you will know the user has a mailbox which they control.
About the frequency: there aren't many situations where a user has access to your application, but not to email. I've been thinking about that, but when you have access to a browser, (most of the times) you have access to your mail.
Just my $.02.