Greylisting: What It Looks Like in a Live Campaign
Greylisting temporarily refuses mail from a sender, address and recipient combination a server has not seen before, using a 4xx response, and accepts it on retry. Legitimate senders retry automatically, so nothing is lost. What it costs is time, concentrated entirely on the first message to each recipient.
Key takeaways
- The response is a 4xx temporary failure, so the message is delayed rather than refused.
- Delay lands on first contact, which for cold outbound is every message that matters.
- Sending from a pool of outbound addresses can restart the check and lengthen the delay.
- The damaging reaction is raising send rate to catch up, which invites real throttling.
Greylisting is a spam-reduction technique in which a receiving mail server temporarily refuses a message from a sender it does not recognise, using an SMTP temporary-failure response, and accepts it when the sender tries again after a short delay. The reasoning is that a legitimate mail server queues and retries as the protocol requires, while much bulk-sending software of the era simply moved on. It is described in RFC 6647, which is an applicability statement rather than a protocol: greylisting is a local policy built on ordinary SMTP behaviour, not a standard anyone implements identically.
The identifying detail is the response code. A greylisting server answers in the 4xx range, meaning "not now, try later", rather than the 5xx range, meaning "never". Your sending platform reads that as a deferral, holds the message, and retries. Nothing is lost, and nothing is reported to you as a failure.
What actually happens, and what gets remembered
A greylisting server records a triplet: the connecting IP address, the envelope sender, and the recipient. On first sight of a combination it has not seen before, it returns a temporary failure. It notes the time. If the same triplet returns after a configured minimum delay, often a few minutes, the message is accepted and the triplet is added to a list of known-good senders for a much longer period, typically weeks.
Three behaviours follow, and they explain nearly everything people notice.
The first message to any recipient is delayed, and later ones are not. Once the triplet is trusted, subsequent mail passes straight through. Delay concentrates entirely at first contact, which for cold outbound is every message that matters.
The delay is unpredictable and can be long. The floor is set by the receiver's minimum wait; the actual delay is set by your sending platform's retry schedule, which may be five minutes or may be an hour. Two systems each behaving correctly can produce a two-hour gap between send and delivery.
A sender that varies its outbound IP restarts the clock. The triplet includes the connecting address. Mail leaving from a pool of addresses can present a new triplet on each retry, so a message can be deferred repeatedly and take much longer than the receiver intended. This is a genuine interaction between a common sending architecture and a common receiving policy, and neither side is misconfigured.
- Step 1First attempt
The server sees an unknown IP, sender and recipient triplet and answers with a 4xx temporary failure.
- Step 2Queue
The sending platform holds the message and schedules a retry. Nothing is reported as a failure.
- Step 3Retry
After the receiver's minimum delay has passed, the same triplet is accepted.
- Step 4Remember
The triplet is trusted for weeks, so later mail on the same path is not delayed.
Where the textbook definition misleads
Greylisting has not blocked your campaign. It defers. If mail is genuinely missing rather than late, greylisting is the wrong suspect, because a greylisted message that is retried arrives. The characteristic symptom is a campaign that took far longer to complete than it should have, not one that lost messages.
The delay is invisible in most reporting. Sending platforms treat deferrals as an internal retry rather than an event worth surfacing. From the dashboard the campaign simply sends slowly. Teams routinely read that as a scheduling problem or a throttle they set themselves, and never learn that a chunk of the list is behind a receiver that wanted a second attempt.
Its effectiveness against actual spam has fallen a long way. The technique worked because bulk software of the time did not retry. Modern sending infrastructure, including the infrastructure spammers use, queues and retries correctly. What remains is a delay applied to every unfamiliar sender, which is why greylisting is far less common as a standalone defence than it was and now usually appears as one component inside a larger filtering product.
It interacts badly with time-sensitive mail. Password resets, verification codes and anything else where minutes matter are the classic casualties, which is why many implementations exempt transactional streams. It is worth knowing this if you ever wonder why the same recipient domain delays your outbound and not your product's login emails.
It says nothing about your reputation. A greylisting deferral is a policy applied to unfamiliar triplets, not a judgment. Reading it as a signal that a domain is in trouble points remediation at a problem that does not exist.
Not every 4xx is greylisting, and the ones that are not deserve attention. Rate limiting, reputation-based throttling and temporary resource problems at the receiver all produce temporary failures too. The way to separate them is to look at what happens next: a greylisted message succeeds on its second or third attempt and then stops being deferred at that domain, while a throttled sender keeps meeting deferrals indefinitely. Persistent deferral across many attempts and many recipients is a genuine warning, and it is the one case in this topic where doing nothing is the wrong answer.
Some receivers apply it selectively. Implementations commonly exempt senders with established reputation, exempt authenticated mail, or apply the policy only to senders that already look marginal. That makes greylisting behaviour a weak indirect signal about how a receiver currently sees you: an established sender frequently never encounters it at a domain where a new one does. It is weak enough not to build any decision on, and worth knowing so that a colleague's "I never see this" is not read as evidence against your logs.
- Temporary failure, retried automatically
- Message arrives late rather than never
- Applies to unfamiliar sender, IP and recipient combinations
- Nothing to fix on your side
- Permanent failure, no retry
- Message never arrives and is counted as a bounce
- Applies for reputation, policy or content reasons
- Needs diagnosis, and the rejection text names the cause
What this means when you are running outbound
The main practical value of understanding greylisting is that it removes a false alarm and stops a bad reaction.
When a campaign sends more slowly than planned, the question to ask is whether messages are being deferred and eventually delivered, or refused outright. Your platform's logs separate those two by response code. If the answer is deferrals, the correct action is to do nothing: the mail is arriving, on the receiver's schedule rather than yours, and the delay is largely confined to the first message to each organisation.
The bad reaction, and it is common, is to increase sending rate or retry aggressiveness to catch up. That converts a harmless delay into a genuine reputation problem, because a sudden burst of retries from an address a receiver is already treating cautiously is exactly the behaviour that attracts throttling. Patience costs an afternoon; impatience costs a domain.
Why it matters more for one message than for many
There is a reason greylisting deserves attention in cold outbound specifically. Because every first contact is an unfamiliar triplet, the delay lands on the message that carries the entire value of the campaign. A programme that sends one message per prospect experiences greylisting on essentially all of its mail, where a programme sending repeatedly to a warm list experiences it once and never again.
That does not argue for sending more. It argues for planning around the delay: allow a wider delivery window when a campaign has to land inside a particular period, and read completion time rather than assuming a campaign finished when the platform stopped queueing. If a campaign is timed to a date, count backwards from the date with the deferral window included rather than from an idealised send rate.
There is a related habit worth adopting on any campaign whose timing matters: read the send log at the end rather than the dashboard summary. The summary reports what was accepted. The log reports when each message was accepted and how many attempts it took, and the shape of that distribution is the difference between "the campaign went out on Tuesday" and "a third of it went out on Wednesday afternoon". For work timed to an event or a deadline, that distinction is the whole result.
- Yes: Deferrals and refusals are separated by SMTP response code
- Yes: Deferred messages are confirmed to have been delivered on retry
- Yes: Delivery window is planned wide enough to absorb first-contact delays
- Yes: Completion time is read from the logs rather than assumed
- No: Raising send rate or retry aggressiveness to make up lost time
- No: Treating a deferral as evidence of a reputation problem
The short version
One structural point is worth carrying away even if you never think about greylisting again. SMTP has always distinguished "not now" from "never", and a great deal of receiving behaviour lives in the first category: throttling, rate limits, resource pressure, and this. Sending platforms hide that distinction behind an automatic retry, which is the right default and also the reason most teams have never looked at the difference. The moment a campaign behaves oddly, the response codes are the first place worth looking, and they are usually one click away in a place nobody has opened.
Greylisting is a receiver saying "prove you are a real mail server" by asking you to come back in a few minutes. Legitimate senders comply automatically, so the technique costs you time rather than messages.
It is worth recognising because the symptom, a campaign running slowly, is easy to misdiagnose as throttling, as a reputation problem, or as a fault in your own platform, and the wrong response to it is genuinely damaging. Check the response codes, confirm the deferred mail arrived, and move on. If messages are genuinely being refused rather than deferred, the cause sits elsewhere: in authentication, in bounce behaviour, or in a recipient-side policy that a deliverability audit will identify faster than guesswork. A domain with real sending history behind it, warmed properly, meets fewer of these policies in the first place.
RevenueFlow runs cold email and LinkedIn outreach for B2B teams, one message per campaign, on infrastructure we monitor ourselves. See how the campaigns work.
Behaviour verified as of August 2026 against RFC 6647. Implementations vary by receiver; verify current specifications with the source before relying on them.
Frequently asked questions.
Frequently asked questions- Is greylisting blocking my emails?
- No. It defers them, and a retried message arrives. If mail is genuinely missing rather than late, greylisting is the wrong suspect. The characteristic symptom is a campaign that took far longer to complete than planned, with the delay concentrated on first contact and absent from later mail to the same recipients.
- How long does a greylisting delay last?
- The floor is the receiver minimum wait, often a few minutes. The actual delay is set by your sending platform retry schedule, which may be considerably longer, so two systems each behaving correctly can produce a gap of an hour or more between send and delivery. Plan a wider delivery window when timing matters.
- How do I tell greylisting apart from throttling?
- Watch what happens next. A greylisted message succeeds on its second or third attempt and then stops being deferred at that domain. A throttled sender keeps meeting temporary failures indefinitely, across many recipients. Persistent deferral is a genuine warning and the one case here where doing nothing is the wrong answer.
- Does a greylisting deferral mean my domain has a reputation problem?
- No. It is a policy applied to unfamiliar sender, address and recipient combinations rather than a judgment about you. Some implementations do exempt senders with established reputation, so an experienced sender may never encounter it where a new one does, but the deferral itself is not evidence of anything being wrong.