Email Validation
Email Regex Test Cases
Use a focused list of valid and invalid email samples to review regex behavior before shipping a form or API validator. This reference is written for developers who need practical validation behavior, reviewable rules and safe examples rather than copied snippets with no explanation.
Recommended workflow
| Step | Why it matters |
|---|---|
| Build a tiny matrix | Keep a table of accepted, rejected and intentionally unsupported addresses. |
| Run the same samples everywhere | Browser, API, import jobs and tests should use the same fixtures. |
| Add regression cases | Every production validation bug should become one new sample. |
| Keep private data out | Use synthetic examples instead of real user addresses. |
Starter snippet
valid: dev@example.com, name+tag@example.co.uk
invalid: dev@, @example.com, dev example.com, dev@@example.comReview checks
- Include uppercase, plus tags, subdomains and long but reasonable domains.
- Include common typing mistakes and copy-paste whitespace.
- Record intentional product limits so support can explain them.
- Use automated tests rather than manual form clicks only.
Common mistakes
- Only testing happy-path addresses.
- Copying real customer emails into docs or public examples.
- Changing the regex without updating fixtures.
Validation should help users correct input while protecting systems from bad data. Keep syntax checks, product policy, security review and deliverability checks separate.
Related Formalint references
Continue with Email Regex Cheatsheet, Developer Data Validation Guide, Regex Examples.