Why SMTP Email Verification Gets It Wrong: False Valids and False Invalids

SMTP email verification goes wrong in two directions. A false valid is an address marked deliverable that bounces when you send; it is usually caused by catch-all domains, gateways that accept now and bounce later, or a verifier that skips the check. A false invalid is a real address marked dead, usually because the receiving server refused the verifier, not the mailbox. Knowing which is which tells you what to fix.

To show where each error comes from, we ran recipient probes ourselves on 7 October 2026 (UTC). Each one opened an SMTP session to the domain's mail server, gave a made-up recipient at RCPT TO, and quit. No message was sent. The made-up local part was zq8x7k2mnv41p, which nobody owns.

How an SMTP check decides

A verifier reads the server's reply to RCPT TO and maps it to a status. A 250 means the server is willing to take mail for that recipient. A 550 5.1.1 means the address does not exist. A 4xx means try later. Syntax vs MX vs SMTP checks explains where this step sits among the other checks.

The weakness is that the reply describes what the server will accept, not what will eventually be delivered. RFC 5321, section 6.1, plans for exactly that gap: "If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message." Accepting first and bouncing later is a standards-compliant design, and every false valid below is some version of it.

What we saw at the big consumer providers

Domain	Server's answer to a made-up recipient	A naive verifier would say
gmail.com	550 5.1.1 The email account that you tried to reach does not exist	Invalid (correct)
outlook.com	550 5.5.0 Requested action not taken: mailbox unavailable	Invalid (correct here)
yahoo.com	550 5.7.25 Forward-confirmed reverse DNS failed, at MAIL FROM, then disconnect	Invalid, for every address
icloud.com	550 5.7.1 [HCM2] Your mail from [our IP] was rejected	Invalid, for every address

Gmail and Outlook gave a real answer about the recipient. Yahoo and iCloud never got that far: they refused us. Our probes came from an office broadband connection with no reverse DNS, and both providers rejected it on policy grounds before evaluating the address. Had we probed a real Yahoo or iCloud address, we would have received the same rejection.

That is the most common source of false invalids.

False invalids: when the server is rejecting the verifier

A 5.7.x reply is about the sender, not the mailbox. RFC 3463 defines the middle digit 7 as "Security or Policy Status", while address problems use 1 ("Addressing Status"). A verifier that maps every 550 to invalid will throw away real Yahoo and iCloud contacts whenever its own IP is in poor standing.

Causes we see repeatedly:

• The verifier's IP fails reverse DNS or reputation checks. Our Yahoo result is the clearest case; see reverse DNS for email for what Yahoo and Gmail require of a connecting IP.
• Greylisting. RFC 6647 describes greylisting as "providing temporarily degraded service to unknown email clients", done by answering unfamiliar senders with a temporary 4xx. A verifier that does not retry later, or treats 4xx as failure, marks those addresses dead.
• Accounts that are real but unavailable. Microsoft's consumer servers return the same 550 5.5.0 for locked accounts as for closed ones, as covered in verifying Outlook and Hotmail addresses.
• Rate limiting. Probe a provider too quickly and its answers turn into deferrals or blocks that have nothing to do with the addresses.

The fix is the same in each case: read the enhanced code, not just the first digit. 5.1.x and 5.2.1 are address verdicts. 5.7.x and 4.x.x mean "no verdict", and the honest status for those is unknown or risky, with a retry from a well-configured IP.

False valids: when the server accepts everything

A server that says 250 to a recipient it has never heard of cannot confirm anyone. We probed the same made-up local part at six large company domains:

MX route	Answer to a made-up recipient
Microsoft 365 (mail.protection.outlook.com)	550 5.4.1 Recipient address rejected: Access denied
Proofpoint gateway, company A	550 5.1.1 User Unknown
Proofpoint gateway, company B	550 5.1.1 Unknown recipient address.
Company's own MX	550 #5.1.0 Address rejected.
Proofpoint gateway, company C	250 2.1.5 Recipient ok
Company's own MX	250 recipient <...> ok

Two of the six accepted an address that does not exist. Any real address at those domains would get the same 250, so the reply carries no information. Note also that three of the domains route through the same gateway product and only one accepts everything: whether a domain is catch-all depends on how it is configured, not which vendor it uses.

The main ways false valids arise:

• Catch-all domains, like the two above. A verifier detects these by probing a random address first; if that is accepted, every address on the domain should be returned as catch-all or risky. Our explainer on catch-all domains covers what to do with them.
• Accept-then-bounce gateways. Some filters accept at RCPT TO, then check the directory after the message arrives and send the bounce RFC 5321 requires. From outside, this looks the same as catch-all, and the random-address probe catches it the same way.
• Verifier shortcuts. A tool that returns valid for big providers without connecting, or that falls back to valid when the connection fails, manufactures false valids at scale. We found both in our own engine and wrote it up in how to tell if your verifier is lying.
• Time. A verification result is a snapshot. A mailbox confirmed today can be closed next month. SimpleVerifier caches a confirmed result for 14 days and re-checks after that, and any verifier's result gets less reliable the older it is.

Which error costs more

False valids cost you bounces; false invalids cost you people. Which one matters more depends on what you do with the list.

Use	Worse error	Why
Cold outreach to new contacts	False valid	Each bounce counts against a sender reputation you are still building
Customers who signed up themselves	False invalid	Deleting a real customer loses revenue and they will not notice why
Signup form validation	False invalid	Blocking a real person at signup is a lost user
Old or bought lists	False valid	Dead addresses and traps cluster in exactly these lists

For signup forms, reject only on unambiguous 5.1.x answers and let everything else through. For cold lists, send only to addresses with a positive confirmation and treat catch-all and unknown as a separate, smaller-volume segment.

Test your verifier for both errors

Five minutes and a handful of made-up addresses reveal how a verifier behaves.

1. A random string at gmail.com. Should be invalid. If it is valid, the tool is not checking mailboxes.
2. A random string at a Microsoft 365 company. Should be invalid (5.4.1).
3. A random string at a domain you know is catch-all. Should be catch-all or risky, never valid.
4. A real address you own at Yahoo or iCloud. Should be valid or unknown. If it is invalid, the verifier is misreading policy blocks.
5. Look at the reason the tool gives for each. A verifier that cannot tell you why cannot tell you which of the errors above it is making.

The free email checker shows the status and reason for one address at a time, so you can run this test against it as well as against whatever you use now.

The short version

• A 250 at RCPT TO means "I will accept this", not "this person exists". Catch-all domains and accept-then-bounce gateways turn that into false valids; detect them by probing a random address.
• A 5.7.x rejection means the server refused the verifier. Treat it as unknown, not invalid, or you will delete real contacts.
• 4.x.x is "try later". Retry before deciding.
• Results age. Re-verify a list that has sat for weeks before you send to it.