What is Greylisting?

What is Greylisting?
What is Greylisting?

Greylisting temporarily blocks unfamiliar emails, leveraging differences in retry behaviour between legitimate and spam servers. Legitimate mail systems correctly retry later per protocols when initially rejected, whereas spammers rarely bother.

By failing unknown senders first, greylisting filters substantial spam right away but delays initial messages. This blog explains the greylisting methodology, its advantages in effectively blocking most spam, and disadvantages like mail delays. It also covers proper configuration and integration with other layers.

What is Greylisting?

Greylisting temporarily blocks messages from unfamiliar senders, forcing email servers to retry delivery per SMTP standards to get mail through. Legitimate systems retry automatically, while spammers rarely bother, blocking volumes of initial spam.

Greylisting complements other filters, handling initial waves so advanced methods can focus on trickier spam that does slip past this first layer after senders meet retry criteria over time to become recognised.

How Greylisting Works

Greylisting works by checking incoming mail server IP address, sender email, and recipient email - collectively the "SMTP triplet" - against a database of known senders called the greylist. New, unrecognised triplets get temporarily rejected with a 4xx error to trigger greylisting vetting.

Legitimate servers retry delivery starting around 15 minutes later per standards, now matching the greylist record and clearing validation, with further emails automatically whitelisted.

But spammers rarely retry after even a single failure, so greylisting blocks most initial spam by failing unfamiliar senders once until they demonstrate good behaviour on retry to pass this filtering layer.

Advantages of Greylisting

Greylisting comes with several advantages:

Effectiveness Against Spam

Greylisting blocks the vast majority of spam and malware from unfamiliar sending systems. Spammers depend on sending vast volumes quickly and rarely retry rejected messages. Greylisting leverages this weakness for easy early filtering.

Low Resource Usage

Checking the sender triplet and issuing temporary errors consumes very few server resources compared to other spam filtering methods. With most spam blocked before more advanced filtering, the overall load is reduced.

No End User Configuration

Users enjoy automatic spam protection via greylisting without needing to change settings or whitelist senders themselves. Delays impact only early messages until senders pass vetting.

Protection for New Threats

The combination of temporary denial and whitelisting provides protection even against new spam and malware attacks using previously unseen domains and servers. Sources are blocked on first contact until verified safe over time.

Compatibility With All Mail Servers

Greylisting functions with any standards-compliant mail systems, making it suitable across the modern email ecosystem. There are no special mail client requirements. Only sending MTAs needs to accommodate retries.

Ease of Implementation

Implementing greylisting requires a fairly straightforward configuration, mostly around timing parameters. Many turnkey packages integrate smoothly with mail servers through plugins or modules, minimising admin overhead to enable protection.

Disadvantages of Greylisting

While greylisting does provide some appealing advantages, there are also some problems with the technology:

Delays for First-Time Senders

Greylisting inherently delays initial messages from any new, unknown sender since even legitimate sources start out unverified. This delay period feels at odds with the near-instant delivery that many users have come to expect. However, the original SMTP protocol guarantees only eventual delivery, not immediate delivery.

Order Inversion

In some cases, the following messages may arrive sooner than the initial ones. If an early email gets greylisted while a subsequent one passes whitelisting, the later message could appear first. Users may find this confusing if order matters.

Failure to Retry Properly

Some misconfigured, outdated, or non-compliant mail servers and clients fail to retry properly after temporary rejects. Very old systems may follow only the initial SMTP RFC 821, which used "should" instead of the more definitive "must" for retries. Whitelisting and exceptions help accommodate such cases.

Changing IP Addresses

If the sending server retries from a different IP address than the original attempt, greylisting will fail the triplet match and keep rejecting the message. Using relaxed matching thresholds for IP addresses based on subnets or SPF data alleviates this issue, as do aggregated whitelist entries.

Configuring Greylisting

Proper configuration tuning goes a long way toward mitigating the disadvantages and downsides above, stemming from the fundamental method of greylisting.

Severity varies based on how rigorously greylisting gets enforced versus adding exceptions to accommodate real-world diversity. There are always trade offs balancing spam protection efficacy versus potential overblocking. Key timing criteria driving this equilibrium include:

Initial Delay Period

The initial 4xx refusal response triggers the start of the delay period clock for unknown new senders to retry message submission. This retry scheduling sets the tempo of greylisting. Too short timers allow too easy spammer retries, while overly long delays negatively harm user experience for legitimate senders.

Typical initial greylist periods fall in the 5-15 minute range, which fits general email infrastructure expectations. Research indicates spammers rarely retry even after just 5 minutes, while 15 minutes is the common retry start point across many mainstream mail systems.

Total Blocking Period

The total greylist window determines how long unsuccessful entries stay active, pending potential retries to qualify messages. Too short risks spam getting through while too long causes false positives expiring before late retries by slower legacy mail systems.

Common configurations keep greylist periods active from one hour out to as many as multiple days before discarding non-matching entries altogether and resetting the process on any future submissions. Tuning depends on sending traffic diversity and administrator tolerance for delayed emails.

Retry Intervals

The escalating retry intervals expected by RFC 5321 provide useful guidance. The standards recommend retries increasing incrementally, such as 0, 15, 30, 60 minutes, etc, on temporary failures, which fits greylisting rejection scenarios.

Assessing retry spacing patterns offers clues into sender legitimacy, such as randomness hints at spammers, while orderly known intervals indicate proper implementations amenable to greylisting protections after the first pass.

Blocking Flexibility

