As icktoofay points out:
It rejects valid addresses like
Check out this post for an interesting explanation without having to actually read the RFC.
The problem is with this section of code
As you are splitting on
,, it will split on any quoted
, characters within the email address local part such as the one found in the above email address.
With the exception of that, this is a good piece of code to find out if you have a possibly valid email address. Yes, control flow logic based on an exception is generally bad, however unless this is a massive bulk operation it will not cause anything more than a minor performance hit. At the end of the day, the only way to find out if it is truly valid is to send a message to it and ask the recipient to click a link containing a cryptographically secure random sequence. However, some anti-spam systems will automatically follow links in emails so this does not validate whether you have a human being at the other end, so you could get them to manually enter a random code instead on a form linked from the email.
To summarise, you need to find a method of splitting the email addresses without accidentally splitting on quoted sections. Yes, you'd be mad to purposely register the email address
"this;will,never,be;accepted;anywhere"@example.com or to set one up for one of your employees with an address like this. However, we had a customer using one of our systems recently and they requested a change to the email validation routine as their customer had an employee with an email address like
David.Oemail@example.com which our system was rejecting and they could not register.
This is why I like your approach of relying on the built in
MailAddress object to validate, which as also suggested in the first comment in this article: Don’t trust the .NET web forms email regex validator (or most others).