Understanding email greylisting and how it works
Michael Ko
Co-founder & CEO, Suped
Published 24 Jun 2025
Updated 21 May 2026
8 min read
Summarize with
Email greylisting is a temporary SMTP deferral. The receiving mail server refuses a first delivery attempt with a soft failure, then accepts the message when the sending server retries after a short delay. The basic idea behind greylisting is simple: real mail servers queue and retry mail, but low-effort spam software often gives up.
I treat greylisting as a delay signal, not as proof that the sender is bad. It is different from a hard rejection, a spam-folder decision, a DMARC failure, or a blacklist (blocklist) listing. A greylisted message is still in play. The sender has work to do: keep the message queued, retry properly, and keep authentication and DNS clean enough that the next attempt looks normal.
The direct answer is this: greylisting works by remembering a first-time sender pattern, temporarily rejecting that first attempt, and accepting a later retry if the sender behaves like a standards-compliant mail server. The delay is often minutes, but the exact timing depends on the recipient's mail system and the sender's retry schedule.
How greylisting works
A receiving server usually evaluates a combination of the sending IP, envelope sender, and recipient address. People often call this the greylisting triplet. When the triplet is new, the receiving server returns a temporary SMTP response such as 451 or 4.7.1. A proper sender does not treat that as a final failure. It keeps the message in the queue and tries again.
Flowchart showing a first email attempt deferred, retried, then accepted.
After the retry succeeds, many greylisting systems cache that sender pattern for a period of time. Future messages with the same pattern pass without the same delay. This is why greylisting feels most visible during a first contact, a new campaign, a new sending IP, a new vendor setup, or a cold transactional path.
Typical SMTP greylisting responsetext
S: 220 mx.recipient.example ESMTP C: EHLO mail.sender.example C: MAIL FROM:<bounce@example.com> C: RCPT TO:<person@recipient.example> S: 451 4.7.1 Please try again later # A compliant sender queues the message and retries later.
- Sender IP: the connecting server address is part of the first-time pattern.
- Envelope sender: the SMTP return path helps the receiver identify the stream.
- Recipient address: the target mailbox can be included so one user does not whitelist every path.
- Retry timing: the sender must retry after the receiver's minimum delay, then continue within the queue lifetime.
What greylisting looks like in practice
The most common user-visible symptom is a delayed first message. A password reset, invoice, signup confirmation, or first reply arrives late, then later messages arrive normally. That pattern is a strong greylisting clue because the recipient accepted the mail after retry instead of returning a final bounce.
Do not treat every delay as greylisting
Greylisting has a specific SMTP shape: a temporary 4xx response followed by a later accepted retry. If the message gets a 5xx response, disappears into spam, or never leaves your outbound queue, look at a different cause.
|
|
|
|---|---|---|
4xx then accepted | Greylisting | Retry log |
5xx rejection | Hard block | Bounce text |
Accepted then spam | Filtering | Headers |
Queue stuck | Sender issue | MTA logs |
Fast symptom mapping for email delays.
A blacklist or blocklist issue behaves differently. A listed IP or domain often receives a clear rejection, degraded placement, or repeated filtering across many recipients. If you need the wider background, this email blacklist explainer covers that separate failure mode.
Greylisting compared with blocking
Greylisting is temporary by design. Blocking is a refusal or filtering decision. The confusion matters because teams waste time changing SPF or DMARC records when the real event was a normal retry challenge, or they ignore a serious blocklist (blacklist) hit because they assume everything is only greylisting.
Greylisting
- SMTP result: temporary 4xx response.
- Sender action: queue and retry.
- User impact: delayed first delivery.
- Fix focus: retry behavior and sender hygiene.
Blocking
- SMTP result: often final 5xx response.
- Sender action: fix cause before retrying.
- User impact: failed or filtered delivery.
- Fix focus: reputation, policy, or abuse signals.
When delay and reputation signals overlap, I check blocklists and authentication side by side. A greylisting retry can succeed even when a reputation problem exists elsewhere, so the cleanest diagnosis uses SMTP logs, headers, and domain checks together.
Why legitimate senders get greylisted
Legitimate senders get greylisted because the recipient has not seen that exact sending pattern before, or because the sender looks new enough that a short pause is useful. It does not mean the sender is malicious. It means the receiver wants proof that the sender has a real queue and will come back.
Common greylisting retry windows
Actual timing depends on the recipient system, but these ranges match common operational patterns.
Too soon
0-5 min
Retry arrives before the receiver's minimum wait.
Normal
10-30 min
Retry lands inside many common greylisting windows.
Slow
1-4 hr
Delivery still works, but user-facing delay is obvious.
Problem
4+ hr
Investigate queue policy, network issues, or repeated deferrals.
- New infrastructure: a new IP or outbound host has no delivery history with the recipient.
- First contact: the recipient has never seen that sender and mailbox combination.
- Burst traffic: a sudden batch can trigger more cautious handling.
- Weak identity: poor reverse DNS, odd HELO names, or inconsistent authentication increase friction.
- Bad retry policy: retries that are too aggressive or too sparse make greylisting worse.
Authentication still matters
Greylisting itself is not an SPF, DKIM, or DMARC failure. Still, weak authentication makes the sender harder to trust after the retry. Clean authentication reduces the number of other reasons a receiver has to slow, filter, or reject mail.
How to diagnose greylisting
I start with the SMTP transcript or MTA log, not the inbox complaint. The key question is whether the recipient returned a temporary response and later accepted the same message. Without that evidence, greylisting is only a guess.
- Capture result: find the first SMTP status code and enhanced status code.
- Confirm retry: verify that the sender queued the message and tried again.
- Compare timing: check whether the retry happened after the receiver's wait period.
- Check acceptance: look for a later 250 response, final bounce, or continued deferral.
- Separate causes: check authentication, DNS identity, and reputation if deferrals continue.
A practical test is to send a real message and inspect the headers, authentication results, and delivery path. Suped's email tester helps with that part of the workflow because it shows whether the sender's SPF, DKIM, DMARC, and message structure look healthy.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For a broader check, I also use a domain health checker to catch missing DNS records, broken authentication, and other issues that make greylisting harder to separate from real delivery problems.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
How to reduce greylisting delays
You cannot force a recipient to turn off greylisting, but you can make your mail easier to accept after the retry. The biggest improvement is boring reliability: stable infrastructure, correct DNS identity, standards-compliant retries, and clean authentication.
Best practical response
Keep retry behavior conservative. Retrying too fast can keep hitting the greylist window, and retrying too slowly creates user-facing delays. A normal mail queue with gradual backoff is the right pattern.
Example Postfix retry settingstext
# Example only. Test changes before production use. queue_run_delay = 300s minimal_backoff_time = 300s maximal_backoff_time = 4000s maximal_queue_lifetime = 5d
- Use stable IPs: avoid unnecessary outbound IP changes for established mail streams.
- Fix reverse DNS: make PTR, forward DNS, and HELO identity look consistent.
- Authenticate mail: publish working SPF, sign with DKIM, and enforce DMARC gradually.
- Warm new paths: introduce new IPs, domains, and vendors with predictable volume.
- Monitor bounces: separate 4xx deferrals from 5xx rejections and spam-folder placement.
Where DMARC and Suped fit
DMARC does not stop greylisting by itself. SPF and DKIM passing also do not guarantee that a recipient skips greylisting. What authentication gives you is a cleaner sender identity, which helps when the receiver decides what to do after the retry.
Suped is useful here because greylisting rarely appears in isolation. Teams need to know whether a delay came from retry behavior, failed authentication, a new sender source, or a reputation issue. Suped's product brings DMARC monitoring, SPF and DKIM visibility, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, and blocklist monitoring into one workflow.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
For most teams running DMARC operations, Suped is the strongest practical choice because it turns raw reports into issue detection, clear fix steps, and alerts. That matters when someone reports delayed mail and the team needs to rule out authentication drift before blaming greylisting.
Without joined monitoring
- Slow triage: logs, DNS, and reports live in separate places.
- Missed changes: new sending sources appear after incidents start.
- Weak evidence: teams guess whether delay, rejection, or filtering occurred.
With Suped
- Clear sources: verified and unverified senders are visible.
- Actionable fixes: issues include steps to correct DNS and policy.
- Real-time alerts: authentication failures surface before they become a wider incident.
When greylisting points to a deeper issue
Greylisting should resolve after a compliant retry. If the same domain keeps seeing long delays, repeated deferrals, or hard failures, treat it as a broader deliverability incident. At that point, the question changes from "what is greylisting" to "why does the receiver keep distrusting this mail stream".
|
|
|
|---|---|---|
Many 4xx | Retry issue | Queue review |
Mixed 5xx | Blocking | Bounce review |
Auth fails | Identity gap | DNS fix |
Listing found | Reputation | Blocklist fix |
Escalation clues after repeated greylisting.
The most common escalation mistake is retrying harder. More connection attempts do not create trust when the receiver has already asked you to wait. Fix identity, clean lists, separate transactional and marketing streams, and keep the retry pattern predictable.
My practical view
Greylisting is a controlled pause. It works because legitimate mail servers retry and weak spam tools often do not. A normal greylisting event has a first temporary deferral, a queued retry, and later acceptance.
The right response is to verify the SMTP evidence, keep retry behavior sane, and make sender identity clean enough that the retry succeeds. When greylisting sits next to DMARC failures, sender drift, or blocklist and blacklist concerns, Suped gives teams one place to connect those signals and act on the right cause.
