I haven't been able to replicate this behavior. I tried the following:

First, I shut off all network connections and ran this code:

my $address = Email::Valid->address(-address => 'foo@example.com', -mx
+check => 0, -tldcheck => 0, -fudge => 0);
use Data::Dumper;
warn Dumper $address;
[download]

I did not block. Next I added $Email::Valid::Debug = 1; at the top of my script, and saw no debug output. Next I ran the same but with -mxcheck => 1. With that setting I did block (my network was off) and saw this output: using Net::DNS for dns query. Turning the network back on, I got a clean response but with that same debug. My next step was to override the Net::DNS::Resolver::new sub and the Net::DNS::mx sub so that they would warn if invoked. With -mxcheck => 0 I got no warning. With -mxcheck => 1 I got the warning indicating I was hitting Net::DNS code.

Finally I spewed %INC with -mxcheck set false. Unfortunately Net::DNS does get loaded even if the check is turned off. But with no network I never blocked.

In the POD for Email::Valid it mentioned that you can set $Email::Valid::Resolver->tcp_timeout($seconds) and $Email::Valid::Resolver->udp_timeout($seconds) to set how many seconds you're willing to wait on the network. If you continue to find a way to get blocking behavior despite turning off the external checks, set that number really low. However, in my own testing with the network turned off, those two method calls didn't seem to do what was needed; I still got blocking behavior.

One more thing: I looked at Net::Domain::TLD and saw that it does not seem to hit the network. So you could probably enable -tldcheck => 1 without blocking.