What is a greylist delay?

The server records a triplet of sending IP, envelope sender and recipient, then rejects with a 4xx. It accepts the same triplet after the delay has elapsed, and usually remembers it for weeks afterwards.

Retry timing decides what the user experiences. A platform that retries in one minute clears a five-minute delay on the fifth attempt; one that waits fifteen minutes between tries turns it into a quarter of an hour.

For a password reset that delay is the difference between working and not. It is one reason transactional mail belongs on infrastructure with aggressive retry behavior.

For verification the delay has to be waited out rather than reasoned around. A single-pass verifier that never returns sees only the rejection, and calling that invalid is a false negative on a perfectly good address.

Postgrey is a common greylisting add-on for Postfix, and its defaults make a useful example. At 10:00:00 your server offers a message for lee@smallfirm.example. The reply is 450 4.2.0 Recipient address rejected: Greylisted, and Postgrey records your IP, your envelope sender and the recipient.

The default delay is 300 seconds. If your server retries at 10:02, it gets the same 450. A retry at any point after 10:05 is accepted. From then on that combination passes straight through, and the entry is kept for 35 days after it was last seen. Once a sending host has delivered five messages successfully, Postgrey whitelists the host and stops delaying it at all.

Large senders hit a wrinkle here: if the retry comes from a different IP in the pool, it can look like a new triplet and restart the clock. Postgrey softens this by matching on the first three octets of the address by default, so neighbors in a /24 count as the same sender.

A verifier faces the same rule as any sender. To get past the delay it has to come back after the waiting period, from the same IP range, using the same envelope sender it used the first time. One that returns from a different address each time will never clear it.

That sets a floor on speed. A greylisted address can't be resolved in under the server's delay, which is usually several minutes. Bulk jobs can afford that by setting the address aside and returning to it later in the run. Live checks on a signup form can't, so the only honest real-time answer for a greylisted address is unknown, followed by a background re-check.

This is worth testing when you compare services. Put a few addresses you control behind a greylisting server and submit them for the first time. A result of valid within a second or two tells you the tool isn't waiting, which means it's inferring.