Can anybody actually verify an address?
The protocol had a command for it, and the internet turned the command off.
SMTP defines VRFY, and the standard is strict about honesty: a server must not return a success code unless it has actually verified the address, and must not return one merely because the syntax parsed.
Operators switched it off almost everywhere, because a working verification command is a working address-harvesting command. The same document anticipates that outcome and reserves a reply code for an address that looks valid but resists verification in real time.
So every verification service you can buy works around a decision the mail system made deliberately. That is not a criticism of them; it is the reason none of them can be certain.
Why does a Gmail address always come back valid?
Because the probe those services use cannot fail there.
The workaround is to open a mail transaction, name the recipient, read the response and never send the message. That works on servers that reject unknown recipients at that moment, and on the same principle as an account-existence check, though the standard itself notes that some servers do not verify the recipient until after the message text arrives.
Measured on 31 July 2026, our own mailbox check skips nine domains outright — gmail.com, googlemail.com, yahoo.com, outlook.com, hotmail.com, live.com, icloud.com, protonmail.com and proton.me — and returns unknown at a confidence of 0.3 for them.
Publishing that skip list is the point. A service that returns a confident valid for a Gmail address is reporting the shape of the reply rather than the existence of the mailbox.
The catch-all problem
Some domains are configured to accept every address at them, on purpose.
It is a supported, documented feature rather than a misconfiguration: Google Workspace lets an administrator route messages sent to non-existent addresses on the domain into one mailbox, and the setting is named for exactly that.
Against such a domain the probe succeeds for every string you put in front of the at-sign. A positive result therefore carries no information about that particular mailbox, and a verification service has no way to distinguish the two cases.
Which is why honest tools return a third state. If a result comes back as anything other than valid or invalid, that third state usually holds the truth, and it is the one nobody puts on a marketing page.
The protocol had a command for exactly this question. The internet switched it off, and everything since has been a workaround.
What does an MX record prove?
That mail for the domain has somewhere to go. Nothing about the person.
An MX record is a routing pointer. Whoever controls the domain publishes it, saying which host accepts mail there, so it is a statement the domain's owner makes about their own domain.
So it proves the domain is set up to receive mail. It does not prove the local part exists, that anyone reads it, that a message would be accepted, or that the domain was registered any earlier than this morning.
Our own check returns DNS resolves in 857 milliseconds, and that field means precisely this and no more. A domain registered an hour ago with valid MX records passes it, which is worth knowing before anybody reads the field as reassurance.
What is a disposable-address check doing?
Looking a domain up on a list that people maintain by hand.
The canonical list is a public repository where contributions require citing where a throwaway address can be generated on that domain, so a maintainer can confirm it before merging. Other lists regenerate daily from the same sources.
Which explains why a disposable check returns instantly: it measures nothing. Ours reads a small built-in set rather than the public list, which is faster and narrower, and worth saying because it changes what a miss means.
The asymmetry matters. A hit is a strong signal, because somebody verified that domain and wrote it down. A miss means very little against either list, and a burner registered this week stays invisible until a person notices it.
What do verification services actually do?
They open real conversations with somebody else's mail server and abandon them.
The mechanism is documented by the mail software that implements it: probe messages are like normal mail except that they are never delivered, deferred or bounced — they are always discarded.
The same documentation warns operators about the cost, which somebody else bears: remote sites may block you for probing them too often, or for probing repeatedly for an address that does not exist, and the probes add load to the receiving server.
That is the reason this page describes the mechanism and not the commands. Checking one address you were given is ordinary. Running a list through it is somebody else's infrastructure bill and a good way to be blocked.
What question should you be asking instead?
Not whether the mailbox exists. Whether anybody has been living behind it.
The mail system is built to refuse the first question; that refusal is deliberate anti-harvesting hygiene. Consumer web services answer a different one constantly, because sign-up and reset flows have to tell a real user whether their account is there.
So an address with a decade of accounts attached tells you far more than a green tick ever could, and that is a question with an actual answer. An address with nothing behind it anywhere is the finding.
Be even-handed about the limits of that too. A profile-service miss in 576 milliseconds proves only that no profile exists on that one service, and absence in a single place is not absence everywhere.
Common questions
How can I tell if an email address is real?
Not with certainty, and the reason is in the protocol. You can check that the format is valid, that the domain has mail routing, and whether the domain is a known disposable service. Beyond that, the mail system is deliberately built not to answer, which is why every verification service is a workaround rather than a lookup.
Why can nobody verify a Gmail address?
Because the probe cannot fail there. Verification works by naming a recipient in a mail transaction and reading the response, and it only returns useful information on servers that reject unknown recipients at that moment. Our own check skips nine consumer domains outright and returns unknown at a confidence of 0.3.
What is a catch-all email domain?
A domain configured to accept mail for every address at it, usually so misaddressed messages are not lost. It is a supported feature in the major business mail platforms rather than a fault. Against a catch-all domain every probe succeeds, so a valid result tells you nothing about that particular mailbox.
Does an MX record mean an email address is valid?
No. An MX record says which host accepts mail for a domain, published by whoever controls that domain. It proves mail has somewhere to go, not that the mailbox exists or that anybody reads it. A domain registered an hour ago with correct MX records passes the check exactly as an established one does.
Are email verification services accurate?
They are accurate about what they can measure and quiet about what they cannot. Published accuracy percentages in this category are self-reported with no named method or sample, and they cannot be true for the large consumer providers or for catch-all domains, where no probe can distinguish a real mailbox from an accepted one.
How do disposable address checks work?
By looking the domain up on a maintained list. The canonical one is a public repository where contributions must cite where a throwaway address can be generated on that domain. So a hit is a strong signal because a person verified it, while a miss only means the domain has not been noticed yet.
Is it safe to send a test email to check an address?
It is contact, and it tells the recipient you are checking. It also gives away that the address is live if the person on the other end is running a scam. Verification services avoid it by opening a mail transaction and abandoning it, which shifts the cost onto the receiving server rather than removing it.
What does it mean if an address is valid but nothing else is there?
Usually that the address is new or was created for one purpose. A mailbox can be entirely real and still have no history: no accounts registered to it, no profile services answering, nothing that predates this week. For somebody vetting a stranger, that emptiness is a more useful finding than the validity.
Can I check whether an email address belongs to a real person?
You can check something more informative than mailbox validity: which services have an account registered to the address. Sign-up and password-reset flows answer that because they must, which is a different mechanism from mail delivery. An address with years of accounts behind it reads very differently from one with none.
