What Is Greylisting?
Greylisting is a spam prevention technique where a mail server temporarily rejects an incoming email with a 4xx response code (usually 451) the first time it sees a message from an unfamiliar sender. The server records three pieces of information — the sending IP, the sender address, and the recipient address — as a "triplet." Any email matching that triplet is rejected with a "try again later" message for a configurable delay period, typically 5 to 15 minutes.
The logic is simple: legitimate mail servers retry delivery after temporary failures. Spambots, which prioritize volume over persistence, usually don't.
When the sending server retries after the delay period has passed, the greylisting server accepts the message and whitelists the triplet for future deliveries. Subsequent emails from the same sender to the same recipient go through without delay.
It's an elegant, low-overhead approach to spam filtering. It requires no content analysis, no signature databases, and no machine learning. Just a simple behavioral test: does the sender retry?
Why Mail Servers Use Greylisting
Greylisting gained popularity in the mid-2000s when spam volumes were exploding and content-based filters couldn't keep up. It remains in use today because it works — particularly at the network edge where you want to reject spam before it consumes server resources.
Effectiveness Against Bulk Spam
Traditional spambots send millions of emails through compromised machines (botnets). These bots typically use fire-and-forget delivery: they attempt each address once and move on. They don't implement retry queues because retrying would slow down the operation and keep connections open longer, increasing the chance of detection. Greylisting exploits this by requiring the one behavior spambots avoid.
Low Resource Cost
Unlike content filtering (which requires parsing message bodies, checking URLs, running Bayesian classifiers, and consulting reputation databases), greylisting happens at the SMTP connection level. The server rejects the message before the body is even transmitted. This makes it extremely efficient in terms of CPU, memory, and bandwidth.
Complementary to Other Defenses
Most servers that use greylisting combine it with other techniques — SPF checks, DKIM verification, content scanning, and reputation lookups. Greylisting acts as a first-pass filter that reduces the volume of messages the more expensive filters need to process.
Where It's Common
Greylisting is most prevalent in:
- University and academic mail servers — Often running open-source mail software (Postfix, Exim) with greylisting plugins
- Small and mid-size business mail servers — Particularly self-hosted setups
- Government and institutional mail systems — Conservative security postures
- European mail infrastructure — Higher adoption rates than North American servers
Major consumer providers (Gmail, Outlook, Yahoo) don't use greylisting on inbound mail. Their scale and sophisticated filtering make it unnecessary. But a significant percentage of business and institutional domains do.
How Greylisting Affects Email Verification
This is where greylisting creates a real problem for anyone trying to verify email addresses.
The Verification Process
Standard SMTP verification works by initiating an SMTP conversation with the recipient's mail server. The verifier connects, issues EHLO, MAIL FROM, and RCPT TO commands, and then checks the server's response to the recipient address. A 250 response means the mailbox exists. A 550 means it doesn't.
The verifier never actually sends a message — it disconnects after the RCPT TO check. This is the standard approach used by every email verification service on the market.
The Greylisting Problem
When a greylisting server receives this RCPT TO probe from a verification service, it sees an unfamiliar sender (the verifier's IP) contacting an address for the first time. The server responds with a 4xx temporary rejection — exactly as designed.
But here's the critical issue: the verification service isn't actually sending an email. It's performing a one-time check. If the verifier treats the 4xx response as a definitive answer, it concludes the address is "unknown" or "unverifiable" — a false negative. The address is perfectly valid; the server just hasn't been given a chance to accept it.
This means a greylisted server can cause every address at that domain to appear unverifiable on the first check, even though all those addresses are real, active mailboxes.
The Scale of the Problem
In verification data, greylisting-affected domains account for roughly 8-12% of all domains checked. That's not a trivial number. If you're verifying a B2B list with diverse domains, you could see hundreds or thousands of addresses returned as "unknown" purely because of greylisting — addresses that would have verified as valid if the server had been given time to whitelist the verifier.
How Verification Tools Handle Greylisting (Or Don't)
The quality of a verification service is partly defined by how it handles greylisting. There are three tiers of sophistication:
Tier 1: No Greylisting Handling
Budget verification tools and free services typically make a single SMTP connection per address. If the server responds with a 4xx, they classify the address as "unknown" and move on. This is fast but inaccurate — you're getting false negatives on every greylisted domain.
If you've ever run a list through a free verification tool and gotten a suspiciously high number of "unknown" results, greylisting is likely the reason.
Tier 2: Basic Retry Logic
Mid-tier services implement simple retry logic: if a 4xx response is received, wait a fixed interval (usually 5-10 minutes) and try again. This catches some greylisted servers but misses those with longer delay periods. The retry timing is also uniform — the same delay for every domain, regardless of that domain's specific greylisting configuration.
This approach improves accuracy but significantly increases verification time. A list that would take 30 minutes with no retries might take 2-3 hours with basic retry logic.
Tier 3: Intelligent Greylisting Detection
Advanced verification services — SendSure included — use a multi-layered approach:
Pattern recognition. The system identifies greylisting responses by analyzing the specific 4xx message text, response timing, and server behavior patterns. Not all 4xx responses are greylisting. A "451 Try again later" from a server known to greylist is handled differently than a "452 Too many recipients" rate-limit response.
Domain-level learning. Once the system identifies a domain as using greylisting, it applies optimized retry schedules for all addresses at that domain. This prevents redundant delays — if user1@domain.com triggered greylisting, the system knows user2@domain.com will too and schedules the retry accordingly.
Adaptive timing. Rather than a fixed retry delay, the system adjusts based on the observed greylisting window for each mail server. Some servers greylist for 2 minutes, others for 30. Adaptive timing minimizes wasted wait time while ensuring the retry happens after the greylisting window expires.
Parallel processing. While waiting for greylisted domains to become available, the system processes non-greylisted domains. This means greylisting doesn't create a bottleneck — it's handled concurrently with the rest of the verification queue.
The Speed vs. Accuracy Tradeoff
Greylisting forces verification services to choose between speed and accuracy. This tradeoff is fundamental to understanding why different services produce different results for the same list.
The Fast Path
Skip retries entirely. Return results in minutes. Accept that 8-12% of addresses at greylisted domains will be classified as "unknown." This is the approach of most API-based real-time verification where latency matters more than coverage — for instance, verifying an address during a signup form submission where the user is waiting.
In real-time contexts, a 200-300ms response time requirement makes greylisting retries impossible. The pragmatic solution is to accept the address provisionally and schedule a background re-verification later.
The Accurate Path
Implement intelligent retries. Accept longer processing times for bulk verification jobs. Resolve as many greylisted addresses as possible. This is the approach that matters for list cleaning, where you need the most accurate picture of your list's health before sending a campaign.
The Right Answer: Both
The best verification services offer both modes. Real-time API calls return instant results with a flag indicating when greylisting was detected. Bulk verification jobs implement full retry logic to maximize resolution. SendSure handles both — the real-time API returns sub-second results while flagging greylisted domains, and the bulk pipeline implements the full 27-stage verification process including intelligent greylisting resolution.
How SendSure Handles Greylisting in the 27-Stage Pipeline
SendSure's verification pipeline doesn't treat greylisting as an obstacle — it treats it as just another signal to interpret correctly.
Stage-Level Detection
During the SMTP verification stages, the pipeline classifies every 4xx response by type. Greylisting responses are identified by a combination of response code, response text patterns, and server fingerprinting. Known greylisting implementations (Postgrey, SQLgrey, Milter-Greylist) produce recognizable response signatures.
Retry Scheduling
Addresses at greylisted domains are moved to a retry queue with domain-specific timing. The system maintains a learned database of greylisting configurations per domain, so repeat verifications of the same domain benefit from previous timing data.
Parallel Execution
The retry queue runs concurrently with the main verification pipeline. A bulk job with 10,000 addresses might have 800 queued for greylisting retries. The other 9,200 continue processing normally while the 800 wait for their retry windows.
Result Classification
After retries, addresses that resolve are classified normally — valid, invalid, or catch-all. Addresses that remain unresolvable after multiple retry attempts are classified as "unknown" with a greylisting sub-status. This tells you the address couldn't be verified due to server behavior, not because the address is necessarily bad.
What This Means for Your Results
When you verify a list with SendSure, your "unknown" category is significantly smaller than with services that don't handle greylisting. Fewer unknowns means less guesswork and less wasted list.
Consider a 10,000-address B2B list:
- Without greylisting handling: ~1,000 addresses return as "unknown" (many valid addresses misclassified)
- With intelligent greylisting handling: ~200-300 addresses return as "unknown" (only truly unverifiable addresses)
That's 700+ addresses recovered from the "unknown" bucket — addresses you'd otherwise have to guess about or discard.
What to Do with Greylisting-Flagged Results
Even with intelligent retry logic, some addresses will remain unresolvable due to aggressive greylisting configurations, intermittent server availability, or other factors. Here's how to handle them:
For Bulk List Cleaning
Addresses marked as "unknown" with a greylisting sub-status are likely valid. If the domain has good MX records, proper SPF/DKIM/DMARC configuration, and isn't on any blacklists, the address is almost certainly real. You can include these in your send with a monitoring plan — track bounces per domain and suppress if any bounce.
For Real-Time Verification
In real-time contexts (signup forms, checkout flows), accept greylisted addresses provisionally. The user is right there — don't reject a valid customer because their mail server greylists. Queue a background re-verification and handle the result asynchronously.
For High-Stakes Sends
If you're sending a critical campaign where deliverability must be maximized and every bounce matters, consider re-verifying greylisting-flagged addresses 24-48 hours later. The greylisting server may have whitelisted your verifier's IP from the first attempt, allowing the second verification to succeed.
Greylisting vs. Rate Limiting vs. Deferrals
It's worth distinguishing greylisting from other server behaviors that produce similar-looking 4xx responses:
Greylisting — Temporary rejection of unknown sender/recipient combinations. Resolves after a delay period. The server wants you to retry.
Rate limiting — Temporary rejection because the server has received too many connections in a short period. The server wants you to slow down. Common response: "452 Too many connections from your IP."
Connection deferrals — The server is too busy to handle your connection right now. This is a load issue, not a policy decision. Typically resolves quickly.
Tarpitting — The server intentionally slows down the SMTP conversation to waste the sender's time. Used against known spam sources. Not a temporary rejection — just extreme slowness.
A good verification service distinguishes between these behaviors and handles each one appropriately. Greylisting gets retried. Rate limiting gets exponential backoff. Deferrals get immediate retries. Tarpitting gets detected and abandoned.
The Bottom Line
Greylisting is a legitimate spam prevention technique that creates a specific challenge for email verification: it causes valid addresses to appear unverifiable on first contact. The quality of your verification results depends directly on how your verification tool handles this challenge.
If you're seeing a high percentage of "unknown" results in your verification reports — particularly concentrated on certain domains — greylisting is the likely cause. Switching to a verification service with intelligent greylisting handling, like SendSure, will recover a significant portion of those addresses and give you a more accurate picture of your list's true health.
Speed matters for real-time checks. Accuracy matters for list cleaning. The right tool gives you both without forcing a compromise.
