To test this, I tested the result for a non-existing dummy address was 'invalid', then registered a gmail account with that dummy address, then re-checked the result to be 'valid'. As far as I could tell, there was nothing sent to the new account (so e.g. they aren't just checking for a bounce from a test email)
How can this work? This basically allows for user existence enumeration, which I would expect Google might frown upon. Reckon they are abusing some Google API in some way? (e.g. I'm having fuzzy thoughts about calendar invites, doc sharing, etc.) I am working under the assumption that they have special-cased detection for Google accounts; I haven't checked other email providers. Obviously their service could not possibly work in the general case.
There are examples of successful and unsuccessful RCPT attempts here (scroll down to the second sample SMTP session):
https://en.wikipedia.org/wiki/List_of_SMTP_server_return_cod...
This is an entirely valid use of the SMTP protocol (getting back that status code is how you find out if a message to an address was undeliverable), but I suppose that if an e-mail provider wanted to prevent this kind of validation, they could stop accepting connections from subdomains of Experian that repeatedly aborted their SMTP sessions.
There are different approaches. As a sibling comment mentioned, you can use any login protocol that responds with a different message for users vs. non-users.
Off the top of my head, you have POP, IMAP, SMTP, OAuth, Gmail's undocumented HTTP API, Gmail's documented HTTP API, and web scraping.
You probably can't do any of those at scale.
To solve the scale issue, you could buy databases of verified email addresses, which are not expensive. For any address found in those databases, you know it's registered.
If it's not in your database, you can do a live check.
Alternatively, you could make a business arrangement with Google, which is also possible for a company like Experian.