What Is Greylisting in Email Delivery?

Greylisting is an anti-spam technique that works directly on the recipient's mail server. When an email arrives from an unknown sender, the server temporarily rejects it with a refusal code instead of accepting it on the first attempt. Legitimate mail servers, in compliance with the SMTP protocol, resend the message after a short delay. Most spam servers do not bother retrying, which is how greylisting filters out a large share of unwanted mail without any configuration on the sender or recipient side.

This guide explains what greylisting is in email delivery, how the mechanism works step by step, where it sits among other spam protection methods, and the trade-offs that come with it. We also cover the angle most articles skip: how greylisting interacts with email verification tools and why a 451 response from a greylister should never be confused with a real invalid mailbox.

Definition: What Is Greylisting?

Greylisting is a server-side filtering method that postpones the delivery of any email coming from a sender, IP address, or recipient combination that the receiving mail server has not seen before. Rather than blocking the message outright or accepting it immediately, the server returns a temporary error code and waits to see whether the sending server retries.

A standards-compliant Mail Transfer Agent (MTA) will retry the delivery after a specified delay. When that retry arrives, the message passes through and is delivered to the inbox. A spam server, which is typically built for one-shot bulk distribution, usually does not retry, and the message never reaches the recipient. The technique is rooted in the behavior of mail servers, not in keyword lists or static blocklists.

Where Is Greylisting Used?

Greylisting is mainly used to stop the illegitimate mass distribution of spam emails, also known as Unsolicited Bulk Email (UBE). UBE refers to non-personalized messages sent in large volumes, often using purchased or stolen email address lists. These campaigns typically come from compromised computers that form part of remote-controlled botnets, with spoofed sender addresses used to disguise the true source.

Greylisting is not suitable for tackling Unsolicited Commercial Email (UCE). UCE often consists of individually sent, personalized messages from seemingly legitimate businesses or individuals. To counter UCE, content-based filters and blacklisting are more appropriate.

Because greylisting works through a straightforward mechanism, it is resource-efficient and fits well into modern security models such as Zero Trust or Defense in Depth.

How Does Greylisting Work?

The idea of greylisting is based on sorting out potential spam during the delivery process itself. To understand where it intervenes, it helps to look at how an email actually moves between servers.

Email Transmission, Simplified

Email delivery uses the Simple Mail Transfer Protocol (SMTP). An email follows this path:

1. The sender writes a message using their Mail User Agent (MUA), which can be a local mail program or a webmail interface.
2. The MUA establishes an SMTP connection to the sender's Mail Transfer Agent (MTA), the software on the SMTP server that receives and forwards email.
3. The sender's MTA forwards the email to the recipient's MTA. If the recipient's MTA accepts it, the message is deposited in the inbox.
4. When the recipient synchronizes their local inbox via IMAP or POP3, the email appears as a new message.

When Greylisting Intervenes

Greylisting takes effect during the third step, when the recipient's MTA receives the message. At that stage, the receiving MTA already knows three pieces of information before accepting the full email:

• The IP address of the sending mail server
• The sender's email address, obtained via the SMTP MAIL FROM command
• The recipient's email address, obtained via the SMTP RCPT TO command

Because these details are transmitted before the message body itself, they are referred to as envelope data. The MTA logs the envelope data of each incoming email in a list known as the greylist. A greylist entry looks like this:

IP Address	Sender	Recipient
192.0.2.3	[email protected]	[email protected]

First and Second Delivery Attempts

If a combination of envelope data appears for the first time, the MTA initially rejects the email. It returns a fault code indicating a temporary technical issue and prompts the sending MTA to retry after a waiting period.

A legitimate, standards-compliant MTA will follow this request and resend the email later. On the second delivery attempt, the envelope data is already stored in the greylist, so the message is accepted and delivered. Illegitimate MTAs used by spammers typically do not retry, which is where the strength of greylisting lies. Because no second attempt is made, the spam never reaches the recipient. The recipient remains unaware of the process, making greylisting a discreet and highly effective method of filtering unwanted messages.

The same logic applies across the cold email landscape, where SMTP error codes and temporary deferrals shape how a sending domain is treated by recipient servers.

An Example of Greylisting

