What does verifying through fallback providers mean?

Every Valid Email Checker verification goes through a primary verification provider first. If the primary returns a definitive status (Safe, Invalid, Disposable, and so on), the result is returned and the verification is done. If the primary returns Unknown or throws an error, the engine routes the same request through a secondary provider. The result the customer sees is whichever provider gave a definitive answer.

The mechanic is implemented in the verifySingleWithFallback function in our shared provider code. The primary and secondary are configured by the VEC admin team — currently Reoon and EmailListVerify are the active providers. Which one is primary versus secondary can be swapped without any change to customer-side behaviour.

How the fallback decides when to fire

1. Call the primary provider. If the response maps to a definitive DB status, return that result and stop. The primary handles around 90% of verifications without needing the fallback.
2. If the primary returns Unknown (or its provider-specific equivalent like EmailListVerify's smtp_protocol or antispam_system no-charge statuses), trigger the fallback.
3. If the primary throws (rate-limit, network failure, provider downtime, low account balance), trigger the fallback.
4. Call the secondary provider with the same email. If the secondary returns a definitive status, use that and mark the result with fallbackTriggered = true.
5. If the secondary also returns Unknown or also fails, return whichever result we have. The caller then issues a credit refund because the final status is Unknown.

Why two providers instead of one

Each provider has its own sending IPs, its own connection history with various recipient domains, its own anti-probe defences it can deal with cleanly, and its own gaps. An address that triggers an anti-probe block on Reoon can verify cleanly through EmailListVerify and vice versa.

A single-provider verifier has a structural ceiling on accuracy — every probe block or timeout on that one provider becomes an Unknown result. A dual-provider stack roughly halves the Unknown rate by catching the cases where one provider fails but the other succeeds. That gain is what pushes the engine above the 99%+ threshold rather than the 95% to 97% range that single-provider verifiers typically hit.

How fallback affects credits and timing

A fallback verification uses one credit, just like a non-fallback one. The customer never pays double when the engine has to go through both providers. If the result ends up Unknown anyway (both providers failed), the auto-refund returns that one credit.

Timing is the trade-off. A clean primary verification finishes in 2 to 6 seconds. A fallback verification takes longer — typically 8 to 15 seconds — because the engine ran the primary, waited for its Unknown or error, then ran the secondary. From the customer side, the spinner just runs a bit longer; the result is the same definitive answer.

Bulk second-pass: a related but different mechanic

For bulk verifications, fallback works slightly differently. The engine runs the entire bulk through one provider first, then optionally re-verifies the Unknown subset through the other provider in a second pass. The second pass is capped at 25% of the list (configurable in system_settings.max_bulk_secondpass_pct) and 50 addresses synchronously, to avoid runaway costs and timeouts on very large bulks. See how fast is bulk verification for the broader bulk pipeline.

What customers do not control

Provider selection is automatic. There is no API parameter to force a specific provider or skip the fallback. The reasoning: forcing one provider over another would let abuse patterns target specific provider weaknesses, and the engine is designed to maximise accuracy by routing where the best answer is most likely. The exception is if you have a specific support reason to debug a result — contact support and the engine logs can show which provider produced the verdict.