The two checks, and what each actually proves

An MX lookup asks DNS whether a domain publishes mail servers at all. A domain with no MX cannot receive mail under any circumstances, so every send to it is a guaranteed bounce. This check is free, fast, cacheable, and it never lies. On a list of 79,093 addresses it removed 1,457 across 4,234 distinct domains, which is a few thousand DNS lookups rather than eighty thousand.

It also proves very little. A live domain says nothing about whether a particular mailbox at that domain exists. On a list of historical addresses almost every dead entry is a dead mailbox at a perfectly healthy domain: an abandoned Hotmail account from 2013 passes the MX check exactly as well as an active one.

The second check is meant to close that gap. You open an SMTP conversation with the domain's mail server, issue MAIL FROM and then RCPT TO for the address, and read the response code. You never send DATA, so no message is delivered. A 250 means the server accepted the recipient; a 550 means it refused.

What the probe actually returns, by provider

The way to test whether a probe is honest is to point it at a mailbox the provider has ALREADY told you does not exist. Take addresses that hard-bounced with 5.1.1, then ask the same server about them again and see whether the answers agree.

Measured against exactly that set:

gmail.com 550 5.1.1 The email account that you tried to reach does not exist hotmail.com 250 2.1.5 Recipient OK yahoo.com 250 recipient <...> ok aol.com 250 recipient <...> ok

Gmail is consistent: it refuses at RCPT what it would refuse later. The other three accept every recipient at SMTP time and issue the rejection asynchronously afterwards, as a bounce message. This is a deliberate design choice on their part, and a reasonable one, because answering truthfully at RCPT turns any mail server into a free directory-harvesting oracle.

The consequence for verification is not that it fails. It is that it lies. A dead Hotmail address returns 250 and gets recorded as good. Run that over a consumer list and you do not get a partial answer, you get a confident wrong one covering roughly half your addresses.

Where you probe from changes the answer

This part costs people a lot of time, because the failure looks like a different result rather than like an error.

The same probes run from an ordinary machine, a laptop or a cloud box without a PTR record and without sending history, do not return 250. They return nothing: Microsoft, Yahoo and AOL close the connection before RCPT is reached. Only Gmail answers at all.

It is easy to read that as 'these providers cannot be probed' and move on, which happens to reach the right conclusion by the wrong route. Run the identical code from a host with a proper PTR record and established sending reputation and the connections succeed, and the honest answer appears: they accept everything.

So a verification result is only meaningful if you know which machine produced it. Two runs of the same tool from different hosts return different things, and neither announces which situation you are in.

What to do about the half you cannot check

There is no pre-send check for Microsoft, Yahoo and AOL mailboxes. That is worth stating plainly, because the market for verification services is built on implying otherwise, and their own pages cannot say it.

What remains is a feedback loop rather than a filter. Send in small batches, read the bounces back out of your own mailbox, suppress the permanent failures, and let the observed bounce rate decide whether the next batch goes out. Bounces arrive as RFC 3464 delivery status notifications, which are machine readable, so this is automatable.

One trap in implementing it. The part of a bounce carrying the failed recipient and status code is a message/delivery-status part, and that is not text. In Python, get_payload(decode=True) returns None for it and str() of its payload gives a list repr rather than headers, so a parser that walks parts as text finds nothing. A first pass over a real mailbox reported 262 of 275 bounces as unreadable for exactly this reason, which reads as 'we barely have a bounce problem'. Reconstructing the sub-part headers explicitly took it to 264 parsed and 0 unreadable.

Suppress permanent failures only. A 4xx is a deferral, a full mailbox or a greylist, and dropping those addresses forever loses real people to a server having a busy afternoon.

The number that decides whether any of this matters

Bounce rate is what receiving systems judge a sender on. A few percent is normal. Sustained double digits gets a domain filtered and then blocklisted, and the damage is not limited to the campaign: ordinary mail from the same domain starts landing in spam.

For calibration, a real measurement rather than a rule of thumb. A list of historical consumer addresses, already MX-validated, produced a 34% hard bounce rate on first contact. A second list pulled from a production user table did worse at 60%, because it still contained test signups that nobody had filtered out. Both would have been fatal to the sending domain within days.

Which is the real argument for verification, stated honestly: not that it makes a bad list safe, but that it tells you the list is bad before the receiving world does.