Below is what a typical SMTP transaction looks like when the receiving server has greylisting enabled. The sending IP and sender address have never been seen before, so the message is held with a 4xx response:

$ telnet mail.example.com 25
220 mail.example.com ESMTP ready
HELO sender.test
250 mail.example.com Hello
MAIL FROM:<[email protected]>
250 2.1.0 Ok
RCPT TO:<[email protected]>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: Hello

First contact.
.
451 4.7.1 Greylisted, please try again in 300 seconds
QUIT
221 2.0.0 Bye

The key line is the 451 response after DATA. 4xx codes signal a temporary failure, which tells the sending MTA to keep the message in its queue and retry later. A compliant sender will redeliver automatically and the second attempt will be accepted. A spam-blasting tool that fires once and moves on never comes back, and the message is silently dropped.

Notice that the rejection happens after the full DATA phase in this example. Some greylisters reject earlier (right after RCPT TO) to save bandwidth. Both styles produce the same outcome from the sender's perspective.

Greylisting With Whitelist and Blacklist

Greylisting works particularly well in conjunction with related techniques like whitelisting and blacklisting. A timeline of delivery attempts on the receiving mail server shows how the three interact:

• e1: An email from a sender not yet listed on the greylist arrives. The MTA rejects it with a temporary error and logs the envelope data.
• e2: Later, another email from the same sender to the same recipient arrives. Since the envelope data is now in the greylist, the message is delivered and the data is also added to the whitelist.
• e3: After previous correspondence between Anne and Fred, the IP address of Anne's SMTP server changes from 192.0.2.3 to 192.0.2.34. Because this is a new combination, Anne is treated as an unknown sender and placed on the greylist again.
• e4: Anne writes to Fred again, this time via the original SMTP server 192.0.2.3. Since the envelope data already exists in the whitelist, the email is delivered immediately without delay.
• e5: A delivery attempt is made from server 192.0.2.66. As this server is flagged as malicious in the blacklist, the email is rejected outright. This suggests that the sender address [email protected] was spoofed.

Greylisting vs Blacklist-Based and Rule-Based Filtering

The three approaches differ in how they identify and stop unwanted email.

Greylisting

• Uses a temporal approach. Initial emails from unknown senders are temporarily rejected, prompting a retry.
• Legitimate mail servers retry after a delay, while spam servers tend not to.
• Not based on blacklists or specific rules, but on the behavior of mail servers when they attempt delivery.

Blacklist-Based Filtering

• Uses databases of servers or IP addresses known to be associated with spam.
• Emails from those IP addresses are blocked or marked as spam.
• Blacklists are maintained by specialized organizations and updated regularly to include newly identified spam servers. Tools like MXToolbox help senders monitor whether their domains are listed.

Rule-Based Filtering

• Uses specific criteria to identify unwanted email.
• Rules can include keywords, regular expressions, specific headers, and similar patterns.
• Emails matching the criteria are blocked or marked as spam.

The main differences lie in their approach: greylisting is based on server behavior, blacklist filtering relies on pre-established databases of known spam IP addresses, and rule-based filtering uses content criteria. These techniques can be combined to provide more comprehensive protection.

Greylisting and Email Verification: Why a 451 Is Not an Invalid Mailbox

This is the part most greylisting articles miss. Email verification services connect to recipient mail servers and walk through the same SMTP envelope (HELO, MAIL FROM, RCPT TO) that a real mail send would use. If the receiving server is greylisting and returns a 451 on the verification probe, a naive verifier will record that mailbox as failed, undeliverable, or risky. That is a false negative — the address is perfectly valid, the verifier just got deferred.

For senders, the consequence is real. Removing greylisted addresses from a campaign list discards engaged recipients, biases your audience toward providers that don't greylist, and makes the deliverability of the remaining list look artificially better than it is.

Verification engines that handle greylisting properly do three things:

• Distinguish 4xx from 5xx. A 5xx permanent error (e.g. 550 No such user) is a real invalid mailbox. A 4xx temporary error is a deferral and must not be scored the same way.
• Retry from the same probing identity. The retry has to come from the same connecting IP and use the same envelope so the greylist entry matches. Probing from a fresh IP each time guarantees a permanent loop of greylist hits.
• Honor the suggested delay. Most greylisters recommend a wait of 1 to 15 minutes before the retry. Hitting the server again in 5 seconds is treated as suspicious and may extend the deferral window.

