How do I verify email addresses during signup?

A good email verification flow during signup usually looks like this:

1. User enters email + password
2. Create an unverified account
3. Send a verification email with a unique, time-limited link or code
4. User confirms email
5. Mark the email as verified and let them continue

Common approaches

1. Verification link (most common)

• Generate a secure, random token.
• Store a hashed version of it in your database with:
  • user ID
  • expiration time
  • whether it’s been used
• Email the user a link like:
  • https://yourapp.com/verify-email?token=...
• When they click it:
  • validate token
  • check expiry
  • mark email verified
  • invalidate the token

2. Verification code

• Generate a 6-digit or short alphanumeric code.
• Email it to the user.
• Ask them to enter it during signup.
• Verify it server-side and expire it quickly.

Best practices

• Use cryptographically secure random tokens
• Expire tokens quickly, e.g. 15–60 minutes
• Hash tokens in storage so leaked DB data can’t be used directly
• Allow resend, but rate-limit it
• Invalidate old tokens when issuing a new one
• Don’t fully enable the account until verified, if email trust matters
• Make verification links single-use
• Normalize emails carefully:
  • lowercase domain at minimum
  • be cautious about assuming local-part case rules
• Handle abuse:
  • rate-limit signups and resend requests
  • consider CAPTCHA if needed

Typical database fields

For a users table:

• email
• password_hash
• email_verified_at nullable
• status or is_active

For verification tokens:

• user_id
• token_hash
• expires_at
• used_at nullable
• created_at

Example flow

• Signup request comes in
• Create user with email_verified_at = null
• Create token random_bytes(32)
• Store hash(token)
• Send email with link containing raw token
• On click:
  • hash submitted token
  • find matching record
  • verify not expired/not used
  • set email_verified_at = now()
  • mark token used

If you want higher security

You can also:

• require verification before allowing password reset or sensitive actions
• add device/IP logging for suspicious patterns
• use short-lived login magic links if you want passwordless auth

If you want, I can show:

• a Node.js/Express example
• a Django example
• a Laravel example
• or a database schema + API design for this flow.