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.

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:

The sender writes a message using their Mail User Agent (MUA), which can be a local mail program or a webmail interface.
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.
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.
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 an example of an SMTP transaction ending with a temporary rejection (greylisting):

z03:~# telnet c03.hornetsecurity.com 25
220 c03.hornetsecurity.com ESMTP
helo toto.com
250 "HELO OK."
mail from: [email protected]
250 "MAIL FROM OK."
rcpt to: [email protected]
250 "RCPT TO OK."
data
354 Enter message, ending with "." on a line by itself
Subject: Test
Test
.
451 [EN] Hello, your message was temporarily refused. Your mail server will resend it automatically. Your recipient should receive your email in a few minutes.
quit
221 c03.hornetsecurity.com closing connection

The 451 code is the temporary refusal that tells the sending server to retry. A compliant MTA will queue the message and attempt redelivery automatically.

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 as Part of Comprehensive Spam Protection

Greylisting is often used alongside other anti-spam technologies. Mechanisms such as the Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) help secure email traffic and protect against common forms of abuse. For senders, configuring these correctly is also part of avoiding reputation damage that pushes mail into the spam folder regardless of the receiving filter in use.

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.

Advantages and Disadvantages of Greylisting

Advantages	Disadvantages
No configuration required by the user	Users may not be aware that greylisting is active
Normally does not lead to loss of emails	In rare cases, legitimate emails may be lost
Delay in acceptance can help blacklist malicious senders	Delay may cause users to question the functionality of the mail server
Delay can protect against new, not yet identified malware	May be too slow for time-sensitive emails such as password reset links
Resource-efficient compared to most spam filters
Highly effective technique, providing major relief for mail servers worldwide

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.