Why Verify Emails

The email you received might not be theirs

When a user signs up with [email protected], you know one thing: someone typed that email into the form. You do not know that the person typing is Alice, or that Alice controls that email address.

Without verification, your app accepts any string that looks like an email. This causes problems.

The problems

Typos. A user signs up with [email protected] (typo in “example”). They never receive password reset emails because the email is wrong. They contact support. You waste time on a problem that verification would have caught at signup.

Fake signups. An attacker creates accounts with emails they do not own. Depending on your app, this could mean: sending spam from “their” account, claiming someone else’s identity, or flooding your user table with garbage.

Abuse via notifications. If your app sends emails (welcome emails, notifications, newsletters), unverified signups mean you are sending emails to people who never asked for them. This can get your domain flagged as spam.

Password reset to the wrong person. If Alice signs up with Bob’s email (intentionally or by typo), Bob receives Alice’s password reset emails. Bob can reset Alice’s password and access her account. This is an account takeover via misattributed email.

What verification proves

When the user clicks the verification link, you know:

The email address is real (it received the email)
The person who signed up has access to that inbox (they clicked the link)
The email is correctly typed (a typo would send the link to the wrong inbox)

This does not prove the person is who they claim to be (that is what government ID verification does). But it proves the email account belongs to the person creating the account, which is sufficient for most apps.

When to verify

At signup (recommended). Send the verification email immediately. The user can start using the app but some features are restricted until they verify.

Before first sensitive action. Allow signup without verification, but require it before the user can send messages, create content, or access billing. This reduces signup friction while still ensuring verification before meaningful use.

Never (not recommended). Some internal tools or prototypes skip verification. This is acceptable for internal use but not for production apps with real users.

Exercises

Exercise 1: Sign up for a service you use and pay attention to the verification flow. When did they send the email? What could you do before verifying? What was blocked?

Exercise 2: Think about what happens in your app if someone signs up with an email they do not own. What features could they abuse?