What is Greylisting? The Temporary IP Block

Why Email Servers Use a Patience Test to Fight Spam

In the mid-2000s, as spam volumes were overwhelming internet infrastructure, a computer scientist named Evan Harris published a proposal for a deceptively simple anti-spam technique. The insight was behavioral: spam bots are optimized for volume and speed. They connect, dump messages, and disconnect as fast as possible to maximize throughput and evade detection. Legitimate mail servers, by contrast, are built to comply with SMTP standards, which explicitly require that servers retry delivery on temporary failures.

That behavioral difference is the entire basis of greylisting. By returning a temporary failure code to any unfamiliar sending IP, a receiving mail server creates a filter that distinguishes between compliant mail infrastructure and volume-optimized spam bots — at virtually zero processing cost and with no need to analyze message content.

The SMTP Foundation: Why Retrying Is Required

SMTP (Simple Mail Transfer Protocol), defined in RFC 5321, specifies three categories of response codes:

• 2xx codes (Positive Completion): The command succeeded. For SMTP delivery, 250 OK means the message was accepted.
• 4xx codes (Transient Negative Completion): A temporary failure occurred. The sender must retry the delivery after a reasonable delay. Common examples: 421 Service Not Available, 450 Requested mail action not taken, 451 Requested action aborted: local error in processing.
• 5xx codes (Permanent Negative Completion): A permanent failure. The sender should not retry. Example: 550 No such user here.

Greylisting exploits the 4xx category. When a message arrives from an IP the server has never seen before, the server returns a 451 (or similar 4xx code) with a message like "Greylisted, please retry in 5 minutes." The SMTP standard requires compliant mail servers to retry this delivery. Spam bots, which do not implement proper SMTP retry queues, simply move on to the next target.

The Greylisting Triplet

A key technical detail: greylisting tracks a triplet of three values, not just the sender's IP address:

1. Sender IP address
2. Sender email address (MAIL FROM)
3. Recipient email address (RCPT TO)

The triplet is stored in a database with a timestamp. When a new, unseen triplet arrives, the server returns a 4xx error and records the triplet with a "first seen" timestamp. When the same triplet attempts delivery again after the required waiting period (typically 5-15 minutes), the server recognizes it in the database, marks it as verified, and accepts the message. Future messages from the same triplet are accepted immediately without delay.

Using the full triplet rather than just the IP prevents false positives in two directions: a sending IP that is whitelisted for one recipient cannot automatically deliver to all recipients, and a new sending IP is not permanently blocked just because it was seen once — only that specific combination is temporarily held.

How Spam Bots Fail the Patience Test

Spam botnets are designed with throughput maximization as the primary engineering goal. A compromised host running a spam bot typically:

• Maintains a queue of millions of target email addresses
• Attempts delivery, moves to the next target immediately on any failure
• Does not implement a proper SMTP retry queue
• Rotates through thousands of different source IPs to evade IP-based blacklists
• Cannot afford to retry every temporarily rejected message — doing so would dramatically reduce throughput

The greylisting delay is typically 5-15 minutes. For a spam bot processing millions of messages, holding a rejected message for 5-15 minutes and then retrying from the same IP contradicts the botnet's fundamental design. The spam bot moves on and never retries. The greylisting server never adds the triplet to its verified list, and any future messages from that IP-sender-recipient combination are greylisted again.

Implementation: How Greylisting Is Deployed

Greylisting is typically deployed as a milter (mail filter) that integrates with a mail server daemon like Postfix, Exim, or Sendmail. Common implementations include:

• Postgrey: A popular Perl-based greylisting policy server for Postfix. It maintains the triplet database and handles whitelisting of known good IP ranges.
• SQLGrey: A Perl-based greylisting policy daemon for Postfix that uses an SQL database for higher-performance triplet lookups.
• Milter-greylist: A C-based greylisting milter that supports multiple MTAs including Sendmail and Postfix.
• Built-in greylisting: Some complete mail security platforms like Rspamd include greylisting as a built-in feature with machine learning integration.

