A message can show a temporary failure before a later delivery. Greylisting is one possible cause. Throttling and other temporary problems can produce the same status class.
How does greylisting work?
A receiver temporarily defers an unfamiliar sending client and checks whether a later attempt qualifies as a retry.
RFC 6647 describes this anti-abuse technique. Software that never retries cannot complete delivery through that check.
The receiver returns a temporary SMTP failure, leaving the sending system responsible for retaining and retrying the message. Passing the retry test removes that obstacle. The receiver's other filtering rules still apply.
How does the receiver recognize a retry?
The receiver compares information from the new attempt with a record of the earlier one.
RFC 6647 recommends tracking the sending IP, envelope sender and first recipient. The envelope sender is the address used for delivery-failure notices.
A change to those identifiers can make a retry look like a new message. Sending from several servers can therefore complicate matching, depending on the receiver's policy.
The RFC recommends allowing further traffic from the IP after a successful retry. It also recommends expiring inactive records, so that permission need not last indefinitely.
Why can greylisting stop some unwanted mail?
It stops sending software that makes one attempt and abandons a temporary failure.
The technique tests retry behavior. It does not establish whether the message content is safe or wanted. Abusive software that retries can pass it too.
A receiver therefore needs other filtering signals. Successfully passing greylisting does not establish authentication, consent or a good sending reputation.
How long can the delay last?
The delay depends on when the sender retries and which attempts the receiver accepts as timely.
RFC 6647 recommends a default retry window from one minute to 24 hours to accommodate typical retry schedules. This is a receiver-side range for recognizing retries. It does not promise delivery within that period.
For example, a retry after 30 seconds is too early for that default window. A retry after 30 hours can be treated as a new attempt. A qualifying retry still faces the receiver's other checks.
A sender that retries only after an hour cannot deliver through the check sooner. For a passcode expiring after ten minutes, that delivery arrives after the code becomes unusable.
How do you distinguish greylisting from another failure?
Use the reply details and retry history. A temporary status code alone does not prove greylisting.
| Observation | What it establishes |
|---|---|
4xx, then successful delivery | A temporary failure cleared. Greylisting is one possible cause |
Repeated 4xx replies until expiry | Delivery never completed. The reply text and retry pattern can help identify why |
5xx reply | A permanent failure for that SMTP request |
RFC 6647 discusses 421 when terminating the connection and 450 otherwise. It does not prescribe reply wording, so text need not explicitly name greylisting.
Deferred email and bounces describe the temporary and final outcomes.
What should the sending operator investigate?
Confirm that the message is retried and that its identifying information remains suitable for the receiver's matching policy.
Check whether retries change the envelope sender or move between sending IPs. Also check whether different receiving MX servers recognize the same retry history.
RFC 6647 recommends that receiving servers share a greylisting database, because a retry can reach a different destination. A mismatch can repeatedly delay legitimate mail.
Provide the receiving operator with attempt times, IPs and reply text when the delay persists. The RFC supports receiver-managed exceptions for legitimate senders that do not work well with greylisting.
Should a receiver greylist authenticated submissions?
RFC 6647 recommends that operators exclude authenticated clients of their own submission service from greylisting. Those clients have already authenticated to submit mail, so testing whether an unfamiliar sender retries adds an avoidable delay. Apply the rule at the receiving or submission service that controls it.
For an application using a sending platform, review the message's delivery result. Creating another application send does not repair the first attempt's greylisting match. It can produce duplicates.
In short
Greylisting tests retry behavior.
A temporary failure asks the sending server to try again. It does not establish a permanent rejection.
A retry does not guarantee acceptance.
The attempt must satisfy the receiver's timing and identity checks, along with its other mail policies.
Timing depends on both servers.
The receiver's retry window and the sender's schedule jointly determine the delay.
Repeated deferrals need investigation.
Check reply details, retries and changing sender identifiers before concluding the cause is greylisting.