BounceCheck's verification pipeline classifies 4xx greylisting responses as a deferred state rather than a failure, queues a retry from the same probing infrastructure after a respectful delay, and only finalizes the address as valid or invalid once a definitive answer is received. The result is that legitimate addresses behind greylisting servers (common at corporate domains, universities, and managed mail providers) are not silently removed from your list.

Is Greylisting Effective in Reducing Spam?

Greylisting can be effective in reducing spam, since many spam servers are not configured to retry delivery after a specified delay. However, some spam systems can be configured to bypass greylisting by retrying, which reduces its effectiveness over time. In practice, the technique still provides major relief for mail servers worldwide because the cost of programming spam infrastructure to retry every rejected message is high relative to the return on a single campaign.

Trade-Offs of Greylisting

Greylisting is rare among spam-fighting tools in that it costs almost nothing to run and requires no maintenance. The flip side is that the delay it introduces is visible in exactly the moments when delay is most painful.

What you gain:

• Effective at filtering bulk spam from one-shot senders, with no per-message configuration.
• Cheap to operate. No content scanning, no machine learning, no list maintenance.
• Acts as an early signal: a sender that fails to retry is flagged as suspicious without needing further analysis.
• Catches malware campaigns and zero-day spam patterns before signature-based filters have learned them.

What you lose:

• Time-sensitive messages (password resets, OTP codes, two-factor login links) may arrive after the user has given up.
• Legitimate senders running misconfigured MTAs may never retry, and their mail is silently lost.
• If the sending server changes IP between attempts (common in load-balanced sender pools), the greylist match fails and delivery is delayed again.
• End users rarely know greylisting is in play, so unexplained delivery delays become support tickets.
• Modern spam operations increasingly retry, eroding the technique's hit rate compared to a decade ago.

Potential Problems With Greylisting

Although greylisting offers clear advantages, the technique also comes with certain drawbacks worth flagging:

• Dependence on a stable IP address: If the sending SMTP server's IP address changes, the recipient's server treats the email as unknown and places it on the greylist.
• Possible delivery failures due to configuration issues: If the sender's MTA does not follow the request to retry, the message will never be delivered.
• Potential to be bypassed with enough resources: In theory, spammers could resend emails multiple times to circumvent greylisting. The effort required is currently high enough that it is rarely attempted.
• Delays can disrupt time-sensitive messages: Emails such as password reset links or login codes may expire if they are delayed by greylisting. By the time the resend occurs, the content may no longer be valid.
• Limited transparency in cloud-based solutions: In many modern cloud email services, greylisting is integrated by default without direct access for administrators or users, which can lead to unexplained delivery delays.

FAQs

What is greylisting in email delivery?

Greylisting is an anti-spam technique where the recipient's mail server temporarily rejects an email from an unknown sender by returning a temporary refusal code. Legitimate mail servers retry the delivery after a delay, while most spam servers do not, which is how greylisting filters out unwanted mail.

How long does greylisting delay an email?

The delay depends on the sending server's retry interval, which is typically a few minutes. Once the retry succeeds, the envelope data is stored, and subsequent emails from the same sender are delivered without further delay.

Can greylisting cause legitimate emails to be lost?

In rare cases, yes. If the sender's MTA is misconfigured and does not retry after a temporary rejection, the message will never be delivered. Time-sensitive messages such as password reset links may also expire before the retry occurs.

Does greylisting require any setup from the sender or recipient?

No. Greylisting functions directly on the recipient's mail server and requires no configuration from either the sender or the recipient. Users often do not know that greylisting is active.

Is greylisting still useful when SPF, DKIM, and DMARC are in place?

Yes. SPF, DKIM, and DMARC verify the authenticity of a sender, while greylisting filters based on retry behavior. The two approaches address different aspects of spam protection and are typically used together.

How does greylisting affect email verification results?

If a verification service treats a 451 greylisting response as a permanent failure, valid mailboxes get marked as undeliverable. A correctly built verifier classifies 4xx codes as deferred, retries from the same probing IP after the recommended delay, and only finalizes the address once the receiving server returns a definitive answer.