Matching thresholds determine how closely a retry attempt needs to match the original IP address, sender, or recipient values to qualify as the same triple entry coming back through. More rigidity increases security while more flexibility prevents over-blocking of legitimate mail that may come back slightly altered.

Automated Whitelisting Criteria

Intelligently automated promotion of vetted senders to bypass future greylisting is key to minimising repeat delays after successful introductions. Whitelist updates build a safe senders list without ongoing manual overhead.

Criteria governing trusted sender status assessments based on positive delivery patterns include:

  • Multiple Successful Retries

Consistently completing the greylisting cycle with expected retry spacing indicates good faith and standards compliance, qualifying the source.

  • Varied Recipient Pools

Senders establishing reputations across different recipient addresses avoid single target favouritism indicative of potential phishing risks.

  • Sustained Volume Consistency

Steady volumes within reasonable levels over time suggest established infrastructure rather than short-term spam bursts.

  • IP Reputation Factors

External IP sender reputation metadata provides supplementary trust and risk context factored into whitelist promotion decisions.

  • Timestamp Longevity

Keeping whitelist entries active for extended periods avoids discarding reliable senders due merely to email dormancy, providing value continuity.

  • Source Encryption

Whitelist prioritisation for encrypted transport protocols like TLS recognises security best efforts in Sender routines.

  • Priority Contacts

VIP contacts designated by users auto-bypass greylisting vetting, speeding critical response channels.

Balancing these automated criteria prevents admittance of obvious spam while still onboarding reliable, legitimate sources into the greylist trust layer as they exhibit compliant behaviours.

Integration with Supplementary Filters

While highly effective against initial unfamiliar traffic, greylisting's protection window constraints mean integration with additional filtering provides failsafe coverage against subsequent attacks between whitelist updates or by truly persistent abusive senders across longer campaigns.

Follow-on filters like reputation blacklists, full content analysis, Bayesian poisoning detection, malware heuristics and more handle messages that do slip past greylisting using these secondary techniques best suited for scrutinising trickier emails than sieve-like greylisting alone.

Unifying these tools leverages their respective strengths in a blended strategy pipeline:

  • Greylisting filters first unfamiliar spikes rapidly upfront based on behavioural standards
  • Blacklists block senders with recognised prior offences
  • The content inspection identifies disguised threats on deeper analysis
  • Machine learning detects emerging spam mutations

Arranged together, these layers economically handle different focus areas in aggregate for robust protection. Greylisting shields early streaming influxes, so supplementary filters contend only with leftover residue getting through initial vetting.


Combining greylisting of unknown parties with blacklists that are predefined and constantly updated to prevent known malicious senders is a complementary strategy. Greylisting is used to manage new or unknown sources, while blacklisting is used to prevent recidivist threats from occurring. Together, they offer comprehensive coverage.

A number of reputation services, including Spamhaus DROP, SORBS DNSBL, and Spamcop, that provide external blocklists are available. The security is further strengthened by automated additions that are based on spam that is discovered inside.

Implementation Considerations

Deployment Models

Organisations have several options for enabling greylisting:

  • Cloud Services:

Major cloud email platforms like G Suite, Office 365, and Zoho Mail offer integrated greylisting or third-party add-ons activating it.

  • Mail Server Software:

On-premises mail servers running platforms like Exchange, Postfix, and Sendmail directly incorporate native greylisting options or integrate plugins like Postgrey and Policyd-weight.

  • Hardware Appliances:

Dedicated anti-spam appliances deploy easily on-site to offload filtering. They combine greylisting with other techniques for turnkey protection.

  • Hybrid Configurations:

Layered architectures leverage cloud filtering supplemented by on-premise gateways to balance functionality with control.

For SMBs, fully cloud-based filtering simplifies setup, while enterprises prefer blended models, optimising security and customisation.

Migrating Greylists

Pre-seeding greylists, when activating, improve protection continuity. Methods vary by platform, but typically, importing hashed triplet data minimises early false positives after deployment.

Automation and Management

Centralised management tools ease admin tasks around configuring, monitoring, and updating greylisting deployments, especially for larger server groups. Failover and high availability require orchestrating synchronisation.

System Impacts

Modelling anticipated greylisting workload given email volumes and server resources assists in right-sizing deployments. Storage for greylists/whitelists, email queue support if retries back up inbound loads, and connectivity factors into planning.


Greylisting blocks high volumes of spam by temporarily refusing messages from any new, unknown senders while imposing minimal burdens on legitimate email delivery. Its elegant method interacts easily with other filtering safeguards. While delays exist, proper implementations ensure legitimate emails are sent through reliably after initial vetting.

Instasafe's Multi-Factor Authentication provides an extra layer of protection beyond passwords alone.

With Instasafe's easy integration, organisations can enable robust safeguards against phishing risks.

Frequently Asked Questions (FAQs)

1. Is greylisting good or bad?

Greylisting is an email spam filtering technique that temporarily rejects unknown emails. The sending mail server retries later, which filters out spammers who don't retry. It is considered good practice to implement greylisting if you want to cut down on spam.

2. What is greylisting, and how does it work?

Greylisting works by telling an unknown email sender to try again later. Legitimate servers will retry per email protocols, but spammers usually won't. This filters spam without losing wanted emails.

3. What is the difference between blacklisting and greylisting?

Greylisting is similar to blacklisting but less severe. Items on a grey are not confirmed to be completely harmful or safe, they are “temporarily blocked” until verified. In contrast, blacklisting would fully block a listed item.