What Is Greylisting and Why Email Gets Delayed

Greylisting is an anti-spam technique where a receiving mail server temporarily rejects a message from a sender it has not seen before, returning a 4xx SMTP response that tells the sending server to try again later. Legitimate mail servers are required by RFC 5321 to queue the message and retry, so the mail arrives after a short delay. Most spam sources fire once and never retry, so they are quietly filtered out. Greylisting blocks a large share of junk at almost no infrastructure cost, at the price of delaying the first message from any new sender.

How greylisting works

When an inbound message arrives, a greylisting server does not immediately accept or permanently reject it. Instead it records an identifier for the delivery attempt and answers with a temporary failure. The sending server sees a 4xx code, keeps the message in its queue, and retries after a delay. On the retry, the greylisting server recognizes the sender, accepts the message, and usually remembers it so future mail is not delayed.

The identifier most implementations track is called the triplet:

• The connecting server's IP address (large senders that rotate addresses are often matched on a /24 subnet instead of a single IP)
• The envelope sender address, also known as the MAIL FROM or Return-Path
• The envelope recipient address (RCPT TO)

The first time a given triplet appears it is unknown, so the message is deferred and the server starts a timer. If the same triplet comes back after a minimum waiting period (commonly between 1 and 20 minutes) but before an expiry window closes, the message is accepted. The triplet is then added to an allow list for a defined period, frequently 30 to 90 days, during which mail from that sender to that recipient passes without any delay.

Because the envelope sender is part of the triplet, greylisting interacts with your Return-Path configuration. To understand which address is being matched, see what is the Return-Path.

The SMTP response codes involved

Greylisting relies on the transient-failure class of SMTP replies. The leading digit 4 marks a transient negative completion: RFC 5321 defines it as a command that was not accepted, where the error condition is temporary and the same command may be requested again. This is different from the 5xx class, which signals a permanent failure that no amount of retrying will fix.

The enhanced status code (the three-part 4.7.1 style value defined in RFC 3463) rides alongside the basic reply. RFC 3463 defines X.7.1 as "Delivery not authorized, message refused," a per-host or per-recipient policy decision, and the leading 4 marks it as transient. That combination is exactly what greylisting is. Many servers add human-readable text such as greylisted, please try again later so postmasters can tell what happened.

The distinction between a 4xx deferral and a 5xx rejection matters. A deferral is a soft outcome that the sender retries automatically; a rejection is a hard outcome that bounces back to the author. For a full walk through of both classes, read SMTP error codes explained.

Why it fights spam so effectively

Greylisting exploits a simple economic asymmetry. A compliant mail server treats a 4xx reply as a normal part of SMTP and keeps the message queued for a later retry, as the protocol requires. Most spam and malware systems do not behave this way. They are built to blast as many messages as possible in the shortest time from botnets or throwaway hosts, then move on. When they hit resistance, they drop the connection and never come back, and that single missed retry is enough to stop the message.

Spam operators could, in theory, build proper retry queues to defeat greylisting, and some larger operations do. But doing so slows their throughput, forces them to hold state, and makes their infrastructure easier to identify and blocklist. For the long tail of low-effort spam sources, greylisting remains a cheap and durable filter. It also buys time: during the delay before the retry, real-time blocklists such as those run by Spamhaus may list a newly abusive IP, so the retried message can still be caught by other layers.

Why legitimate mail is delayed, not lost

This is the point that worries senders most, and the answer is reassuring. A 4xx deferral does not bounce the message. RFC 5321 directs a sending server that receives a transient failure to retain the message and attempt redelivery, with a retry window that generally spans several days before giving up. Every mainstream platform, from Google Workspace to Microsoft 365 to standalone Postfix and Exim servers, honors this. The message sits in the outbound queue and is retried automatically.

In practice most greylisted messages arrive within 15 to 30 minutes, and often sooner. The exact delay depends on two things: the receiving server's minimum waiting period, and the sending server's retry schedule. If the sender's next retry falls before the greylist waiting period elapses, it is deferred again and waits for the following attempt, which is why some messages take longer.

