TL;DR
- Greylisting temporarily rejects (
4xx) the first attempt from an unknown sender and accepts a later retry. - It works because legitimate servers queue and retry, while much spam software never does.
- For verification, a
4xxis not a yes or a no. We retry after a wait and, if it is still deferred, return unknown, which is refunded.
The short definition
RFC 6647 describes greylisting as "the practice of providing temporarily degraded service" to unknown email clients as an anti-abuse mechanism (RFC 6647, checked 2026-10-18). In practice the server remembers who tried, answers with a temporary failure, and accepts the same sender when it comes back later.
How it works
- A server connects that the receiver has not seen before. The receiver records the tuple of the sender's IP, the MAIL FROM address and the first RCPT TO address (RFC 6647 recommends this combination).
- It answers with a transient error, for example
451 4.7.1 Greylisted, please try again later. - A real mail server queues the message and retries. The RFC suggests accepting a retry that arrives inside a window of roughly one minute to 24 hours.
- After a matching retry, later mail from that sender is let through without delay.
RCPT TO:<[email protected]> → 451 4.7.1 Greylisted, try again later
(wait, reconnect)
RCPT TO:<[email protected]> → 250 OKThe wording of the reply varies by server. The 4xx class is what signals "temporary" (see bounce codes and hard vs soft bounces).
Why it matters for senders
Greylisting delays the first message to a new recipient domain, usually by minutes, sometimes longer. It does not bounce it, provided your sending server retries as it should. Cold-email tools that fire once and give up can lose these messages. If you see a delay only on your first send to a domain, this is a likely cause.
Greylisting and email verification
A verifier is also a first-time sender, so it can be greylisted. The temporary reply says nothing about whether the mailbox exists, and a verifier that calls it "invalid" or "valid" is guessing. Here is what we do (how it works):
| What the server said | Our result |
|---|---|
Temporary 4xx on the first pass | retried after a wait, in a later pass |
| Accepted on the retry | normal result (deliverable, risky or undeliverable) |
| Still temporary after the retry | unknown: unavailable_smtp (refunded) |
Our code keeps each domain to one session at a time and defers greylisted domains to a later pass, so a slow server doesn't hold up the rest of your file. Statuses are explained in email verification statuses.
Unknowns are refunded and credits never expire (pricing), so a greylisted address costs you nothing to re-check later.
Sources
- RFC 6647, Email Greylisting: checked 2026-10-18
Common questions
What is greylisting in email?
A server temporarily rejects mail from a sender it hasn't seen, with a 4xx code, and accepts it when the sender retries later.
Does greylisting cause bounces?
Not if your sending server retries. It delays the first message. A server that never retries can lose the message.
How does greylisting affect email verification?
A 4xx reply is not a verdict on the mailbox. We retry after a wait and return unknown, refunded, if the server still defers.