Can I see which verification provider was used for each email?

Every verification result in Valid Email Checker is tagged with the provider that actually produced it. The current providers are Reoon and EmailListVerify; both are routed through the fallback wrapper which automatically selects the right provider for each address.

Where the provider tag surfaces

• In the verification_results table that backs your dashboard, every row has a provider column with the name of the provider that produced that specific result.
• In bulk task CSV exports, the provider appears as a column you can include in the export. See downloading your results.
• In the API response on the single-verification endpoint, the provider is not exposed by default but is logged internally and can be surfaced for support diagnostics on request.
• In your Credits History, transactions are not provider-tagged (they record the credit movement, not the verification details), but each transaction links back to a verification row where the provider is available.

Why both providers can appear in a single bulk task

A bulk task runs the entire list through one provider initially (the configured primary). Any addresses that returned Unknown from the primary get re-verified through the secondary in the optional second-pass. The second-pass results are tagged with the secondary provider; the rest stay tagged with the primary. So a single bulk task can have results from both providers, and the breakdown is visible in the CSV export.

For single verifications, the same logic applies but on a per-address basis. The primary handles most addresses; the secondary handles the addresses where the primary returned Unknown or failed. Each result is tagged with whichever one actually produced the verdict.

Why the provider matters for diagnostics

Most customers do not need to know which provider produced a result — the status enum is the same across providers, the confidence score is normalised, and the bounce-rate behaviour you get from sending is the same. The provider tag matters mostly for two cases:

• Diagnostics when a result looks off. If you suspect a specific result was wrong, knowing which provider produced it helps support trace the underlying provider call and explain the verdict.
• Curiosity about fallback behaviour. If you ran a bulk and noticed a chunk of results tagged with the secondary provider, that tells you those addresses needed fallback — which is normal and not a problem, just an observable signal.

What you cannot control

Provider selection is automatic. There is no API parameter or dashboard toggle to force one provider over another, and there is no way to skip the fallback path. The reasoning matches the fallback design: letting customers select providers would let abuse patterns target specific weaknesses, and the engine is designed to route automatically for the best aggregate accuracy.

The admin team can swap which provider is primary versus secondary, and can adjust the fallback parameters in system_settings. Customers see the change as slightly different per-provider tag distributions; the canonical status enum and confidence scoring stay constant.

For API users and developers

The single-verification API endpoint returns the canonical status and confidence score without exposing the provider name in the default payload. If you need provider-level visibility for analytics or debugging, contact support — the data is logged and we can expose it on the response for your account if you have a real reason. For the broader API reference see how to verify a single email with the API.