Greylisting Whitelisting: Handling Large Senders

A critical operational consideration: large email senders like Google Workspace, Microsoft 365, Mailchimp, Sendgrid, and Amazon SES send from large, rotating pools of IP addresses. When one of these senders' IPs first contacts a greylisting server, the first message is delayed. If the retry comes from a different IP in the pool (which is common for large providers), the server sees a new triplet and re-greylist it.

This is why greylisting implementations maintain whitelists of known good IP ranges. Postgrey ships with a default whitelist that includes IP ranges for major mail providers. These IPs bypass the greylisting check entirely. Keeping this whitelist current is an ongoing operational task — as major providers change their IP ranges, the whitelist must be updated to prevent delivery delays from legitimate commercial senders.

Greylisting vs. Other Spam Defenses

Common Misconceptions

Misconception 1: Greylisting Blocks Email Permanently

Greylisting is a temporary deferral, not a block. Any legitimate mail server that retries after the delay will have its message accepted. The greylist is not a permanent blacklist. Once a triplet passes the retry test, it is added to the verified list and subsequent messages from that same combination arrive without any delay. Only the very first message from a new sender to a new recipient experiences a delay.

Misconception 2: Greylisting Stops All Spam

Greylisting is effective against volume-blasting spam bots that don't implement retry queues. It is ineffective against spam sent through legitimate mail infrastructure — messages sent via compromised accounts on Gmail, Outlook, or SendGrid will pass greylisting because those providers' infrastructure properly retries delivery. Greylisting is one layer in a defense-in-depth strategy, not a complete solution on its own.

Misconception 3: The Delay Only Happens Once Per Sender IP

The delay applies to the full triplet (IP + sender + recipient), not just the IP. A legitimate sender sending to ten different recipients will experience a greylisting delay for each new recipient in turn. Once each triplet is verified, subsequent messages to those recipients are instant. This is why greylisting can feel disruptive when first deployed on a mail server — there is a brief period where many legitimate first-time senders experience delays as their triplets are established.

Misconception 4: Modern Spam Has Made Greylisting Obsolete

Greylisting remains effective because the fundamental constraint it exploits — the throughput cost of implementing proper SMTP retry queues in botnet software — has not changed. However, the most sophisticated spam operations have adapted by using legitimate cloud mail relays (SES, SendGrid, Mailgun) that do implement retries and are whitelisted. Against these vectors, greylisting offers no protection. For raw botnet spam from compromised hosts, it remains highly effective.

Pro Tips for Greylisting Configuration

• Keep your IP whitelist current for major providers. Google Workspace, Microsoft 365, and major ESPs change their sending IP ranges periodically. Review and update your whitelist quarterly. Postgrey's default whitelist is a starting point but is not always up to date with current provider IP blocks.
• Set the greylist delay to at least 5 minutes but no more than 15 minutes. Too short (under 2 minutes) and some spam bots' retry logic will pass. Too long (over 30 minutes) and you will generate significant user complaints about delayed email. The 5-10 minute range balances effectiveness with acceptable delay.
• Use triplet-based greylisting, not IP-only greylisting. IP-only greylisting causes excessive false positives because large senders rotate across many IPs. Triplet-based greylisting is more surgical and has a lower operational impact on legitimate mail flow.
• Combine greylisting with SPF, DKIM, and DMARC validation. Greylisting handles bot-originated spam effectively. SPF and DKIM handle spoofed-domain spam. DMARC enforces policy for both. The combination blocks the majority of spam categories before any content analysis is needed.
• Monitor your greylist database size and implement expiry policies. Triplet records for senders who never retried accumulate over time. Configure record expiry (typically 30-90 days for unverified triplets, longer for verified ones) to keep the database manageable and avoid stale entries consuming disk space.
• Alert on unusually high greylist hit rates for specific sending IPs. A sudden spike in rejected triplets from a single IP or IP range may indicate a new spam campaign or that a legitimate large sender has changed their IP range. Both situations require different responses — blacklisting versus whitelisting.