How does VEC handle greylisting during verification?

Greylisting is an anti-spam technique where a mail server temporarily refuses the first connection from any sender it does not recognise, then accepts the retry. The idea is that real mail servers retry; spam bots usually do not. For email verification this creates a problem, because a probe from a verification provider looks unfamiliar by definition.

Valid Email Checker handles greylisting at three layers — at the provider connection, at the engine logic, and at the fallback wrapper. Each layer kicks in at a different stage of the verification.

Layer 1: provider-side retry

Both verification providers we route through (Reoon and EmailListVerify) include their own greylisting retry logic. When a recipient server responds with a 4xx temporary error code (421, 451, 452 are the common ones), the provider waits a configured backoff window — usually a few minutes — and retries. Most greylisting servers accept the second connection because they have now seen the sender once and decided it is probably real.

This layer handles the vast majority of greylisting cases without involving the engine logic. The verification just takes a few minutes longer instead of the usual seconds.

Layer 2: engine fallback to the secondary provider

When the primary provider returns Unknown because greylisting persisted past its retry window, the engine routes the call to the secondary provider through the fallback wrapper. The secondary often uses a different sending IP and a different sender history, so the greylisting decision at the recipient server can land differently.

In practice this catches another big share of greylisting cases. An address that returned Unknown through the primary now comes back as Safe or Invalid through the secondary, and the customer sees a definitive result with fallbackTriggered = true marking it as a fallback completion.

Layer 3: Unknown auto-refund

When both layers fail to break through greylisting (rare, but real), the result comes back as Unknown and the credit auto-refunds. The customer is not charged for an answer the infrastructure could not deliver. See the Unknown auto-refund for the mechanic.

For high-stakes addresses you can also re-verify the next day or the day after, when the greylisting window at the recipient server has expired and the same sender IP is recognised. See why does the same email return different results on different days.

Why greylisting is hard to solve completely

• Some greylisting servers use multi-day windows. A retry an hour later still looks unfamiliar.
• A few servers combine greylisting with anti-probe defences that refuse even the retry, returning the same temporary error indefinitely.
• Greylisting policy is per-server-pair, not per-server. A recipient that accepts mail from Reoon may still greylist EmailListVerify, and vice versa.
• Some servers degrade gracefully from greylisting (accept on retry) and others do not (keep rejecting). The behaviour is not standardised.

The honest answer is that greylisting is one of the categories where 100% accuracy is mathematically impossible. The combination of provider-side retry plus fallback provider plus Unknown refund is what keeps VEC at 99%+ on greylisted addresses overall — but each of those layers has a failure mode, and the system reports Unknown rather than guessing when all three give up.

See also

For the underlying concept see what is greylisting. For why a verification might fail with timeout see why did verification fail with provider timeout.