One of the most frequent features available for testing is the email subscription. Testing it is similar to testing the registration flow and it requires 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 which 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 - 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, 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 which doesn't follow the email structure pattern. Let's see some examples of invalid emails:

You can find more information about email addresses here.


Email Validation


Email Validation represents actions taken in an attempt to check if the input is compliant 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 represents the action taken in verifying if an email subscription accepts valid email addresses while negative Email Validation is focused on checking if the system accepts negative entries as well.


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)

Note: If you want to check is an email is valid or not before you start testing, you can use this free online tool.

How different customers check user emails

Depending on the budget, customers have at their disposal 3 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 which validation method they use, sometimes their standards disallow using disposable emails (qa.team, yopmail, etc). In such cases, testers need to use their own emails (preferably used only for testing) to test the email validation, deliverability of activation links, bouncing links, etc.

Umlauts and ß in the email address

Quite often our testers report an email validation bug related to umlauts and ß character. 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 English alphabet are supported while the rest of the letters are considered as invalid

  • The validation might be implemented on the base of experimental RFC 5336 which allows international letters

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

Be aware when trying 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 just avoid submitting a bug which you are not sure off. 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 scope of the test at Test IO and such bugs will be rejected.

Did this answer your question?