Sometimes, even a small thing, like a dash in your email, can make a huge difference. If you’re looking for answers regarding using a minus,...
Key Takeaways
- Greylisting temporarily rejects messages from unrecognized sender-recipient-IP combinations with a 4xx SMTP error, then accepts the message once the sender retries.
- The greylisting technique requires no sender-side configuration and costs receiving servers very little computationally, but it does delay the first message between any new sender and recipient.
- Greylisting is less effective against spam than it was years ago, since sophisticated spam botnets now implement proper retry behavior. It works best as one layer in a broader defense-in-depth stack.
This article explains greylisting as an email anti-spam method. It does not cover the FATF or Malta/South Africa financial grey list, which uses the same word for an unrelated regulatory concept.
Greylisting blocks a significant portion of basic spam without complex content filters, blocklists, or paid services. It does this by exploiting a single behavioral difference between real mail servers and spam botnets: legitimate servers retry when temporarily rejected, per RFC 5321, while most spam botnets move on to the next target. Greylisting is built around that retry behavior.
What Is Greylisting?
Greylisting sits between whitelisting (always accept) and blacklisting (always reject) on the spam-filtering spectrum, which is where the “grey” name comes from. It is an anti-spam technique implemented at the receiving mail server. When a new sender connects for the first time, the server temporarily refuses to accept the message with a 4xx SMTP error and asks the sender to retry later. Evan Harris introduced the technique in a 2003 whitepaper that remains the standard reference for how the original implementation worked.
The name reflects its position between the two more familiar approaches. Whitelisted senders are always accepted; blacklisted senders are always rejected. Greylisted senders are conditionally accepted; if they pass the retry test, the message gets delivered.
Greylisting requires no configuration from senders. It happens entirely on the receiving server’s side, invisibly to the human sender. Most users discover greylisting only when their first message to a new contact arrives delayed by a few minutes to an hour, with no obvious explanation.
How Does Greylisting Work?
Every greylisting system follows the same universal 4-step process, centered on a data structure called the “triplet” (a combination of three pieces of information that uniquely identifies each incoming message attempt).
Step 1: The mail server receives the connection
A sending mail server (the MTA, or Mail Transfer Agent) connects to the receiving mail server over SMTP. The sender presents three pieces of information: the sending IP address, the sender’s email address, and the recipient’s email address.
These three values form the triplet. The receiving server uses this triplet to determine whether it has seen this exact sender-recipient-IP combination before.
Step 2: The server checks the triplet against its greylist
The receiving server checks its greylist database for the incoming triplet. If the triplet has been seen before and the previous attempt succeeded, the message proceeds straight to delivery, meaning the sender is effectively whitelisted at this point.
If the triplet hasn’t been seen before, the server moves to Step 3.
Step 3: The server responds with a temporary 4xx error
For unknown triplets, the receiving server returns a 4xx SMTP response, typically 451 4.7.1 “Please try again later”. This tells the sending server the message wasn’t accepted, but the rejection is temporary. The sender is expected to retry.
The receiving server records the triplet in its greylist database with a timestamp. A minimum retry window (usually a few minutes) is now in effect. Any retry attempted before that window passes will fail again.
Step 4: The legitimate sender retries; the message is accepted
Any properly configured mail server follows SMTP’s standard retry protocol. After the configured retry delay (commonly 5 to 60 minutes, sometimes longer), the sender attempts the connection again with the same triplet.
This time, the receiving server recognizes the triplet, accepts the message, and adds the sender to its whitelist. All future messages with the same triplet, or a matching sender/IP combination, deliver instantly without going through greylisting again.
Spam botnets often skip this step entirely: they don’t retry; they simply move on to the next target on their list. That simple behavior difference helps greylisting block a useful share of basic spam without checking the message content.
Greylisting vs. Whitelisting vs. Blacklisting
All three techniques control which messages reach the inbox, but they operate on fundamentally different principles. Most modern mail servers layer all three together: whitelisting for known senders, blacklisting for known bad actors, and greylisting for everything in between.
| Characteristic | Whitelisting | Greylisting | Blacklisting |
| How it works | Pre-approved senders are accepted automatically | Unknown senders are temporarily rejected and tested via retry | Known bad senders are permanently rejected |
| Sender impact | Instant delivery | First message delayed by minutes to hours; subsequent messages instant | Outright rejection, with no recourse short of a delisting request |
| False positive rate | Zero; senders are explicitly approved | Low but possible; poorly configured legitimate senders may not retry properly | Moderate; shared IP space means innocent senders can be caught in others’ problems |
| When to use | Trusted vendors, partners, internal communication | Defending against bulk spam from unknown senders | Known bad IPs and domains identified through external blocklists or internal data |
None of these three works well in isolation. An email filter that combines all three, alongside content scoring tools like SpamAssassin, gives receiving servers multiple independent signals to evaluate, rather than relying on any single check.
Pros and Cons of Greylisting
Older spam tools often failed the retry test, but many modern spam systems now retry like legitimate mail servers. That means greylisting can still reduce some low-effort spam, but it may also delay first-time messages from real senders.
Pros:
- Low computational cost: Rejecting a connection with a 4xx error consumes far less server resource than content scanning, AI classification, or blocklist lookups. A greylist database stays small compared to a content-filtering corpus.
- No sender configuration required: Senders don’t need to do anything differently. They send normally, and the receiving server handles the entire process. Compare this to SPF, DKIM, and DMARC, which require sender-side DNS configuration before they work at all.
- Effective against unsophisticated spam botnets: Many botnets skip retry behavior entirely to maximize sending throughput across as many targets as possible. Greylisting catches the bulk of this low-effort spam invisibly, with no content inspection needed.
Cons:
- First-message delays: Every new sender may face a delay the first time they email a recipient. For time-sensitive communication, such as sales outreach, recruiting, or important notifications, that delay can matter.
- Sophisticated spam now retries: Many modern spam botnets now retry messages like legitimate mail servers. Because of that, greylisting catches less spam than it did years ago. Today, it works best as one layer of protection, not as the main anti-spam solution.
- Transactional email sensitivity: Password resets, magic links, and two-factor codes are time-sensitive by nature. A 30-minute greylisting delay can break the user flow even when the email eventually arrives, as the user has often already given up or requested a new code by then.
What to Do If Your Emails Are Being Greylisted
Greylisting is usually not a problem for properly configured mail servers, but some cases are worth checking. Being greylisted does not mean you are blacklisted; it means the receiving server has not seen you before and wants to confirm that your mail server retries correctly.
- Confirm your mail server retries properly: Any reputable email service provider, like SendGrid, Mailgun, Postmark, and AWS SES, handles SMTP retry automatically without any action needed on your part. Self-hosted mail servers should be explicitly configured to retry 4xx responses according to RFC 5321.
- Check delivery logs for 4xx responses: Look for text like “try again later,” “greylisted,” or “please retry.” These are the specific signals that your message hit a greylisting check and that the standard retry process should resolve it without further action.
- Investigate sender reputation if delays recur with the same recipients: Persistent greylisting issues with specific domains may point to a broader email sender reputation problem. If the same servers keep greylisting your messages repeatedly even after retries succeed, that pattern is worth investigating alongside your overall sending practices.
- Maintain clean lists and strong authentication for high-volume sending: Greylisting interacts with your overall sender reputation signal. Clean lists and properly configured SPF, DKIM, and DMARC reduce the likelihood of secondary deliverability issues compounding with any greylisting delays you do encounter. Email List Validation removes the invalid and high-risk addresses that contribute to the reputation problems greylisting alone won’t fix.
Where Greylisting Fits Today
Greylisting is an elegant, low-cost anti-spam technique that exploits a fundamental behavioral difference between legitimate mail servers and spam botnets. It’s not a silver bullet on its own, but it remains a worthwhile layer in a defense-in-depth setup, particularly because it costs receiving servers so little to implement and maintain.
The 4-step mechanism (receive, check the triplet, reject with a 4xx response, and accept on retry) is invisible to most senders and recipients. The main visible effect, for anyone who notices it at all, is a first-message delay between new sender-recipient pairs.
Greylisting protects recipients, but senders have a role to play too. Clean lists, strong authentication, and a solid sender reputation reduce the chances that greylisting becomes a recurring problem. If your domain is hitting greylisting frequently or seeing related deliverability friction, start by avoiding the spam box through the fundamentals (authentication, list hygiene, and consistent sending) that make every layer of spam filtering work in your favor rather than against you.
