$ guides / postfix / postfix-greylisting-delays ▌

Operations Guides

Postfix greylisting delays: 450 4.7.1 deferrals and slow first delivery

Mail to Gmail, Yahoo, Hotmail, and other major destinations shows a consistent delay of roughly 300 seconds on first delivery. The mail log shows 450 4.7.1 or 451 4.7.1 deferrals from the destination MX. The deferred queue climbs slowly but not explosively. On retry, the messages deliver successfully. This is greylisting, not a Postfix fault.

Greylisting intentionally rejects the first delivery attempt from an unknown sender triplet (client IP, sender address, recipient address) with a 4xx temporary failure. The destination expects legitimate MTAs to retry and spam bots to give up. Postfix handles this correctly by deferring the message and scheduling a retry. The goal is to align retry timing with the destination’s greylisting window, and to whitelist trusted senders if you run postgrey for inbound filtering.

What this means

When a destination greylists your mail, the SMTP delivery agent receives a 450 or 451 response with enhanced status code 4.7.1 (delivery not authorized, message refused). Postfix defers the message rather than bouncing it.

The deferred queue scheduler (qmgr) applies exponential backoff between minimal_backoff_time and maximal_backoff_time. Defaults (since Postfix 2.4):

minimal_backoff_time: 300s
maximal_backoff_time: 4000s
queue_run_delay: 300s

Typical sequence: first attempt gets 450 4.7.1, message enters the deferred queue, qmgr waits approximately 300s, retries. If the destination’s greylisting window has also elapsed (postgrey default: 300s), the retry succeeds. Observed end-to-end delay: approximately 300s.

Do not retry faster than the destination’s greylisting window. If minimal_backoff_time is shorter than the window, premature retries can reset the destination’s timer on many implementations, causing the message to be deferred again with a fresh countdown. This can produce indefinite deferral where every retry restarts the waiting period.

flowchart TD
    A[New message queued] --> B[Delivery attempt]
    B --> C{Destination responds}
    C -->|250 OK| D[Delivered]
    C -->|450 4.7.1| E[Deferred to queue]
    C -->|Other 4xx/5xx| F[Other deferral]
    E --> G["Waits minimal_backoff_time = 300s"]
    G --> H[Retry scheduled by qmgr]
    H --> B

Common causes

Cause	What it looks like	First thing to check
Destination greylisting your IP	450/451 4.7.1 on first attempt to specific domains, success on retry after approximately 300s	Grep mail log for `4.7.1` and check delay values
New or cold IP	All major destinations greylisting uniformly, improving over days to weeks	Check IP age and recent infrastructure changes
Postgrey running locally	Inbound senders report approximately 300s delay on first message to your server	Check for postgrey process and `smtpd_recipient_restrictions`
Backoff time misconfigured	Retry interval too short resets destination timer, or too long adds unnecessary delay	`postconf -h minimal_backoff_time queue_run_delay`
Rate limiting mistaken for greylisting	4xx deferrals but no success on retry, or delays much longer than 300s	Check exact DSN codes and deferral reason text

Quick checks

All commands are read-only. Log path is /var/log/mail.log on Debian/Ubuntu, /var/log/maillog on RHEL and derivatives. On systemd-only systems without a syslog daemon, use journalctl instead.

# Current retry timing parameters
postconf -h minimal_backoff_time maximal_backoff_time queue_run_delay maximal_queue_lifetime

# Find greylisting deferrals in the log
grep -E '450 4\.7\.1|451 4\.7\.1|[Gg]reylist' /var/log/mail.log | tail -30

# Which destinations are deferring with 4.7.1
grep '4\.7\.1' /var/log/mail.log | grep -oE 'to=<[^>]+>' | sort | uniq -c | sort -rn | head -10

# Current deferred queue size
find /var/spool/postfix/deferred -type f | wc -l

# Check if postgrey is running locally
ps aux | grep '[p]ostgrey'

# Deferred and sent counts from recent log activity
# Adjust the tail count based on your log volume
tail -n 5000 /var/log/mail.log | grep -c 'status=deferred'
tail -n 5000 /var/log/mail.log | grep -c 'status=sent'

# Inspect deferred messages and their ages
postqueue -p | head -20

How to diagnose it

