Short answer: Two things can cause this: caching (a repeat check may return a stored result) and transient server conditions (a temporary unknown can resolve to a real answer on a later attempt). A force-refresh request always runs a fresh live check.
Caching
To keep verification fast and to avoid hammering mail servers, confirmed results are cached for about 24 hours. If you verify the same address again within that window, you may receive the cached result rather than a brand-new live check โ and you won't be charged again for it. This keeps repeat lookups instant.
One exception: unknown results are not cached. Because "we couldn't confirm this" is a temporary answer, re-checking an unknown address always runs a fresh live verification โ which is exactly why an unknown can turn into a definite result on a later attempt.
To force a brand-new live verification that ignores the cache, send the request with force_refresh=true. A force-refresh performs a real check and is billed according to its new result.
Transient conditions
Some earlier unknown results are caused by temporary conditions on the receiving side:
- Greylisting โ the server deliberately defers the first attempt and accepts a later one.
- Rate limiting โ the provider was throttling traffic at that moment.
- Timeouts โ the server was briefly slow or unreachable.
When you re-check later, those conditions may have cleared, so a previous unknown can become a definite valid or invalid. This is expected behavior, not an inconsistency.
What we recommend
- For a definitive, up-to-the-second answer, use
force_refresh=true. - If you are batch-verifying a list, there is no need to force-refresh every address โ cached results are accurate within their freshness window and save you credits.
- A result flipping from
unknownto a definite status on retry is a good sign: it means the temporary condition cleared and we got a real answer.