The approach of attempting to deliver a test email synchronously and seeing whether that fails? That's fine in principle. After all, it's in principle just what the MTA would do once you actually sent the email, and what would cause the MTA to generate a bounce message in the case of failure.
The practical problem is essentially the same as with all the syntax validation out there: It's extremely likely that you are getting it wrong, thus, once again, rejecting valid addresses because your implementation is buggy and behaves differently than an actual MTA.
As for the how so: Because somebody obviously, as is so often the case, just made shit up and implemented that instead of reading the relevant standards and implementing what they say. That's how most of the interoperability problems out there start: People have some passing familiarity with some protocol or data format, and then they implement code handling that protocol or format based on their idea of how things work, instead of what the standards actually say. That's just how we end up with people rejecting email addresses that contain "+" characters in the localpart. I mean, RFCs are public, what more do you need? If you want to implement an actual email address validator, you don't have to pay anything, you don't need to sign up anywhere, you just have to read it, and you can actually build a reliable email address validator, and there is nothing wrong with doing so. Yes, that is more work than just implementing your fantasy protocol. But if you can't be bothered with that, then just forget it and use an existing implementation by people who did care--namely, use an MTA to send a verification email.