Greylisting is a spam-reduction technique where a receiving mail server temporarily refuses a message from a sender it has not seen before, expecting a legitimate server to retry. For cold email, where every recipient is by definition a first contact, this means a small share of first messages take longer to arrive than you might expect, even though nothing is actually wrong.
This page covers what greylisting is, how the temporary deferral and retry actually work, why it specifically affects cold outreach more than other mail, and how it differs from throttling and rate limits. It sits under our cold email deliverability guide, which covers the fuller set of causes behind slow or missing cold email delivery.
What is greylisting in cold email?
Greylisting is a server-side technique that temporarily rejects an email from an unfamiliar sender, on the theory that spam software usually does not retry while a real mail server does. RFC 6647 is the IETF's applicability statement for the practice. It describes greylisting as "providing temporarily degraded service to unknown email clients as an anti-abuse measure." The RFC is explicit that greylisting means a specific, defined mechanism, not any temporary failure for any reason.
For cold email, this matters because every message to a new recipient is, by definition, from a sender that recipient's mail server has not logged before. A legitimate cold email that a greylisting system defers is not rejected forever; it is just made to wait and prove it is willing to retry.
How does greylisting actually work for cold email?
Greylisting works by replying to an unknown sender with a temporary 4xx error instead of accepting the message. The server then tracks a combination of the sending IP, sender address and recipient address, usually called a "triplet." If the same triplet tries again after a set delay, often a few minutes, the message goes through.
- A cold email arrives at the recipient's server from a sending IP, sender address and recipient address the server has not logged before.
- The server returns a 4xx temporary failure, typically something like
450or451, rather than accepting or permanently rejecting the message. - A legitimate sending server queues the message and retries automatically, per RFC 5321's standard behavior for temporary SMTP failures.
- The receiving server sees the same triplet retry after the greylisting delay has passed, and accepts the message.
- The triplet is now known, so future mail between the same sender and recipient usually passes straight through.
Spam senders that blast mail once and move on, without any retry logic, never get past step 3. A properly configured cold email sending platform retries exactly like any other legitimate mail server, so the delay costs minutes, not days.
Why does greylisting delay first-touch cold email specifically?
Greylisting delays first-touch cold email because the entire point of cold outreach is contacting someone your sending domain has never emailed before, which is exactly the condition greylisting is built to flag. A newsletter sending repeatedly to the same list stops seeing this delay after the first message to each subscriber; cold email, by nature, keeps adding new first contacts.
The delay itself is usually a few minutes, since most greylisting implementations use short deferral windows specifically to deter spam software without meaningfully disrupting legitimate retries. For cold email, that means the first message to a given prospect may show up a little later than instantly, even on a fully warmed, properly authenticated sending domain. This is a normal side effect of outreach to new contacts, not a sign your email warm-up has failed.
How is greylisting different from email throttling in cold email?
Greylisting is a one-time deferral tied to being an unknown sender, while throttling is an ongoing limit on how fast a known sender can send, regardless of recipient history. Both show up as temporary SMTP errors, but they solve different problems and trigger under different conditions.
| Greylisting | Throttling / rate limiting | |
|---|---|---|
| Trigger | Sender, recipient and IP combination not seen before | Too many messages too fast from a sender, known or not |
| Typical code | 450 or 451 | 421, often with a 4.7.x enhanced status code |
| Resolves by | One retry after a short delay | Slowing the overall sending rate |
| Hits cold email | Once per new recipient, usually | Repeatedly, as volume grows on one mailbox or domain |
Gmail's own published rate-limit errors illustrate the throttling side: 421 4.7.28 for "Gmail has detected an unusual rate of email," per Google's SMTP error reference, opened October 2026. That code is about volume and reputation, not about being an unfamiliar sender, which is the distinction that separates throttling from true greylisting.
What causes Gmail's "421 4.7.28" rate limit error during cold email sending?
Gmail's 421 4.7.28 error fires when Gmail detects an unusual rate of email from your sending IP, domain, or DKIM signature, and temporarily rate limits it to protect its users from spam. Per Google's SMTP error reference, this single code covers several specific triggers: an unusual rate from the sending IP, from the DKIM domain, from the SPF domain, or from a URL domain appearing in the message.
This is a volume problem, not a greylisting one: it means a sending mailbox or domain is pushing more cold email than Gmail currently trusts it to send, usually because the domain is new or volume jumped suddenly. The fix is to send less, more gradually, and let sending history build before increasing volume. Our email warm-up guide covers how a new sending domain builds that history before cold sending starts.
What should you do about greylisting and throttling in cold email?
Do nothing for a true greylisting deferral beyond making sure your sending platform retries correctly, since a legitimate server resolves it automatically within minutes. For throttling, the fix is different: reduce sending volume on the affected mailbox or domain and let it build reputation gradually rather than retrying the same volume immediately.
- Confirm the sending platform retries on 4xx codes. Most legitimate SMTP software does this by default; a message that never arrives after a
450deferral usually means the retry logic, not greylisting, is the problem. - Check whether the code is a one-off
450/451or a repeated421 4.7.x. The first is likely greylisting and resolves itself. The second is a volume signal and needs lower sending volume. - Spread sends across more mailboxes rather than one. A mailbox sending a smaller, steadier volume is less likely to trip rate limits in the first place.
Pipefire runs new sending mailboxes through a warm-up period before any cold email goes out. It also watches bounce and complaint rates on every mailbox, pausing a campaign automatically if thresholds are crossed, so a mailbox never gets pushed past the volume a receiving server will tolerate.
Greylisting cold email FAQ
Does greylisting mean my cold email domain has a bad reputation?
No. Greylisting applies to any sender a recipient's server has not seen before, regardless of reputation. A brand-new, perfectly configured cold email domain and a disreputable one both get greylisted on a first contact; the difference is that only the legitimate sender's mail server retries correctly and gets through.
How long does a greylisting delay last for cold email?
Most greylisting delays last from a few minutes to around 15 minutes before a retry succeeds, though the exact window is set by the receiving server and is not standardized. RFC 6647 describes the general mechanism but leaves the specific delay up to each implementation.
Will my cold email sending platform retry automatically after greylisting?
Yes, if it follows standard SMTP behavior. RFC 5321 expects any compliant sending server to queue a message after a temporary 4xx failure and retry later, which is exactly what defeats greylisting for a legitimate sender.
What is email throttling in cold email, and is it the same as greylisting?
Email throttling is a receiving server slowing or temporarily blocking a sender's mail because of volume, not because the sender is unfamiliar. It is not the same as greylisting, though both appear as temporary SMTP errors; throttling targets sending rate, while greylisting targets first contact.
Can greylisting cause a cold email to be marked as a bounce?
Not if the sending server retries correctly. A greylisting deferral is temporary by design and resolves on retry within the delay window. It only looks like a bounce if the sending platform gives up too early or does not retry at all, which is a sending-side configuration problem rather than a true delivery failure.