Email greylisting is an anti-spam technique in which receiving mail servers temporarily reject emails from unknown senders and wait to see whether the sending server tries again.
Legitimate mail servers retry automatically (usually within 15 minutes), whereas spam servers typically don’t.
As a result, most mass spam never arrives, and real emails get through with a short delay.
In this guide, we’ll be covering:
- How greylisting works at the SMTP protocol level
- The difference between greylisting, blacklisting, and whitelisting
- What high-volume senders should know about greylisting delays
- Why your emails trigger greylisting and how to reduce it
- How authentication affects greylisting behavior
How does greylisting work?
When your mail server connects to a recipient server running greylisting, the receiving server checks three pieces of information (called a “triplet”):
- Your sending IP address
- Your sender email address
- Recipient address
If this combination is new, the server returns a temporary rejection with a 4xx error code — typically 451 or 450. The temporary rejection isn’t a permanent block. It’s a request: try again later. Here’s what happens next, depending on who sent the email:
| Sender type | Behavior after rejection | Result |
| Legitimate mail server | Queues the message and retries after 15-30 minutes | Email delivered on retry |
| Standards-compliant ESP | Automatic retry per SMTP specifications | Email delivered on retry |
| Spam botnet | Usually moves on to the next target without retrying | Email never delivered |
| Poorly configured server | May not retry, or retry too quickly | Email may fail delivery |
The mechanism works because spam systems prioritize volume over persistence. Sending millions of emails and waiting for retry windows eats into the economics of spam operations. Most don’t bother.
After a successful retry, the receiving server often adds your triplet to a temporary whitelist. Future emails from the same sender-to-recipient combination pass through without delay, at least for a defined period (often 30 to 90 days).
Why does greylisting exist?
Greylisting solves a specific problem — filtering spam without inspecting email content.
Content-based spam filters (Bayesian filters, keyword analysis, link scanning) require processing power and can produce false positives.
Greylisting takes a different approach. It exploits a behavioral difference between legitimate senders and spammers — the willingness to retry — rather than analyzing the message’s contents.
The technique also buys time. When greylisting delays an email by 15 minutes, real-time blacklists and reputation databases have more time to flag newly compromised IPs.
A spam source that wasn’t blacklisted when the first delivery attempt failed might be flagged by the time the retry arrives.
For mail administrators, greylisting is attractive because it’s lightweight. Rejecting a message before accepting its body consumes almost no server resources compared to scanning attachments, running heuristics, or querying external spam databases.
What triggers greylisting?
Greylisting activates when the receiving server doesn’t recognize your sending signature. Several conditions make this more likely:
New sender IP address
If you’ve recently changed email providers, migrated to a new IP, or started sending from a domain that hasn’t sent to this recipient before, you’ll appear as an unknown sender. Your first email to any new recipient on a greylisting server will be deferred.
New domain without sending history
Domains with no established sender reputation face greylisting more frequently because receiving servers have no track record to evaluate.
Sending from server pools
Large ESPs like SendGrid, Mailgun, or Amazon SES rotate sending IPs across their infrastructure.
If your retry comes from a different IP address than your original attempt, some greylisting implementations treat it as a brand-new triplet and defer again. This can lead to delays or repeated greylisting.
Missing or weak authentication
Senders with properly configured SPF, DKIM, and DMARC often bypass greylisting entirely on servers that support authentication-based exceptions. Without authentication, you’re treated as higher risk.
Low volume or sporadic sending
Servers that send infrequently to a given domain may keep falling out of whitelist windows. If you email someone once every four months and the whitelist expires at 90 days, you’ll trigger greylisting each time.
How long does greylisting delay emails?
The delay depends on two factors:
- How long the receiving server requires before accepting a retry
- How your sending server schedules retries.
Most greylisting systems require a waiting period of 1 to 20 minutes before they accept a second attempt. Different mail server software uses different default retry schedules:
| Mail server | Default retry timing |
| Sendmail | 0, 15, 30 minutes |
| Postfix | 0, 16.6 minutes |
| Microsoft Exchange | 0, 1, 2, 22, 42 minutes |
| Exim | 0, 15, 30 minutes |
| Qmail | 0, 6:40, 26:40 minutes |
In practice, most greylisted emails arrive within 15 to 30 minutes. For well-configured servers communicating with standard greylisting implementations, the delay is typically a one-time event per sender-recipient pair.
Problems arise when:
- Your mail server doesn’t retry at all (non-RFC-compliant configuration)
- Your retry comes from a different IP than the original attempt
- The receiving server has unusually long greylist windows (some set 60+ minutes)
- Your mail server gives up before exhausting its retry queue
For time-sensitive emails — password resets, two-factor authentication codes, transactional confirmations — even a 15-minute delay can be operationally painful. The token might expire before the email arrives.
How is greylisting different from blacklisting?
Greylisting and blacklisting both filter email, but they work on completely different principles.
| Aspect | Greylisting | Blacklisting |
| Mechanism | Temporary deferral based on retry behavior | Permanent rejection based on known-bad sources |
| Target | Unknown senders (neither trusted nor known-bad) | Confirmed spam sources, malicious IPs, compromised domains |
| Recovery | Automatic — retry successfully and you’re whitelisted | Manual — requires delisting process |
| Duration | Minutes to hours | Days to weeks (or permanent) |
| Data source | Real-time behavior | Historical reputation databases |
A greylisted email isn’t rejected; it’s deferred. The receiving server is saying, “I don’t recognize you — prove you’re a real mail server by trying again.” The email will likely arrive.
A blacklisted email is rejected outright. The receiving server has decided (based on IP reputation, domain reputation, or external blocklist data) that your email shouldn’t be accepted at all. Getting off a blacklist requires identifying the problem, fixing it, and requesting removal.
Whitelisting is the opposite end of the spectrum — pre-approved senders bypass greylisting and most spam filtering entirely. Some organizations maintain internal whitelists for trusted vendors, partners, and domains they frequently communicate with.
What are the advantages and disadvantages of greylisting?
Greylisting trades a small delay for significant spam reduction — but that trade-off doesn’t work equally well for everyone. The technique shines in certain environments and creates friction in others.
Advantages
Disadvantages
How can senders reduce greylisting delays?
You can’t disable greylisting on someone else’s server, but you can minimize how often it affects your mail.
Establish proper authentication
Servers using authentication-aware greylisting often exempt senders with valid SPF, DKIM, and DMARC records.
Proper authentication signals that your domain is legitimate and your sending infrastructure is configured correctly.
Start with SPF to define which servers can send on your behalf. Add DKIM to cryptographically sign your messages. Implement DMARC to tell receiving servers how to handle authentication failures.
This trio doesn’t guarantee exemption from greylisting, but it significantly reduces how often you trigger it.
Warm up new domains and IPs
New sending infrastructure with no reputation history faces more aggressive filtering, including greylisting.
A gradual warmup process — starting with low volumes to engaged recipients and scaling over weeks — builds the sending history that helps receiving servers recognize you as legitimate.
Domain warming establishes a reputation for your domain specifically, while IP warming does the same for your sending infrastructure.
Both reduce the likelihood that receiving servers treat your email as unknown.
Use a consistent sending infrastructure
IP rotation causes problems with greylisting because retries may come from different addresses than the original attempt.
If possible, use a dedicated IP or a small, consistent pool. Ensure your mail server’s retry logic uses the same IP that made the initial attempt.
Shared sending pools (common with high-volume ESPs) can complicate greylisting. Some ESPs handle this gracefully, while others don’t.
If you’re consistently seeing greylisting-related delays, ask your provider how their retry infrastructure works.
Maintain sending frequency
Whitelist entries expire. If you email a recipient once every six months and the receiving server’s whitelist window is 90 days, you’ll repeatedly trigger greylisting. Regular (but not excessive) sending keeps your triplets active and reduces the likelihood of re-greylisting.
This doesn’t mean sending more emails than you need. It means understanding that dormant sender-recipient relationships fall out of whitelist windows.
Monitor and troubleshoot systematically
Use tools like Google Postmaster Tools and Microsoft SNDS to track reputation and delivery patterns.
Check your mail server logs for 4xx responses, particularly 450 and 451 codes, which indicate greylisting or temporary deferrals.
If greylisting becomes a persistent problem with specific recipients, the fix may require coordination.
Some organizations will whitelist legitimate business contacts to avoid the delay entirely.
How does greylisting interact with other spam filtering?
Greylisting is one layer in a multi-layered filtering stack. Most modern mail servers combine several techniques:
Where each check fits
Greylisting typically runs early in this stack because it’s cheap and doesn’t require full message processing. An email might pass greylisting but still fail content analysis. Or it might pass authentication checks and bypass greylisting entirely.
The layered approach means deliverability isn’t about defeating any single filter. It’s about maintaining good standing across all of them.
When greylisting points to deeper problems
Occasional greylisting is normal, especially when emailing new recipients or after changing the sending infrastructure. But persistent greylisting — or greylisting combined with other delivery failures — often signals systemic issues.
Authentication gaps
If greylisting resolves after authentication improvements, the root cause was missing SPF/DKIM/DMARC. The greylisting was a symptom.
Reputation damage
Senders with a poor reputation face stricter filtering across the board, including longer greylist windows, more frequent re-greylisting, and higher rejection rates. Blacklist status should be checked if greylisting becomes chronic.
Infrastructure misconfiguration
Mail servers that don’t retry properly, or retry from different IPs, turn temporary greylisting into permanent delivery failure. The problem isn’t greylisting — it’s your sending setup.
List quality issues
Sending to invalid addresses, spam traps, or unengaged recipients damages reputation and increases the likelihood of being filtered. Email list hygiene affects how receiving servers perceive all your traffic.
Deliverability is a system
Greylisting is one signal within that system. When greylisting delays become a recurring headache, the productive response is to audit your entire sending infrastructure, not just work around individual deferrals.
Stop chasing email errors — fix the system causing them
Greylisting is one symptom of a larger deliverability problem. When your emails face repeated deferrals, authentication failures, or reputation issues, the root cause usually isn’t a single setting — it’s a gap in your sending infrastructure that no one has diagnosed.
EmailWarmup.com runs a complete deliverability audit that surfaces what’s actually broken:
- Sending patterns that raise red flags
- Reputation damage across domains and IPs
- Infrastructure vulnerabilities triggering filters
- Authentication gaps (SPF, DKIM, DMARC misconfigurations)
Then you get the tools and expert guidance to fix everything — not just one piece.
Talk to a deliverability expert today for free.
Frequently asked questions
Here are some commonly asked questions about greylisting:
No. Greylisting is a temporary deferral, not a rejection. Your mail server queues the message and retries automatically. Most greylisted emails deliver successfully within 15 to 30 minutes.
You can’t disable greylisting on someone else’s server. But proper authentication (SPF, DKIM, DMARC), established sender reputation, and consistent sending infrastructure significantly reduce how often you trigger it.
If your sender-recipient triplet already exists in the receiving server’s whitelist (from previous successful deliveries), greylisting doesn’t apply. New recipients or lapsed relationships trigger the delay.
No. Large providers like Gmail and Microsoft use sophisticated reputation systems that may bypass traditional greylisting for authenticated, reputable senders. Smaller mail servers and enterprise systems are more likely to run standard greylisting implementations.
Typically, 30 to 90 days, depending on the receiving server’s configuration. After expiration, the next email to that recipient triggers greylisting again.
For business-critical relationships, yes. Manual whitelisting bypasses greylisting entirely. For broad marketing or outreach, it’s not practical — focus on authentication and reputation instead.
