How greylisting works
When a receiving server sees mail from a sender/IP combination it hasn’t seen before, it returns a temporary SMTP error — a 4xx code in RFC 5321, typically 450 or 451 — instead of accepting or rejecting outright. Legitimate mail servers are built to retry after a delay (often minutes), while most spam-sending infrastructure does not bother retrying, so it never gets through.
Why greylisting matters for email verification
A verification check that only attempts a single SMTP connection can be fooled by greylisting into reporting “unknown” or a temporary failure for a perfectly valid address, simply because the receiving server hasn’t “warmed up” to the sending IP yet.
How to handle greylisting in a verification pipeline
Retrying SMTP checks with appropriate delays, and using a distributed set of sending IPs with established reputation, reduces false “unknown” results caused by greylisting. A verification pipeline that gives up after one attempt will systematically misclassify a slice of valid addresses on greylisting-enabled domains as unknown.
Greylisting vs. rate limiting
They’re often confused but distinct: greylisting is a one-time “prove you’ll retry” test tied to a specific sender/recipient/IP triplet, while rate limiting throttles how many connections a given IP can make in a time window regardless of retry behavior. A verification fleet needs to handle both.