Manual TestingPublished: 6 min read
Email Regex Validation in Test Automation — Do It Right
How to validate email input in Selenium, Playwright, and Cypress with a regex that balances accuracy and pragmatism. Includes boundary test cases.
SoftwareTestPilot
QA Editorial Team
2026-07-17 · By SoftwareTestPilot
Every signup form has an email field. Testing it well means picking a pragmatic regex and covering the boundary cases — not writing a 6,000-character RFC 5322 monster.
The pragmatic regex
^[\w.+-]+@[\w-]+\.[\w.-]+$Covers 99% of real-world addresses; rejects the obvious garbage. Test it in the Regex Tester for QA before shipping.
Boundary test cases
VALID
a@b.co
first.last+tag@example.com
user_name@sub.example.co.uk
INVALID
plaintext
@nodomain.com
name@.com
name@domain
name@@domain.com
name domain@example.comPlaywright example
const invalidEmails = ['plain', '@no.com', 'a@b'];
for (const email of invalidEmails) {
await page.getByLabel('Email').fill(email);
await page.getByRole('button', { name: 'Sign up' }).click();
await expect(page.getByText('Enter a valid email')).toBeVisible();
}Don't stop at regex
A well-formed email doesn't mean a deliverable email. Also verify: MX record checks, disposable-domain blocking, and confirmation email delivery. Regex is the cheap first gate.
Frequently asked questions
1.Should I use HTML5 type='email' as validation?
Yes — as a UX hint. Server-side, always re-validate with a regex plus MX check.
2.Do I need to accept unicode local parts?
For international apps yes. Use the 'u' flag and \p{L} where supported.
3.What about plus-addressing (foo+tag@)?
Support it. Users rely on it for filtering; blocking it is an accessibility fail.
4.Is regex validation enough?
No — but it's the first cheap gate. Follow with delivery confirmation.