Email validation and verification
Email validation checks whether an address meets the application's supported format, while verification checks control of the mailbox through an appropriate flow.
What it means
Email validation checks whether an address meets the application's supported format, while verification checks control of the mailbox through an appropriate flow. Neither proves a person's real-world identity. Address normalization must preserve meaning rather than assuming all providers treat punctuation and case identically.
A practical example
An account service stores a supported address representation and sends a verification message before relying on it for sensitive recovery. A change to the address requires its own protected workflow and does not silently transfer trust to an unverified mailbox.
What to check
Define supported address rules, distinguish verification from identity proofing, and review account matching. Test unusual valid addresses, normalization collisions, and changes to verified recovery destinations.
A common pitfall
Aggressive normalization can accidentally merge distinct accounts or transfer privileges. Provider-specific rules should not be applied universally to every email domain.
Think it through
Does verifying a mailbox prove the owner's legal identity?
Answer: No. It establishes control of that mailbox under the verification flow, not a complete real-world identity claim.
Mailbox control is a limited assurance
A fictional membership service sends a verification link to a newly supplied address. Completing the flow provides evidence that someone could receive and act on that message. It does not establish their age, employment, legal name, or enduring ownership of the mailbox. Product decisions should match the assurance actually obtained.
Account matching makes normalization important. One provider may ignore a particular punctuation pattern while another treats it as meaningful. Applying a provider-specific rule to every address can merge distinct identities. Define a supported storage and comparison policy and test it against the providers and address forms the application genuinely supports.
Changing a verified address should be treated as an account-security event. A new mailbox may become the destination for recovery and security notifications, giving it substantial authority. Protect the change with an appropriate authenticated workflow, verify the new destination, and consider notification and recovery options for the existing account owner.
Separate three different questions
For a local exercise, list an address's syntactic validity, successful message delivery, and completion of verification as separate observations. Explain why a syntactically valid address may not receive mail and why a delivered message may still never be acted on. Then describe what the service may safely conclude when verification succeeds.
Use expiring, appropriately generated verification credentials and avoid exposing them in logs or analytics. Handle repeated requests and already-used links predictably so users can recover from mistakes. Finally, review how the service handles abandoned registrations and address changes; verification is a lifecycle feature whose meaning can be undermined by a poorly controlled later update.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Email Validation and Verification