Greylisting

How a later attempt may pass

Greylisting records an unfamiliar SMTP attempt and defers it with a temporary 4xx reply. The server may use the connecting source, envelope sender and recipient to recognise a later attempt. RFC 6647 describes these policies.

Once the configured delay has elapsed, a recognised retry may pass the greylisting rule. Other server checks still apply. There is no universal waiting period or guarantee of acceptance on the second attempt. If the source or envelope details change, the server may treat it as a new attempt.

What the verification result means

A reply such as 451 indicates a temporary failure, but its number does not identify the cause. Server load and SMTP throttling can produce similar replies. Emvero uses SMTP_GREYLISTED for an observation classified as greylisting and SMTP_TEMPORARY_FAILURE for a general temporary SMTP failure.

If no other evidence determines the result, a greylisted probe returns unknown with allow_with_email_confirmation. The deferral supplies no basis for an undeliverable result. Emvero sends no email and stops before DATA, so it cannot observe greylisting applied only at the message-content stage.

Waiting for a check or starting another

When the response is pending, retrieve the same check after retry_after_ms. A completed unknown has finished; decide separately whether to start another check later. That check may use cached evidence and may encounter another refusal. The verification result guide explains the distinction.

At signup, your application can send confirmation to establish access. For a list, keep the reason while deciding whether to hold or recheck the address; see unknown versus undeliverable. A verification retry gathers evidence, whereas a sending server’s retry attempts to deliver an actual message.