What Is Greylisting in Email and Why Does Mail Get Delayed?

The short answer
Greylisting is a spam defense on the receiving mail server. It temporarily rejects the first delivery attempt from an unfamiliar sender with a 4xx error, telling it to try again later. Legitimate servers retry within minutes and get through; most spam software never retries. The first message is delayed by that forced retry.
Greylisting in email temporarily rejects the first delivery from an unknown sender, forcing a retry. That's why your first message is often delayed.
On this page
Greylisting in email is a spam-fighting technique used by receiving mail servers. When a message arrives from a sender the server has never seen before, greylisting rejects that first delivery attempt on purpose — not permanently, but with a temporary error that says, in effect, 'try again in a few minutes.' A legitimate mail server does try again, and the second attempt is accepted. The result you notice is a delay on the first message from any new sender.
The technique is defined in RFC 6647, a Proposed Standard published in June 2012. It works on one bet: most bulk-spam software fires each message once and never retries after a temporary failure, so the message never arrives. This post explains how greylisting works, why it delays password resets and one-time codes, and how it differs from an outright blocklist.
How does email greylisting work?#
Greylisting keys on a triplet — three pieces of information that identify a specific delivery attempt. RFC 6647 recommends the sending server's IP address, the envelope sender (the RFC 5321 MailFrom address), and the first envelope recipient. The 'first recipient' detail matters because legitimate mail servers do not reorder recipients between retries, so the triplet stays stable.
The first time a server sees a new triplet, it returns a temporary-failure reply — a 4yz SMTP code. RFC 6647 recommends a 450 response, or 421 if the server wants to drop the connection immediately. This is a soft rejection: it tells the sending server the message was not accepted yet, not that it was refused for good. Per RFC 5321, the SMTP standard, the sending server MUST then queue the message and retry — 'the give-up time generally needs to be at least 4-5 days' before it abandons delivery.
- 1
First contact
An unknown sender's server connects and tries to deliver. The receiver has never seen this triplet — sending IP, envelope sender, and first recipient — so it is 'grey.'
- 2
Temporary rejection
The receiver replies with a 4yz temporary-failure code (RFC 6647 recommends 450), meaning 'not now, try again later.' Nothing is delivered yet.
- 3
The wait
A legitimate sending server queues the message and waits out its own retry interval — anywhere from under a minute to half an hour or more, depending on its configuration.
- 4
Retry and acceptance
On the retry, the receiver sees the same triplet, treats it as proven, and accepts the message. Many servers then allowlist the triplet so later mail arrives without the delay.
- 5
The spam that never comes
Fire-and-forget spam software never performs the retry step. Having no second attempt, its message is simply never delivered.
Why does greylisting matter — and what breaks?#
Greylisting is cheap and, historically, effective. It rejects nothing permanently, needs no content scanning, and turns away a large share of low-effort spam before the message is ever examined. That is why many mail servers still run it.
The cost is the delay, and it lands hardest on time-sensitive mail. Password-reset links, one-time passcodes, login verification codes, and 'confirm your email' messages are usually the first mail a service ever sends you — which means they hit a fresh, un-greylisted triplet. If the receiving server holds that first attempt and the sending server's retry interval is fifteen minutes, your six-digit login code arrives fifteen minutes late, often after it has already expired.
The length of the delay is not fixed. It depends entirely on how soon the sending server retries, which greylisting does not control. A well-tuned transactional sender may retry in under a minute; a conservative queue may wait half an hour or more. This unpredictability is the practical complaint behind the search 'why is my first email always delayed.'
One-time codes and greylisting don't mix
Greylisting vs blocklisting: what's the difference?#

| Dimension | Greylisting | Blocklisting (RBL) |
|---|---|---|
| What it does | Temporarily rejects the first attempt from an unknown triplet, then accepts on retry | Rejects mail from an address, IP, or domain that appears on a blocklist |
| Reply code | 4yz temporary failure (RFC 6647 recommends 450, or 421) | 5yz permanent failure (commonly 554 or 550) |
| Does the mail get through? | Yes — on the automatic retry, usually within minutes | No — the message is refused outright, and no retry helps |
| What it targets | Software that never retries after a temporary failure | Known bad senders identified by reputation or reports |
| Main side effect | Delay on the first message from every new sender | False positives that block legitimate senders until delisted |
| Sender's remedy | Wait for the retry, or ask to be allowlisted | Request delisting from the blocklist operator and repair reputation |
| Standard / reference | RFC 6647 | DNSBL query convention; no single defining RFC |
Common misconceptions about greylisting#
Three ideas about greylisting are repeated often enough to be worth correcting directly.
The first is that greylisting still stops most spam. It is far less effective than it once was. Modern spam operations increasingly use real mail servers and botnets that retry correctly, so they pass greylisting like any legitimate sender. RFC 6647 itself notes that some spam software 'does indeed route around this technique.' Greylisting today catches the crudest fire-and-forget senders and adds friction — it is not a primary defense against a determined spammer.
The second is that a greylisting rejection means your mail was blocked. It does not. A 4yz temporary failure is a 'try again,' not a refusal. If a message never arrives after a greylisting delay, the cause is almost always that the sending server gave up retrying or has a misconfigured queue — not the greylisting itself.
The third concerns whitelisting. Recipients often ask how to whitelist a sender from greylisting. As an end user in a hosted mailbox, you usually cannot — greylisting runs on the mail server, above your inbox, and adding a contact to your address book does not change it. Whitelisting a sender past greylisting is a server-side setting, made by whoever administers the receiving mail server, typically by exempting the sender's domain or IP from the greylisting policy.
Who can actually whitelist a greylisted sender
How greylisting shows up in AI Emaily#
Greylisting is a receiving-server job that happens before a message reaches any mail client, so it is worth being clear about the boundary: AI Emaily is an email client, not a receiving mail server. We do not perform greylisting, and we cannot speed up a delay that another server's retry timing created. If your one-time codes arrive late because of greylisting, that is a setting on the mail server that accepts your mail — not something a client changes.
What AI Emaily does sits one layer up, on mail that has already been delivered. Once a message lands in your inbox, the agent triages it by urgency and context and can draft a reply in your voice, using a Personal Context brain and per-client profiles you set — not by studying your old mail. Our spam and cold-email filtering works on that delivered mail too, deciding what deserves your attention rather than gatekeeping delivery the way greylisting does. We build AI Emaily, an AI-native client for Gmail, Outlook, and any IMAP mailbox. You can see how it handles spam at aiemaily.com and start a 7-day free trial at aiemaily.com/pricing.
Frequently asked
See it in AI Emaily
Keep reading
Sources

Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.