Email verification is treated as a formality, which is why it is so often built in a way that either annoys everybody or proves nothing. It has exactly one job: establishing that the person holding this account can receive mail at this address, at this moment.
Everything else people hang on it — that the person is real, that they work at the company in the domain, that they are not a bot — does not follow, and building as though it does leads to decisions the evidence does not support.
Decide what unverified users may do
Blocking the product until verification completes is the simplest rule and it costs you sign-ups, because delivery is slow, spam filters are opinionated and people mistype addresses. Letting an unverified account do everything is the other extreme and it makes your product a convenient way to send mail to strangers.
The workable middle is to let people in and gate the actions where an unverified address causes harm: inviting others, being invited, receiving notifications, appearing in a directory, anything that puts the address in front of another user. Show the state clearly with a one-click resend, and expire the account if it is never verified.
- Allow exploration, gate anything that emails or exposes the address
- Persistent, dismissible banner with resend — not a modal wall
- Rate limit resends per address and per account
- Handle hard bounces: mark the address undeliverable and prompt for a new one
Verification proves somebody can read that inbox today. It does not prove who they are or where they work.
Changing an address needs both sides
The change flow is where accounts get stolen. Sending a confirmation to the new address only means a session that has been compromised for ten minutes can move the account permanently out of its owner's reach. Confirm at the new address to prove it is reachable, and notify the old one with a way to object and an immediate route to lock the account.
Keep the old address active until the new one is confirmed, and require re-authentication before starting the change at all. This is a small flow with a large blast radius, and it is worth the extra prompt.
Verified is not governed
The most consequential mistake in this area is treating a verified address as evidence of organisational membership. Somebody can control an address at a domain without being an employee, and a consumer account at a provider that also sells business accounts looks identical in most token claims.
If access depends on belonging to an organisation, that has to come from the organisation — a claimed domain the customer proved they control, a directory that lists the person, or an assertion from their identity provider. Verification is the right check for reachability, and the wrong one for authority.
- Domain claiming is proof of the domain, not of any individual at it
- Automatic organisation join by domain suffix is an escalation path; require the claim first
- Free-mail and disposable domains are a policy question, not a verification one
- Record verification as an audit event, including changes and re-verifications
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.