Confirm the greylisting pattern. Look for 450 4.7.1 or 451 4.7.1 responses followed by successful delivery on retry after roughly 300 seconds. The deferral reason text often contains “Greylist”, “try again later”, or similar.
Check which destinations are affected. Greylisting hits specific destinations consistently. If all destinations defer equally, suspect DNS failure or a network partition instead. See Postfix connection timed out: delivery deferrals to unreachable destinations.
Verify retry success. Greylisted messages should deliver on the first or second retry. If messages are still deferred after multiple retries, the problem is not greylisting. Check for rate limiting, IP reputation blocks, or TLS failures.
Check retry timing. Run postconf -h minimal_backoff_time queue_run_delay. If minimal_backoff_time is below 300s, you may be retrying before the destination’s greylisting window expires. If it is well above 300s, you are adding unnecessary delay to every deferred message.
Distinguish from rate limiting. Rate limiting deferrals use different DSN codes or reason text. They often mention “too many connections”, “rate limit”, or “throttling”. Rate limiting does not resolve on a single retry; it requires reducing your sending rate. See Postfix mail flow: injection rate outpacing delivery rate.
Check for local postgrey. If the delays are on inbound mail, check whether postgrey or another greylisting daemon is running. Inspect smtpd_recipient_restrictions for a check_policy_service entry pointing to the greylisting daemon.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Deferred queue size	Growing queue means delivery problems accumulating	Slow steady growth specific to certain domains, not explosive
Deferral rate (status=deferred)	Ratio of deferred to total delivery attempts	Sustained above 15% with 4.7.1 reason codes
Per-destination deferral count	Identifies which destinations are greylisting	Same domains repeatedly appearing in deferrals
Delay value on successful deliveries	Total time message spent in queue	Consistent approximately 300s for messages that eventually deliver
Retry timing parameters	Misconfigured backoff causes unnecessary delay or timer resets	`minimal_backoff_time` below 300s or above 600s
Delivery success rate	Confirms retries are working	Declining success rate means retries are failing, not greylisting

Fixes

Tune retry timing for faster second attempts

Ensure minimal_backoff_time and queue_run_delay align with the typical 300-second greylisting window.

# Check current values
postconf -h minimal_backoff_time queue_run_delay

# Set both to 300s if they are not already
postconf -e 'minimal_backoff_time = 300s'
postconf -e 'queue_run_delay = 300s'

# Reload to apply (safe, does not interrupt active deliveries)
postfix reload

Do not set minimal_backoff_time below 300s. Premature retries reset the destination’s greylisting timer on many implementations, causing the message to be deferred again with a fresh countdown. This can produce indefinite deferral.

Do not set it excessively high. A minimal_backoff_time of 600s or more adds unnecessary latency to every deferred message, including those deferred for transient network errors or other non-greylisting reasons.

Whitelist trusted senders if running postgrey locally

If you run postgrey for inbound filtering and legitimate senders are consistently greylisted, add them to the whitelist. Postgrey reads whitelist files at startup:

/etc/postfix/postgrey_whitelist_clients for client domains or IPs
/etc/postfix/postgrey_whitelist_clients.local for local additions
/etc/postfix/postgrey_whitelist_recipients for recipients exempt from greylisting

Add trusted sender domains or IPs to the appropriate file and restart postgrey.

Postgrey auto-whitelists clients after a number of successful deliveries (default --auto-whitelist-clients = 5). Each unique triplet (sender, recipient, client subnet) that passes greylisting counts toward this threshold.

For senders that use multiple outbound IPs (Office 365, large mailing list providers), postgrey’s default --lookup-by-subnet groups IPs by /24 to mitigate triplet fragmentation, but this is not a complete fix. Manually whitelist these senders if they are business-critical.

Accept and monitor the pattern

Some destinations will always greylist new senders. This is expected anti-spam behavior. Focus on:

Monitoring deferred queue growth rate to detect when greylisting transitions from normal to problematic. A destination that suddenly starts greylisting all your mail after previously accepting it may signal an IP reputation change or destination policy update.
Warming up new IPs gradually before sending production volume through them.

Prevention

Warm up new IPs gradually. Destinations greylist unknown IPs more aggressively. Ramp up volume over days to weeks rather than starting at full load.
Monitor per-destination deferral patterns. Track which domains show 4.7.1 deferrals and whether the rate changes over time. A sudden spike from a previously cooperative destination warrants investigation.
Keep retry parameters at sane defaults. The defaults (300s for minimal_backoff_time and queue_run_delay, 4000s for maximal_backoff_time) are well-tuned for most greylisting scenarios. Only deviate with a specific reason.
Maintain authentication records. SPF, DKIM, and DMARC help destinations verify your identity faster, which can reduce greylisting duration on some implementations.
Track deferred queue velocity, not just size. A stable queue with messages retrying and succeeding is normal during greylisting. A growing queue means retries are failing, which points to a different problem. See Postfix deferred queue growing: why mail piles up and how to drain it.

How Netdata helps

Netdata’s Postfix collector tracks queue sizes (active, deferred, hold, incoming, maildrop) at per-second resolution. For greylisting diagnosis:

Deferred queue trend shows whether the queue is stable (normal greylisting with successful retries clearing messages) or growing (a different delivery problem).
Anomaly detection on queue size flags sudden changes that may indicate a destination policy shift or IP reputation change after a previously stable pattern.
Cross-collector correlation lets you overlay Postfix queue metrics with DNS resolver latency, network throughput, and system load to rule out competing root causes that produce similar symptoms.