OP said to not validate.

The OP is contrasting between a 'validation' function with type e.g.

    validateEmail :: String -> IO ()

and a 'parsing' function

    validateEmail :: String -> Either EmailError ValidEmail

The property encoded by the ValidEmail type is available throughout the rest of the program, which is not the case if you only validate.

That's fine.

Validation would be:

   Email email = new Email(anyString);
   email.validate();

Parsing (in OP's context) would be:

   Either<Error, ValidEmail> eEmail = Email.from(anyString);

You're misunderstanding. Validation looks like

  validateEmail : String -> String -- post-condition: String contains valid email

whereas parse looks like:

  parseEmail : String -> Either EmailError ValidEmail

There is no problem using `ValidEmail` abstraction. The problem is type stability, when your program enters a stronger state at runtime (i.e. certain validations are performed at runtime) it's best to enter a strong state at compile time (stronger types) so that compiler can verify these conditions. If you remain at String, these validations (that a string is valid email) have no compile-time counterpart so there is no way for compiler to verify. So use `ValidEmail` instead.