Definition
Greylisting: An anti-spam technique where a server temporarily rejects mail from an unfamiliar combination of sending IP, sender and recipient with a 4xx reply, then accepts it when the sender retries after a delay. During verification it can delay or block a definitive answer.
How greylisting works
The server records three values for each delivery attempt: the connecting IP, the envelope sender and the recipient. A combination it has never seen gets a temporary rejection.
When the same combination comes back after the minimum delay, the server accepts it and remembers it, so later messages from that sender go straight through. RFC 6647 describes the technique and its tradeoffs.
What greylisting replies look like
Most greylisting replies use 450 or 451 with an enhanced code of 4.2.0 or 4.7.1, and many say so in plain words: greylisted, please try again later.
The key part is the 4. It marks the failure as temporary, so a correctly behaving sender keeps the message queued and retries.
How greylisting affects email verification
A verifier's first RCPT TO to a greylisting server gets a 4xx, which says nothing about whether the mailbox exists. Getting a real answer means coming back later from the same IP with the same sender.
A verifier that treats that first 4xx as invalid deletes real contacts. One that treats it as valid lets bad addresses through. The right move is to wait and retry.
C: RCPT TO:<maria@example.com>
S: 450 4.2.0 <maria@example.com>: Recipient address rejected: Greylisted, please try again later
(about 10 minutes later, same IP and sender)
C: RCPT TO:<maria@example.com>
S: 250 2.1.5 OKHow RocketVerifier handles it
A greylisted check is retried automatically, up to 3 times about 10 minutes apart, and a stalled bulk job is moved to another verification node. If the server is still deferring after the retries, the address comes back as unknown with sub_status greylisted and is never charged. A greylisting reply is never read as undeliverable, because it says nothing about the mailbox.