How Greylisting Works
Greylisting is formally defined in RFC 6647 — Email Greylisting: An Applicability Statement for SMTP, published by the IETF in 2012. It doesn't inspect message content at all. Instead, it exploits a behavioral gap between real mail servers and spam senders.
Per RFC 6647, the receiving server records a triplet for every inbound connection: the sending server's IP address, the envelope sender (MAIL FROM), and the first envelope recipient (RCPT TO). RFC 6647 notes that tracking only the first recipient is sufficient, since compliant MTAs preserve recipient order across retries.
When a triplet is seen for the first time, the server issues a temporary SMTP failure — a 4xx response — instead of accepting or permanently rejecting the message. RFC 5321 §4.5.4.1 requires SMTP clients to queue mail after a 4xx response and retry delivery later, so a properly configured legitimate sender complies automatically.
The default parameters recommended in RFC 6647:
| Parameter | RFC 6647 default | What it controls |
|---|---|---|
| Retry window | 1 minute – 24 hours | Retries in this window count as valid; the connection is accepted |
| Retry too soon | Rejected again | Retrying inside the first minute is treated as another new attempt |
| Retry too late (>24h) | Timestamp resets | Treated as a brand-new triplet, delay starts over |
| Record retention | ≥ 1 week | How long an inactive triplet stays in the greylist database |
| Whitelist duration | 30–90 days (implementation-specific) | How long a proven triplet skips greylisting |
This table interprets RFC 6647's own recommended defaults; specific mail servers (Postfix postgrey, Exim greylistd, Barracuda, etc.) can tune these values, so actual delay windows vary by provider.
Why It Delays Legitimate Email
Most SMTP servers (Postfix, Exchange, Sendmail) retry a 4xx failure within a few minutes automatically, so the typical delay for a legitimate first-contact email is under 15 minutes. But delays stretch out in a few common scenarios:
-
Load-balanced outbound mail pools. If a sender rotates between multiple outbound IPs (common with ESPs like SendGrid or Mailgun), the retry can come from a different IP than the original attempt. Since the triplet includes IP address, this looks like a brand-new sender and the deferral repeats.
-
Custom retry intervals. Some MTAs back off retries by 15 minutes, 1 hour, then 4 hours. If the receiving greylist's window is narrow, the second attempt can land outside it.
-
First contact with a new recipient. Every new sender-recipient pair is greylisted once, even if the sender's IP is already trusted elsewhere on that same server — because the triplet includes the recipient address too.
-
Transactional/OTP mail. Time-sensitive mail (password resets, 2FA codes, signup confirmations) is the most visible casualty, since users expect delivery in seconds, not minutes.
Greylisting vs Blacklisting vs Allowlisting
| Method | Action on first contact | Spam effectiveness | False-positive risk |
|---|---|---|---|
| Greylisting | Temporary 4xx reject, retry required | Moderate — stops non-compliant spam tools | Delays legitimate mail 1–60 min |
| Blacklisting (DNSBL) | Permanent reject if IP/domain is listed | High for known bad actors | Can block legit senders on shared IPs |
| Allowlisting | Always accept, no check | None on its own | Requires manual trust management |
| Greylisting + allowlist | Reject once, then trust the triplet | Moderate, self-tuning over time | Only the first message per pair is delayed |
Most production mail servers combine all three: DNSBL blacklist checks reject known-bad IPs outright, greylisting screens unknown senders, and a rolling allowlist means the delay only ever hits the first message between a given sender and recipient.
Popular open-source implementations include postgrey (Postfix), greylistd (Exim), and Milter-Greylist, while commercial gateways like Barracuda, Proofpoint, and Microsoft Exchange Online Protection bundle greylisting-style deferral into their broader anti-spam scoring rather than exposing it as a standalone toggle. That's why two domains hosted on similar-looking mail platforms can show very different delay behavior for the same sending IP.
Common Errors and Log Lines
Greylisting shows up in mail logs and bounce messages as a temporary (4xx) failure, not a hard bounce. The exact strings vary by mail server software:
451 4.7.1 Greylisted, please try again in 00:05:00
451 4.7.1 <sender@example.com>: Sender address rejected: Please try again later
451 4.3.2 Please try again later
450 4.2.0 <recipient@domain.com>: Recipient address rejected: Greylisted
Postfix with postgrey typically logs:
postgrey[1234]: action=greylist, reason=new, client_name=mail.example.com, client_address=203.0.113.10, sender=user@example.com, recipient=you@yourdomain.com
A retry that succeeds logs action=pass for the same triplet. If you never see action=pass for a given sender, the retry either never happened or arrived from a different IP/outside the retry window — the two most common root causes of a "stuck" greylisting delay.
How to Diagnose a Greylisting Delay
-
Confirm it's a 4xx, not a 5xx.
A 4xx (temporary) code means the message is queued and will retry. A 5xx code is a permanent rejection unrelated to greylisting — check SPF/DKIM/DMARC alignment instead with the SPF Checker and DMARC Checker.
-
Check the sending server's mail queue.
On Postfix,
mailqorpostqueue -pshows deferred messages with the exact 4xx reason string from the receiving server. -
Verify the retry came from the same outbound IP.
Pull the message headers with the Email Header Analyzer and compare the
ReceivedIP on the first attempt against the retry. If they differ, the triplet reset and the message was greylisted again from scratch. -
Check MX record health.
Confirm the recipient's mail servers are reachable and correctly configured using MX Record Lookup — greylisting delays are sometimes misdiagnosed when the real issue is an MX misconfiguration.
How to Fix or Avoid Greylisting Delays
-
Use a consistent outbound IP or IP range for a given domain's mail stream. If you're on a shared ESP, ask whether they support IP pool stickiness for transactional mail — it prevents the "new IP = new triplet" reset.
-
Respect standard retry queues. Don't disable or shorten your MTA's default retry backoff; RFC 5321-compliant queuing is what makes greylisting transparent in the first place.
-
Ask the recipient's admin for allowlisting if you run high-volume transactional or time-sensitive mail (OTPs, password resets) to a domain that greylists — most greylisting implementations support a permanent allowlist entry per sending IP or domain.
-
Warm up new sending infrastructure gradually. A brand-new IP hitting many domains for the first time will get greylisted everywhere simultaneously; established IPs with sending history accumulate allowlist entries over time and stop seeing delays.
-
Don't confuse greylisting with authentication failure. Fixing SPF, DKIM, or DMARC won't resolve a greylisting delay — those are separate checks. Run the SPF Checker and DMARC Checker to rule out an alignment problem before assuming greylisting is the cause.
-
Set outbound queue alerts, not just inbound ones. If your MTA can alert on messages stuck in the deferred queue for longer than your expected greylisting window (typically over an hour), you'll catch retry-IP mismatches before a customer complains about a missing password-reset email.
Stop checking manually. DNSnexus Monitor watches your DNS records, SSL expiry, email auth, and blacklist status — and alerts you before things break. Free tier covers one domain.
Key Takeaways
- ✓ Greylisting is defined in RFC 6647; it tracks a triplet of sender IP,
MAIL FROM, andRCPT TO. - ✓ The default retry acceptance window is 1 minute to 24 hours; RFC 5321 requires compliant servers to queue and retry after a 4xx response.
- ✓ Typical delay for legitimate mail is under 15 minutes to about an hour, not hours or days.
- ✓ Retries from a different outbound IP reset the triplet and trigger another delay — the most common cause of "stuck" greylisting.
- ✓ A 4xx code means temporary deferral; a 5xx code is unrelated to greylisting and points to a hard authentication or configuration failure.
Frequently Asked Questions
Q: What is email greylisting?
Greylisting is an anti-spam technique that temporarily rejects mail from an unrecognized sender with an SMTP 4xx code, per RFC 6647. Legitimate servers retry automatically and the message is accepted, usually within minutes.
Q: Why is my email delayed by greylisting?
Your message hit a receiving server's greylist because the sender IP, MAIL FROM, and RCPT TO triplet hadn't been seen before. The delay resolves once your mail server's automatic retry succeeds, typically in 1–60 minutes.
Q: What does SMTP error 451 4.7.1 mean?
451 4.7.1 is a temporary (4xx) SMTP rejection, commonly used for greylisting. It tells the sending server to queue the message and try again later — it is not a permanent bounce.
Q: How long does greylisting delay an email?
Most implementations use RFC 6647's default 1-minute-to-24-hour retry window. In practice, standard MTA retry backoffs mean delivery usually completes in under 15 minutes to an hour.
Q: Does greylisting stop working after the first email?
Yes, for that sender-recipient pair. After a successful retry, most greylisting implementations add the triplet to a temporary allowlist — commonly 30 to 90 days — so subsequent mail is not delayed again.
Q: Can greylisting cause permanent email loss?
Rarely, and only if the sending server is misconfigured to not retry 4xx failures, or retries occur outside the accepted window (e.g., using a different outbound IP each time). RFC 5321-compliant servers always retry.
Q: Is greylisting the same as being blacklisted?
No. Blacklisting is a permanent rejection based on a DNSBL lookup of a known-bad IP or domain. Greylisting is a temporary, content-blind delay applied to any new sender, regardless of reputation.
Q: How do I check if greylisting is causing my delivery delay?
Look for a 4xx (not 5xx) response in your mail server's queue or bounce logs, with wording like "greylisted" or "try again later." Confirm with the Email Header Analyzer that the retry came from the same outbound IP as the first attempt.
Next Steps
If greylisting delays are affecting transactional or time-sensitive mail, start by ruling out authentication issues with the SPF Checker and DMARC Checker, then confirm the recipient's mail infrastructure with MX Record Lookup. For a deeper dive into email authentication, see SPF Record Explained, DMARC Policy Enforcement Guide, and the Email Deliverability Triage Checklist. If you're troubleshooting broader transport security, MTA-STS Explained covers how encrypted delivery interacts with mail server trust.