The message is only lost in edge cases: if the sending server gives up before the greylist window allows acceptance, or if it rotates to a completely different IP outside the matched subnet on each retry so the triplet never stabilizes. Well-configured senders do not hit these problems. A one-time delay on the first message from a new correspondent, followed by instant delivery afterward, is the normal experience.

Retry behavior in detail

The retry loop looks like this:

1. The first attempt from an unknown triplet returns 451 4.7.1. The sending MTA logs a deferral and queues the message.
2. The sending MTA waits per its retry schedule (often a few minutes for the first retry, then backing off), then reconnects.
3. If the greylist minimum wait has elapsed, the receiving server accepts the message and records the triplet on its allow list.
4. Subsequent messages matching that triplet, within the allow-list lifetime, are delivered with no delay.

Two failure modes are worth knowing. First, senders that use large pools of outbound IPs (many high-volume ESPs) can trip greylisting repeatedly if the receiver matches on exact IP rather than subnet, because each retry may come from a different address. Second, if your sending IP is shared, another tenant's behavior can influence how receivers treat the whole range. Knowing whether you are on shared or dedicated infrastructure helps here; see dedicated vs shared IP.

What senders should do

You cannot force a receiver to stop greylisting you, but you can make sure delays stay short and never turn into losses.

• Confirm your outbound server honors 4xx and retries promptly. Any reputable platform does; if you run your own MTA, check the queue-retry interval is not set to hours.
• Keep your sending IP and envelope sender stable. A consistent triplet gets allow-listed quickly. Frequent IP rotation without subnet-friendly receivers works against you.
• Authenticate cleanly. Greylisting is separate from SPF, DKIM, and DMARC, but strong authentication and a good sending history mean many receivers greylist you less aggressively or skip it once you are trusted. Review SPF, DKIM, and DMARC explained and work on sender reputation.
• Do not treat a 451 deferral as a bounce in your application logic. Retrying it yourself, on top of the MTA's own retry, can create duplicate sends.

If mail to a specific domain seems stuck, separate a genuine greylist delay from a deliverability problem such as filtering to spam. The guide on why emails go to spam helps you tell the difference.

What administrators should consider

If you run inbound mail and are weighing greylisting, the tradeoff is real. It removes a meaningful volume of low-effort spam at near-zero cost, but it adds latency to first-contact mail, which frustrates users expecting instant delivery of password resets and one-time codes. Common mitigations include allow-listing known-good senders and large providers, using subnet matching so IP-rotating senders are not penalized, and setting a short minimum wait of a few minutes so genuine mail is barely delayed.

Many organizations now favor authentication-based filtering with SPF, DKIM, and DMARC plus reputation scoring over classic greylisting, because those approaches do not delay transactional mail. Greylisting still has a place as one layer in a defense-in-depth setup, particularly for smaller servers without commercial filtering. Inbound diagnosis often comes down to reading raw headers, where deferral and policy notes appear in the received chain.

Frequently asked questions

Is greylisting the same as blocklisting?

No. Blocklisting permanently rejects mail from IPs or domains with a bad reputation, usually with a 5xx reply. Greylisting temporarily defers mail from any unknown sender with a 4xx reply and accepts it on retry, regardless of reputation.

How long does a greylisting delay last?

Most greylisted messages arrive within 15 to 30 minutes. The delay depends on the receiver's minimum waiting period and the sender's retry schedule, so occasionally it runs longer, but the message is not lost as long as the sender keeps retrying.

Can greylisting cause permanent email failure?

Only in rare cases, such as a sending server that abandons retries too early or rotates through unrelated IPs on every attempt so the triplet never matches. Standard mail platforms retry correctly, so first-contact mail is delayed and then delivered.

Does greylisting affect SPF, DKIM, or DMARC?

No. Greylisting operates during the SMTP conversation, independent of authentication results. Senders with strong authentication and reputation are often greylisted less or trusted faster, but the two mechanisms are separate.

Want to confirm your domain is set up to sail through greylisting and land in the inbox? Run a free SPFWise scan to check your SPF, DKIM, and DMARC records and spot deliverability problems before your recipients do.