What the bounce says
Exact wording as it appears in the rejection or NDR. Placeholders such as x.x.x.x and example.com stand for your own address and domain.
451 4.7.1 Greylisting in action, please come back later 451 4.7.1 Please try again later 451 4.7.1 <user@example.com>: Recipient address rejected: Greylisted, see https://postgrey.schweikert.ch/help/example.com.html
Greylisting rejects the first delivery attempt from an unfamiliar sender with a temporary error and accepts the retry. It filters spam sources that never retry. For legitimate mail it means a delay of a few minutes to an hour on first contact, then normal delivery.
Most common causes
- First message from this IP, sender and recipient combination
- The receiver uses greylisting for all unknown senders
- A sending platform rotated to a new IP
- Retry interval too short for the greylist window
What to verify next
- Do nothing; a compliant server retries within minutes and delivery succeeds
- Ensure your server retries rather than bouncing on 4xx
- If delays are unacceptable, ask the recipient to whitelist your IP
- Persistent 451 beyond an hour is not greylisting; read the text
How it works
The receiver records the sending IP, envelope sender and recipient. The first attempt is deferred. When the same triple returns after a minimum delay, it is accepted and remembered. Subsequent mail from the same combination passes immediately.
Problems arise when the retry comes from a different IP — sending pools rotate addresses — so the triple never matches and every attempt is treated as first contact.
- First attempt deferred, retry accepted.
- Sending pools with rotating IPs can be deferred repeatedly.
- Delay is minutes to an hour on first contact.
What senders should do
Nothing, usually. Ensure the mail server retries on 4xx rather than bouncing. If your platform rotates IPs, ask the recipient to whitelist your range, or use a platform with stable IPs for that recipient.
When it is not greylisting
A 451 that persists for hours from the same receiver is a different deferral — reputation or rate — dressed in the same code. Read the text; greylisting implementations usually name themselves.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- Delay depends on the sender’s retry schedule.
- Some receivers greylist only unknown or suspicious senders.
Common questions
Is mail lost?
No, as long as the sender retries. Compliant servers do.
Can I avoid it?
Stable sending IPs and good reputation reduce greylisting; some receivers skip it for authenticated, well-known senders.
Why is only one recipient affected?
Greylisting is a receiver-side choice; that organization uses it and others do not.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review RFC 6647 — Email Greylisting.