Greylisting is an anti-spam technique in which a receiving mail server temporarily rejects a message from an unfamiliar sender, expecting the sending server to retry a few minutes later. Legitimate mail servers retry automatically; most spam software does not bother. The result is that first messages from a new sender can arrive several minutes late, which is why a verification code sometimes seems to vanish before it appears.
How does greylisting actually work?
The idea is old and simple. When a message arrives, the receiving server looks at three things: the sender's IP address, the envelope sender address (the one used in the SMTP conversation, not necessarily the visible From header), and the recipient address. That combination is called a triplet. If the server has not seen that triplet before, it replies with a temporary rejection — an SMTP 4xx code, usually 450 or 451 — rather than accepting or permanently bouncing the message.
A temporary rejection is a request to try again. Well-behaved mail servers queue the message and retry after a delay. Once the retry arrives, the triplet is now known, the message is accepted, and the sender is added to a local record so future messages skip the delay. Spam tools, by contrast, often fire once and move on; a retry costs them time and resources, so many simply give up.
Two details matter for understanding delays. First, the retry schedule is set by the sending server, not the receiving one. Common mail transfer agents retry after a few minutes and then back off progressively. Second, the record of a known triplet eventually expires — often after a day or a few weeks — so a sender you hear from rarely can be greylisted again on the next contact.
Why is the delay usually minutes, not seconds?
Because the receiving server does not control when the retry comes, greylisting is deliberately imprecise. A sender that retries quickly might get through in a couple of minutes; a sender with a cautious retry policy might take much longer. This variability is normal, and it is one reason greylisting is often combined with other filters rather than used alone.
Why did my verification code arrive late?
If you have just requested a one-time code from a service you have never used before, the first message is exactly the kind of mail greylisting is designed to slow down: a new sender, a new recipient, no history. The sending domain may retry within a few minutes and the code lands fine. But if the code has a short validity window, the delay can be enough to make it useless by the time it appears.
Several things make this worse:
- Short code lifetimes. Many services expire codes after ten or fifteen minutes. A greylisting delay of several minutes eats into that budget.
- No retry from the sender. Some application mail senders are configured to attempt delivery once. If that attempt is rejected temporarily, the message is dropped rather than queued.
- Shared sending infrastructure. Codes from large platforms often come from pooled IP ranges that change frequently, so the triplet is new more often than you would expect.
- Disposable inboxes with short lifetimes. If your inbox itself expires quickly, a delay of several minutes can mean the code arrives after the address is gone.
None of this is a fault in your inbox. It is a timing collision between a spam filter and a time-limited message.
What should I do when a code is slow?
First, wait. Give it at least five to ten minutes before assuming failure, and resist the urge to request a new code immediately — that may just create another greylisted message and reset the clock. If the code arrives after it has expired, request a fresh one; by then the sender's triplet is usually known and the second message should pass without delay.
If nothing arrives at all, work through the usual checks:
- Confirm the address you typed is exactly right, including any subdomain.
- Check whether the service has a resend button and use it once, not repeatedly.
- Look at whether the sending domain publishes SPF, DKIM and DMARC records — misconfigured senders are more likely to be filtered heavily. Our guide to SPF, DKIM and DMARC explains what those records do.
- If you are using a disposable inbox, check its remaining lifetime before waiting further.
For a fuller checklist, see Verification Email Not Arriving? 10 Things to Check, in Order. If the message is being filtered as spam rather than delayed, Why Verification Emails Go to Spam covers the other common causes.
Greylisting versus other anti-spam filters
Greylisting is one layer in a stack, and it behaves differently from its neighbours. The table below sets out the practical differences.
| Filter | What it does | Typical effect on you |
|---|---|---|
| Greylisting | Temporarily rejects mail from unknown triplets | First message from a new sender is delayed |
| Content filtering | Scores the message body, links and attachments | Spam may be quarantined or marked |
| Reputation filtering | Judges the sending IP and domain history | Mail from new or tainted infrastructure is blocked |
| Authentication checks | Verifies SPF, DKIM and DMARC alignment | Forged mail is rejected or flagged |
Because greylisting only delays, it is one of the gentler filters. It does not read your message content, and it does not permanently reject anything that retries properly. Its weakness is that it penalises slow or one-shot senders, which occasionally includes legitimate application mail.
Does greylisting still work today?
It works, but it is less decisive than it once was. Spam infrastructure has adapted, and many bulk senders now retry like legitimate servers. For that reason, greylisting is usually deployed alongside authentication checks and reputation data rather than as a standalone defence. Whether a particular provider uses it, and with what delays, varies and changes over time — there is no universal schedule to quote.
When a delayed code is more than an annoyance
Greylisting is a plausible explanation for a slow first message, but it is not the only one, and it is not an excuse to cut corners on security. If a code arrives very late, treat it as expired unless the service says otherwise. Do not reuse an old code, and do not forward codes to anyone, including people who claim to be support staff.
If you are receiving codes in a disposable inbox, the timing question is worth thinking about in advance. An inbox that lives for sixty minutes gives you room for a greylisting delay; one that is about to expire does not. Our piece on how long temp mail lasts explains the timers and extensions, and How OTP Verification Works covers the wider mechanics of one-time codes.
Delay is not the same as failure. A greylisted message is usually on its way; a message that never retries is not.
What greylisting means for developers
If you send transactional email — signup confirmations, password resets, one-time codes — greylisting is a design constraint you should plan for. Three practical points stand out.
- Retry properly. Make sure your sending path queues and retries on 4xx responses. A sender that treats a temporary rejection as final will lose mail to every greylisting server on the internet.
- Give codes a realistic lifetime. If your codes expire in five minutes, some users on greylisted paths will never succeed. A longer window, combined with rate limiting and single-use codes, is usually the better trade-off.
- Test the unhappy path. Simulate temporary rejections in your test environment rather than only testing the happy path. Our guide to testing signup and verification emails walks through the setup.
It also helps to understand what your own receiving side is doing. If you run a mail server and are considering greylisting, note that it will delay first contact from every new sender, including customers and partners. Many operators whitelist known-good senders or apply greylisting only to suspicious connections for that reason.
Sources
- Postfix postconf documentation (documents SMTP response handling and the delay-related settings in a widely used mail transfer agent)
- Postfix overview documentation (describes the queue manager and retry behaviour that makes greylisting work)
- Microsoft Exchange mail flow best practices (vendor guidance on sender authentication and delivery behaviour)
The bottom line
Greylisting is a temporary rejection filter: it asks unfamiliar senders to try again later, and most spam does not. That is why a first message from a new sender can lag by several minutes while later messages arrive instantly. If a verification code is slow, wait a few minutes, request a single resend, and make sure the code has not expired before you use it. If you are sending codes yourself, build in proper retries and a lifetime that survives a delay.