A 451 4.7.1 "greylisted" response means the receiving server deliberately rejected your first delivery attempt with a temporary error, betting that spam software won't retry but a real mail server will. Nothing is wrong: a properly configured MTA retries automatically within minutes and the mail goes through, you only have a problem if your sender doesn't retry or retries from changing IPs.
What the response looks like
451 4.7.1 <[email protected]>: Recipient address rejected:
Greylisted, see http://postgrey.schweikert.ch/help/example.org.html
Wording varies, "Greylisted", "try again later", "temporarily deferred, retry in 300 seconds", but the mechanism is the same on Postgrey, rspamd, SpamAssassin-MTA setups, and many corporate gateways.
How greylisting works
The receiver records a triplet on first contact and rejects with a 4xx:
| Triplet element | Why it's tracked |
|---|---|
| Sending IP (often the /24) | The retry must come from the same place |
| Envelope sender (MAIL FROM) | The same message must be retried, not a new one |
| Envelope recipient (RCPT TO) | Per-recipient tracking |
If the same triplet returns after the minimum delay (commonly 1-10 minutes) and within the window (hours to days), the mail is accepted and the triplet is whitelisted, future messages pass instantly. Spam cannons that fire-and-forget never come back, which is the entire filter.
When greylisting becomes an actual problem
For a normal MTA, greylisting costs a few minutes once per sender/recipient pair. It breaks in three specific setups:
1. Senders that don't retry
Homegrown PHP scripts, cron jobs using sendmail -t direct submission hacks, and some lightweight libraries treat any 4xx as a hard failure. The message dies on attempt one. Fix: send through a real MTA (Postfix, etc.) or an SMTP relay that queues, never deliver directly from application code.
2. Retries from rotating IPs
Large sending pools can retry from a different IP than the original attempt. The triplet never matches, every attempt looks like a first attempt, and the mail loops until queue expiry. Fix: pin a message's retries to one IP, or use a provider whose pool retries consistently (most reputable ones handle this).
3. Retry intervals that miss the window
An MTA whose first retry comes after the greylist record expired starts the cycle over. Postfix defaults are safe, but check if you've tuned them:
# /etc/postfix/main.cf - sane retry pacing
minimal_backoff_time = 300s
maximal_backoff_time = 4000s
queue_run_delay = 300s
A 5-minute first retry passes virtually every greylisting implementation.
Confirm greylisting is what's happening
grep "451" /var/log/mail.log | tail -10
# then check the same message ID later:
grep "status=sent" /var/log/mail.log | grep <queue-id>
A 451 followed minutes later by status=sent for the same queue ID is greylisting working normally. A 451 repeating for hours on the same recipient is one of the three failure modes above, or not greylisting at all (rate-limit deferrals like Yahoo's TS codes and 421 connection throttles read similarly but need different fixes).
Reducing how often you get greylisted
Modern implementations skip greylisting for senders that look established. You get exempted faster with:
- Valid rDNS/PTR matching your HELO hostname
- SPF that passes, several implementations (including Postgrey-style setups with SPF whitelisting) skip greylisting for SPF-passing senders
- Consistent sending IPs with history, another reason warm, stable IPs beat rotating ones; see our IP warm-up schedule
Time-sensitive mail (OTPs, password resets) suffers most from the delay. For those streams, the practical answer is maximal reputation, established IP, full authentication per our SPF/DKIM/DMARC guide, so receivers exempt you, plus a tight minimal_backoff_time so unavoidable greylists clear in ~5 minutes.
Should you run greylisting on your own inbound server?
Worth a brief word for senders who also receive. Greylisting still blocks a meaningful slice of low-effort spam for near-zero CPU, but its value has declined: modern spam software retries, and the 5-15 minute delay on first-contact legitimate mail annoys users who expect instant OTPs. The current consensus setup is selective greylisting, apply it only to senders with no SPF, no rDNS, or a poor reputation score (rspamd's greylist module does this scoring natively), and exempt everyone who looks like a real MTA. Blanket greylisting of all first-time senders is a 2008 default that mostly delays mail you wanted.
How BulkEmailSetup helps
Our dedicated SMTP servers retry from consistent, pre-warmed IPs with rDNS and SPF already aligned, the exact profile greylisting implementations whitelist on sight. Transactional mail clears in minutes, not hours; see pricing.
Frequently asked questions
What does 451 4.7.1 greylisted mean?
The receiving server deliberately rejected your first delivery attempt with a temporary error and recorded your sender/recipient/IP triplet. When your server retries after a few minutes, the message is accepted, the test is whether you retry at all.
How long does greylisting delay email?
Typically 5 to 15 minutes: the greylist window (1-10 minutes on most implementations) plus your MTA's retry interval. After the first successful pass, the triplet is whitelisted and subsequent mail flows without delay.
Why does my greylisted mail never get delivered?
Either your sending system doesn't retry (common with homegrown scripts and some API-based senders), or each retry comes from a different IP so the triplet never matches. Fix the retry behavior or pin retries to consistent IPs.
Can I avoid greylisting entirely?
Mostly, yes, established IPs with good reputation, valid rDNS, and SPF records are commonly exempted by modern greylisting implementations. New and low-reputation IPs get greylisted the most.
