Why Does the Same Email Get a Different Verification Result on a Re-Check?

The same address can come back valid on Monday and risky or unknown on Tuesday because a verifier does not hold the answer. It asks the recipient's mail server whether the mailbox exists, and that server's reply changes with load, with anti-abuse rules, and with who is asking. Most flips are in the uncertain middle (greylisting, rate limits, catch-all detection, providers that refuse checks). A genuine valid-to-invalid flip is less common and usually means the mailbox was deleted or disabled. Read the reason behind each result, retry the unknowns later, and trust explicit rejections over everything else.

What a verifier actually asks

An SMTP check connects to the domain's mail server, starts a mail conversation, names the recipient, and listens to the reply. Nothing is sent. The server can say:

• 250 OK: it would accept mail for that address.
• 550 5.1.1 or similar: no such user. That is an explicit rejection.
• 4xx: try later. This is greylisting, rate limiting or a temporary problem.
• Nothing useful: a timeout, a dropped connection or a refusal to talk to the checking server.

Then the verifier asks about a random address that cannot exist. If the server says yes to that too, the domain is catch-all (accept-all) and its yes for the real address proves nothing.

Every step depends on the server's behaviour at that moment. So the result is a snapshot, not a fact stored somewhere.

Seven reasons the same address flips

Cause	What you see	Which result to trust	What to do
Greylisting	Unknown first, valid on a later retry	The later, explicit answer	Retry after a few hours
Rate limiting or throttling	Unknown or timeout during a big run, fine on a small re-check	The explicit answer	Re-check unknowns in a smaller batch later
Catch-all detection flips	Valid one day, risky (catch-all) the next	Risky	Treat the domain as catch-all
Provider refuses checks from a network	Risky or unknown at one tool, valid at another	Neither is proof	Send carefully, or route separately
Mailbox really changed	Valid, then invalid weeks later	The newer invalid	Suppress the address
MX failover or gateway	Valid via one server, catch-all via a backup	Risky	Check the MX records
Cached or stale result	Re-check returns the old answer instantly	Depends on age	Check the result date

1. Greylisting

Some servers reject the first attempt from an unfamiliar sender with a temporary 4xx code, expecting a real mail server to come back later. A verifier that tries once reports unknown; one that retries later gets the real answer. If your first run said unknown and the second said valid, greylisting is the usual reason, and the second answer is the better one.

2. Rate limits during a big run

Verifying 20,000 addresses at one company or one provider looks, to the receiving server, like a lot of probing in a short time. It may start answering with temporary refusals or stop answering at all. Re-check the same address alone a day later and it answers normally. The address did not change. The load did.

3. Catch-all detection that depends on the try

Catch-all detection rests on how the server treats a made-up address. Some servers do not answer consistently. They accept the random address on one connection and reject it on another, or their admin changes the setting. So a domain can look like it rejects unknown users on one run (and your address comes back valid) and look catch-all on the next (and it comes back risky). When you see that flip, treat the domain as catch-all. The cautious answer is the honest one. Our catch-all checker shows how a domain answers right now.

4. Providers that refuse or hide checks

Some mailbox providers limit or refuse SMTP checks from some networks, or reject missing users only after a message is sent, where a check cannot see it. A tool on one network may get an answer that a tool on another network does not. Yahoo and AOL document their missing-user error as a reply to the message itself, so a mailbox check cannot confirm them (see why Yahoo addresses are hard to verify). Microsoft's consumer service (Outlook.com, Hotmail, Live, MSN) is currently refusing checks from our server's network, so we report those mailboxes as risky instead of guessing. See why Outlook leads come back risky.

5. The mailbox really changed

People leave companies, accounts are disabled, inboxes fill up, and companies migrate providers. A valid result from three months ago and an invalid result today are probably both correct for the day they were made. This is why old results should be re-verified before a new campaign. See how often to verify an email list.

6. Backup mail servers and gateways

A domain can list several MX servers. The primary may check recipients properly while a backup accepts everything and sorts it out later. If the primary is slow or down during one run, the check lands on the backup and the address looks catch-all. Security gateways can behave the same way. Look the domain up with the MX lookup to see what is in front of it, and read verifying emails behind security gateways.

7. Cached results

Many verifiers cache recent results so a repeat check is fast and not charged again. That is useful, but it means a "re-check" a few days later may be the old answer, not a new probe. SimpleVerifier caches mailbox results for 14 days, then deletes them, as described on our security page. If you need a fresh probe of something you checked last week, the cache is the first thing to know about.

How to tell which answer to trust

Rank the evidence, strongest first:

1. Explicit rejection of the mailbox (550 5.1.1, 550 5.4.1 at Microsoft 365, "user unknown"). Strong. Trust it, even over an older valid.
2. Explicit acceptance at a domain that rejects made-up addresses. Strong, for that day.
3. Acceptance at a catch-all domain. Weak. The server says yes to everything.
4. Temporary refusals and timeouts. No evidence about the mailbox at all.

So when two runs disagree, ask which run had the stronger reply, not which is newer. A rejection that arrives after a valid usually means the mailbox went away. A valid that arrives after a timeout just means the second try got through.

The single email checker shows the reason for one address. For two whole result files, the verifier comparison tool lists every row where they disagree and the likely cause.

What a consistent verifier should do

Flips cannot be removed, because they come from the receiving servers. A trustworthy tool handles them honestly:

• It gives a reason, not just a status. "Mailbox does not exist" and "server timed out" should never collapse into the same word.
• It separates "risky" from "could not check". One means the server answered but could not confirm. The other means no usable answer. See accept-all vs unknown results.
• It never promotes uncertainty to valid. If a domain looked catch-all on any attempt, calling the address valid is a guess.
• It retries before giving up. Greylisting is designed to be beaten by patience.

If a tool's valid file keeps bouncing, the problem is usually that it called catch-alls or unconfirmable addresses valid, not that it flipped. Our post on false positives in SMTP verification covers that failure in detail.

A practical routine for flipping results

1. Keep the reason column when you export. You need it to judge each flip.
2. Re-check unknowns a few hours to two days later, in a smaller batch than the first run.
3. Treat any catch-all flip as risky and send it as a separate, slower segment. See what to do with catch-all emails.
4. Suppress any address with an explicit rejection, whatever earlier runs said.
5. Re-verify results older than about a month before they go into a new sequence.
6. Test fairly if you are comparing tools: same list, same day. Our bench test guide explains why running tools a week apart produces fake disagreements.

Where SimpleVerifier fits

SimpleVerifier gives every row a status and a reason: safe to send, send with care, check again later, or do not send. Catch-alls and anything a server will not confirm stay risky, never valid, so a re-check can move an address from "check again later" to a firmer answer, but uncertainty is not dressed up as confidence. Addresses we could not check are not charged.

The first 100 checks are free with a Google sign-in on the verify page. Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off, so re-running the unknowns does not add per-email cost. See pricing.