Glossary
Definition
Greylisting is an anti-spam technique in which a mail server temporarily rejects a message from an unfamiliar sender with a 4xx“try again later” response. Legitimate mail servers retry after a short delay and are then accepted, while many spam tools never retry, so the unwanted mail is quietly filtered out on the first attempt.
We open millions of live SMTP conversations to verify email addresses, and greylisting is one of the most common reasons a server gives us a deliberately unhelpful answer the first time we knock. It is not an error, and it is not the server rejecting the address. It is a stalling tactic with a clever purpose, and it explains both why some good mail arrives late and why a careless tool mislabels a perfectly real address.
Greylisting lives on the receiving mail server, and it rests on a single assumption: properly behaved mail servers retry, and a lot of spam software does not. When a message arrives, the receiver looks at a triplet of facts: the sending server’s IP address, the envelope sender, and the envelope recipient. If it has never seen that exact combination before, it does not accept the message. Instead it replies with a temporary 4xx deferral, the SMTPequivalent of “try again later.”
A legitimate sending server treats that response exactly as the standard says it should. It keeps the message in its queue and retries after a configured interval, often a few minutes. On that second attempt the triplet is already on record, so the receiver accepts the message and typically allowlists the sender for a window of hours or days. From then on, mail from that sender flows straight through without the wait.
The deferral is intentionally temporary, never permanent. A 4xxcode tells the sender “this failed, but it is worth trying again,” unlike a permanent 5xx that says “stop, this will never work.” The delay is simply the gap before the sending server’s next retry, which is why two senders hitting the same server can experience very different waits.
The technique is effective out of all proportion to how simple it is. It needs no message content scanning and no reputation lookups; it only leans on that one behavioral split between compliant servers and disposable spam tools. High-volume spam is usually sent from software optimized to fire each message once and move on, so a large slice of low-effort spam never returns for the retry, and never gets in.
There is a second benefit hiding in the delay. A brand-new spam source is often unknown to blocklists for the first few minutes of its life, so forcing a wait before acceptance gives reputation services time to catch up. A sender that looked anonymous on the first attempt may already be flagged by the time it retries.
The cost of that filtering is paid by legitimate senders, as a delay on the very first message to each recipient. Most of the time it is harmless: a newsletter or a reply that lands a few minutes late is rarely noticed. The pain concentrates in transactional mail, where timing is the whole point. A password reset, a one-time login code, or an order confirmation held for fifteen minutes can read to the recipient as a broken product, even though the mail is on its way.
Greylisting also interacts awkwardly with large senders. An operator that delivers from a pool of outbound IP addresses may retry from a different IP than the one that was deferred, which changes the triplet and can restart the clock. And because a deferral is a temporary failure, it shows up in your logs as a soft bounce on the first attempt, easy to misread as a delivery problem rather than the self-clearing speed bump it usually is.
Real-time verification runs into greylisting head-on, because a verification probe opens an SMTP conversation that looks, to the receiver, just like a brand-new sender. So a greylisting server can defer the probe with the same temporary 4xxit gives anyone it has not seen before. In that instant the address is neither confirmed valid nor proven invalid; it is simply unknown, because the server has withheld its answer. A naive validator reports that ambiguity and labels the address “unknown,” a result that describes the greylist, not the mailbox.
We do not think a stalling tactic should count as a verdict, so our engine recognizes the deferral rather than taking the 4xxat face value. It honors the server’s retry expectation with a measured re-probe, the same way a legitimate sender would, so the second attempt clears the greylist and elicits a real answer. When a definitive response still is not safe to force, the result is scored with confidence instead of dropped as a shrug, so you always know whether an address carries a clean signal or a degraded one.
Handled properly, greylisting is a non-event for verification: a short, expected pause that resolves into a real answer instead of a false “unknown.” For teams verifying at scale, where a probe retried correctly is the difference between a usable list and a pile of shrugs, the volume tiers are on the pricing page.
Keep learning
Greylisting sits inside a wider set of deliverability concepts. These are the terms most worth understanding next.
A temporary delivery failure, like a full inbox or a server that is briefly down.
The protocol mail servers speak to hand a message from sender to recipient.
A domain configured to accept mail for any address, real mailbox or not.
A permanent delivery failure, usually because the mailbox does not exist.
Confirming an address is real, reachable, and safe to send to before you send.
Throwaway addresses from temporary-mail services that self-destruct after minutes.
Greylisting is handled automatically by the free email checker. Paste an address and get the resolved verdict, not a temporary deferral, in seconds. No signup.
Common questions
The questions we get most about greylisting, answered with the same logic our verification engine uses.
It is a polite “come back in a minute” from a mail server. The first time an unknown sender tries to deliver a message, the server says “try again later” instead of accepting it, then waits to see if the sender returns.
Real mail servers always retry, so the message gets through on a later attempt. A lot of spam software fires once and never comes back, so it never gets in. That single retry test is the whole idea.
When a message arrives, the receiving server records a triplet: the sending server’s IP, the envelope sender, and the envelope recipient. If it has never seen that triplet before, it replies with a temporary 4xx deferral rather than a 250 acceptance.
The sending server queues the message and retries after its configured interval. On the retry, the triplet is now known, so the receiver accepts the mail and usually allowlists that sender for a while. The handshake itself runs over SMTP.
Because it is cheap and surprisingly effective. It needs no content scanning and no reputation database; it just exploits the fact that compliant mail servers retry and most bulk spam tools do not. That one behavioral difference filters out a large share of low-effort spam before it ever reaches a mailbox.
It also buys time. During the deferral window, blocklists and reputation services can catch up to a brand-new spam source, so a sender that looked unknown on the first attempt may be flagged by the retry.
Yes, on the first message from a given sender to a given recipient. The delay equals the gap between the initial attempt and the sending server’s next retry, which can be anywhere from a minute to half an hour depending on configuration.
After that first successful delivery, the sender is usually allowlisted, so later messages flow without the wait. The recurring pain is for transactional mail like one-time codes, where even a few minutes of delay is a problem.
They overlap. A greylisting deferral is delivered as a temporary 4xx failure, which is exactly the class of response that registers as a soft bounce. So a greylisted message often shows up as a soft bounce in your logs on the first try.
The difference is intent and resolution: greylisting expects and rewards a retry, so it clears itself, while other soft bounces (a full mailbox, a server briefly down) may or may not. You can inspect raw responses with the bounce checker.
A verification probe opens an SMTP conversation just like a real sender, so a greylisting server can defer the probe with the same 4xx it gives anyone new. At that instant the address looks temporarily unknown rather than confirmed valid or invalid.
A naive validator reports that ambiguous moment as “unknown.” We treat the deferral as the signal it actually is and resolve it rather than guessing. You can see a live result on any address with the free email checker.
Our engine recognizes a greylisting deferral instead of taking the temporary 4xxat face value. It honors the server’s retry expectation with a measured re-probe, so the second attempt clears the greylist the same way a legitimate sender would.
When a definitive answer still is not safe to force, the result is scored with confidence rather than dropped as a shrug, and the full pipeline is documented on the email verification page.
You can watch for the signature: a temporary 4xx on the first delivery attempt that turns into a clean acceptance on a retry from the same sender. That defer-then-accept pattern is the tell-tale sign of greylisting at the receiving end.
Our SMTP test opens a live handshake against a server so you can see the exact response code it returns, which is the quickest way to spot a deferral in action.