Your class stays in conflict with the Single Responsibility P...

Your class stays in conflict with the Single Responsibility Principle. It also prevents IDN-domains from being validated. So, your class will automatically invalidate many many valid email addresses.

I recommend to use filter_var and a IDN transport for email validation.

The purpose of the class is to perform several levels of email validation. I believe it is still a single responsibility.

As for IDN I have not came across one example. Can you provide an example?

I suspect that is a matter of adjusting the validation regular expression, which is a class configuration parameter.

foobar@müller.de ( as an example )

en.wikipedia.org/wiki/International ...

I tested here with Thunderbird and it seems email addresses like that need to be encoded as UTF-8, so the regular expression would validate it if I included higher 8 bit characters.

No, they need to be encoded as ascii.

See http://php.net/manual/en/function.idn-to-ascii.php

Unfortunately, idn-to-ascii does not exist in most typical PHP installs so you'll want to provide a class like you do with getmxrr.

I am not sure what you mean? Do you mean the class validate addresses with unicode characters? Can you give me an example?

Sure, take example of teßt@düsseldorf.de

It will not pass your regex and getmxrr will not work with "düsseldorf.de." (note good practise to use final dot for fqdn)

You can change your regex to allow it, but getmxrr will still fail.

You must convert to Punycode representation in ASCII:

teßt@düsseldorf.de -> xn--tet-6ka@xn--dsseldorf-q9a.de

Now "xn--tet-6ka@xn--dsseldorf-q9a.de" will pass the unmodified regex and it will work correctly with getmxrr.

I tested all of this :-)

The issue, as I mentioned, is how best to do the conversion when function_exists('idn_to_ascii') fails on most systems. This will do it:

github.com/phpWhois/idna-convert

$IDNversion=2008;
$IDN=new idna_convert(array('idn_version'=>$IDNversion));
$ascii=$IDN->encode($fqdn);