Skip to main content
Testing Email Validation

Quickly learn how to test the email validation

Zorica Micanovic avatar
Written by Zorica Micanovic
Updated over a week ago

"Testing email validation is an essential part of the test process which validates if the input complies with the Internet Message Format."

One of the most frequent features available for testing is the email subscription. Testing it is similar to testing the registration flow, requiring some basic knowledge to get it done according to the rules. Before we run into testing email validation, we need to make a crystal-clear distinction between valid and invalid email addresses.

Valid Email Address

Valid email address represents an electronic construction that follows the email structure pattern local part + @ symbol + domain.

The local part of the valid email address consists of the first part before the @ symbol upper- and lower-case letters, numerals (0-9) and characters like !#$%&'*+-/=?^_`{|}~.

Remember that the maximum length of the local part of an email address is 64 characters and that the dot symbol is allowed if it is not located in the first or last place in the email structure nor if a dot is followed with another one or more of those.

The domain part of the valid email address consists of upper- and lower-case letters or numerals (0-9). The numerals are not allowed in the last section of the domain part - the top-level domain (after the dot). Even though the use of the dot is permitted, it is not allowed to use as the first or the last element of the domain part (top-level domain). The top-level domain disallows using less than 2 characters and more than 63 characters. In reality, the majority of top-level domains contain up to 9 characters. No spaces are allowed in the domain part.

Remember that the server will not trigger the length validation for the domain part of the email.

Now let's see some examples of valid emails:

Invalid Email Address

An invalid email address represents the electronic construction that doesn't follow the email structure pattern. Let's see some examples of invalid emails:

Email Validation

Email Validation represents actions taken to check if the input complies with the Internet Message Format, aka RFC-5322 standard. More about this standard can be found here.
Testing the email validation, in this case, means that testers are checking the effectiveness of the contact information uploaded to the Emergency Mass Notification System.


Email validation testing can be positive and negative. Positive Email Validation is the action taken to verify whether an email subscription accepts valid email addresses. In contrast, negative Email Validation is focused on checking if the system also accepts negative entries.


Testing Email Validation consists of 3 steps:

  • Syntax Check (valid and invalid email syntax is explained above)

  • Domain verification (domain part is everything after @ in the email address)

  • Mailbox Validation (checking if the mailbox exists)

How different customers check user emails

Depending on the budget, customers have at their disposal three options to check if the email is valid or not:

  • Real-Time Check-Up (the validation is implemented and should check all entries at the input)

  • Checking Addresses Individually (a lot of manual work, and it is typical for companies with small budgets)

  • Checking the file with all emails using 3rd party tools (3rd party tool cleans the file out of the invalid entries, and only valid ones are kept)

No matter their validation method, sometimes their standards disallow using disposable emails (qa.team, yopmail, etc.). In such cases, testers must use their emails (preferably used only for testing) to test the email validation, deliverability of activation links, bouncing links, etc.

Umlauts and ß in the email address

Our testers often report an email validation bug related to umlauts and ß characters. Testing the validation, in this case, is tricky for three reasons:

  • The validation might be implemented on the base of RFC-5322. If this is the case, no internationalization is allowed. It means that only Latin letters from the English alphabet are supported, while the rest of the letters are considered invalid

  • The validation might be implemented based on experimental RFC 5336, which allows international letters

  • The validation is not implemented, and all letters and characters are implemented.

Please keep in mind when you try to prove that the validation of international letters exists because you have to prove that RFC 5336 (or even RFC 6531) is in use. If you are in doubt, it is better to refrain from submitting a bug you are unsure of. Another option would be to ask your experienced colleagues to help you understand which RFC is in use.

Note: Browser validation is not in the test scope at Test IO, and such bugs will be rejected.

Free Online Email Address Validators

Another way to improve your email address input validation testing is by checking your inputs in advance with the help of free online validators. One is VERIFALIA, which provides an email validation service where you can input an email address and check it for validity, ensuring it is appropriately formatted and deliverable. The service helps identify and eliminate invalid or potentially harmful email addresses, ensuring improved data quality on your bug reports.

Did this answer your question?