What Is Greylisting? How It Works, Why It Delays Your Email, and Whether It Still Matters
Your 2FA code just arrived - 14 minutes late, already expired. You request another one, and three codes show up simultaneously. That's greylisting doing its job, badly.
So what is greylisting, exactly, and why does this decades-old spam filter still trip up modern email infrastructure?
Quick version: Greylisting temporarily rejects emails from unknown senders with an SMTP 4xx code (often 451), forcing the sending server to retry. Legitimate servers retry and get through. Spam bots don't bother. It's cheap, effective against unsophisticated spam, and still useful as one layer alongside SPF/DKIM/DMARC - but it causes real headaches if you don't tune it.
How Email Greylisting Works
When a mail server using greylisting receives a message, it checks three pieces of information - the triplet:
- Sender IP address (often treated as a /24 subnet for large senders rotating IPs)
- Sender email address - the MAIL FROM value in the SMTP envelope
- Recipient email address
If the triplet is new, the server responds with an SMTP 4xx temporary failure code, typically 451. It doesn't reject the email permanently. It says "try again later."
Legitimate mail servers like Postfix and Exchange are built to retry after temporary failures after temporary failures. They usually come back around 15 minutes later, sometimes within minutes, sometimes up to an hour depending on configuration. When they do, the greylisting server recognizes the triplet, accepts the message, and often whitelists that combination going forward.
Spam bots typically don't retry. They're built for volume - blast millions of messages and move on. RFC 6647 calls greylisting "cheap and early" in the SMTP sequence and notes it "surprisingly remains useful" because much spamware still doesn't implement proper retry logic. The technique works best against unsolicited bulk email from throwaway infrastructure, not targeted commercial spam from properly configured servers.
One edge case worth knowing: if a system requires exact matching on the sender address, variable return-path schemes like VERP or SRS can change the MAIL FROM between attempts and cause repeated deferrals. Many setups mitigate this with looser matching - treating IP pools as equivalent via /24 grouping, for instance - but misconfigured policies still trip on it.
Greylisting vs. Blacklisting vs. Whitelisting
These three terms get confused constantly. Here's the difference.
| Method | Action | Duration | Basis |
|---|---|---|---|
| Greylisting | Temporary reject (4xx) | Auto-expires | Behavioral - retry test |
| Blacklisting | Permanent block | Until removed | Reputation or rules |
| Whitelisting | Always allow | Until removed | Trusted sender list |
The key distinction: greylisting is locally constructed and auto-expiring. Your mail server builds its own triplet database, and entries expire after a configurable period of inactivity - typically 35 days. Blacklists and whitelists are persistent and often shared across organizations.
Pros and Cons
What greylisting does well:
- Blocks a large volume of bot-driven spam with almost zero resource cost
- Requires no content scanning or machine learning - pure behavioral filtering
- Works at the SMTP level before the message body is transmitted, saving bandwidth
- Easy to deploy on Postfix and Sendmail setups
Where it falls apart:
- MFA emails and password resets get delayed 5-30 minutes. Waiting even fifteen minutes for a password reset feels like an eternity, and MFA codes often expire before they arrive. One sysadmin on Reddit reported 10+ minute delays on MFA emails from AT&T and Lumen through Mimecast.
- Burst delivery after release - Migadu users report multiple queued messages arriving simultaneously once the first one clears. We've seen the same thing in our own testing: five queued messages landing within seconds of each other.
- Whitelisting maintenance becomes endless. Every new SaaS tool, every transactional sender, every password reset service needs an exception. It's death by a thousand paper cuts.
Greylisting works great until it blocks something important. Then it's a fire drill.
Greylisting turns whitelisting into a full-time job and delays the emails that matter most. Your outbound data shouldn't suffer the same fate. Prospeo's 5-step verification retries greylisted 4xx responses instead of marking valid addresses as unknown - delivering 98% email accuracy across 143M+ verified contacts.
Stop losing valid prospects to lazy verification tools.
Is It Still Relevant in 2026?
Yes, but it's not a primary defense anymore.
Email authentication has shifted dramatically. Google and Yahoo enforced SPF/DKIM/DMARC requirements for senders of 5,000+ daily messages back in February 2024. Microsoft followed in May 2025 with similar requirements for high-volume senders to consumer inboxes. But adoption isn't universal - domain-level measurement shows only about 16% of domains have implemented DMARC at all, which is a staggeringly low number given how long the standard has existed.
That gap is exactly where greylisting email defenses still earn their keep. It catches the low-effort spam that slips through incomplete authentication - the bots that don't retry, the throwaway domains without SPF records. Not the wall, but a useful tripwire in a defense-in-depth stack that starts with DMARC enforcement and reputation-based filtering.
Here's the thing: if you're running a self-hosted mail server in 2026 and greylisting is your primary spam defense, you're about five years behind. But if you've already got DMARC enforcement, content filtering, and reputation scoring in place, greylisting at 60 seconds costs you nothing and still catches the bottom-feeders. Turn it on, tune it down, stop thinking about it.
Greylisting and Email Verification
This is where greylisting creates a problem most sales teams don't realize they have.
Many SMTP verification tools perform a single check against the recipient's mail server. When they hit a 4xx response, they don't retry - they mark the address as invalid or unknown. That's a false negative on a perfectly valid email, and it happens more often than you'd think. We've seen verification tools mark 15-20% of valid addresses as unknown when greylisting is in play.
The margins for cold outreach are razor-thin. A spam complaint rate as low as 0.1% can trigger reputation damage, and safe sending limits on Google Workspace and Microsoft 365 sit around 100-150 emails per day. You can't afford to waste sends on bad data, and you can't afford to skip valid contacts because your verification tool choked on a 4xx.
Prospeo's 5-step verification handles greylisting 4xx responses correctly instead of treating them as permanent failures. When a greylisted server returns a temporary rejection, the system retries intelligently rather than marking the address as invalid. Across 143M+ verified emails, that means 98% accuracy - including catch-all domain handling and spam-trap removal.
If you're comparing tools, start with a deliverability-first view of email verification and how it impacts your email bounce rate.
Most SMTP verification tools see a 4xx and quit. That single-check approach marks 15-20% of valid emails as unknown when greylisting is active. Prospeo's proprietary infrastructure retries intelligently, handles catch-all domains, and strips spam traps - so your list is clean before you hit send. At $0.01 per email, bad data costs more than good verification.
Verify your list against greylisting - not around it.
Configuring Greylisting with Postgrey
If you're running Postfix, Postgrey is the standard greylisting implementation. Here are the flags that actually matter:
--delay=60- Drop the default from 300 seconds. Five minutes is unnecessarily long; 60 seconds filters bots without punishing legitimate senders.--max-age=35- Days of inactivity before a triplet gets re-greylisted.--auto-whitelist-clients=5- Whitelist a sender after 5 successful deliveries.--lookup-by-subnet- Group by /24 so rotating IPs from the same sender don't trigger repeated greylisting.--retry-window=2d- Accept retries within a 2-day window, giving slow senders enough time.
Add to smtpd_recipient_restrictions in Postfix:
check_policy_service unix:/var/run/postgrey/postgrey.sock
Maintain whitelist files at /etc/postgrey/whitelist_clients and /etc/postgrey/whitelist_recipients. Add your MFA providers, password reset services, and payment processors to the client whitelist on day one - don't wait for the first support ticket. If you're not whitelisting Okta, Auth0, Duo, and Stripe before you flip greylisting on, you'll hear about it within the hour.
Skip Postgrey entirely if you're running a hosted email gateway like Mimecast or Proofpoint. Those platforms have their own greylisting implementations with better auto-tuning, and layering Postgrey underneath them creates unpredictable retry behavior.
If you're doing outbound too, pair this with an email deliverability checklist and ongoing sender reputation monitoring.
Other Types of Greylisting
The term shows up in two unrelated contexts. In finance, FATF greylisting refers to countries under increased monitoring for anti-money laundering deficiencies. In domain security, greylisting means temporarily blocking newly registered domains - typically for about 30 days - until they're categorized and assigned a reputation score. This article covers email greylisting exclusively.
FAQ
Does Gmail use greylisting?
No. Gmail doesn't use classic triplet-based greylisting. It relies on reputation-based filtering, content scanning, and SPF/DKIM/DMARC enforcement for bulk senders. Traditional greylisting is a receiving-side tactic commonly deployed on self-hosted mail servers and email security gateways like Mimecast.
How long does greylisting delay an email?
Typically around 15 minutes on first contact, though delays range from 60 seconds to over an hour depending on the sending server's retry interval. Postgrey's default delay is 300 seconds (5 minutes), but most admins reduce it to 60 seconds to minimize disruption while still filtering bots.
Can greylisting cause email verification tools to give wrong results?
Absolutely. Many verification tools perform a single SMTP check and treat a 4xx temporary rejection as a permanent failure, marking the address as invalid. Multi-step verification systems that retry intelligently against greylisted servers return accurate results instead of false negatives - it's one of the biggest sources of phantom bounces in cold outreach.