SMTP 451 and greylisting: verify the reason before retrying

Define the decision

Not every 451 response means greylisting. Temporary local processing errors, policy checks and resource issues can use the same basic code. The rejecting host’s explanation and the point of refusal determine the next step.

Work through the procedure

1. Capture the full response and first-attempt time.
2. Check whether the provider explicitly describes greylisting or a retry interval.
3. Preserve sender and recipient context for an orderly later attempt.
4. Investigate repeated failures instead of creating a rapid retry loop.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

First attempt: 451, provider explicitly requests a later retry
Immediate repeated attempts: no new evidence
Planned action: bounded retry following that provider’s interval
Escalation: still failing after the expected window with the same response

Read the result

A delay can be part of normal receiver behavior, but persistence beyond the expected window deserves investigation. Compare affected recipients and sending infrastructure to determine whether the problem is broad or isolated.

Check before moving on

1. Exclude permanent failures from the retry queue.
2. Check acceptance uncertainty before resending.

Limits and next action

Do not publish a universal greylisting wait time. Follow the actual provider guidance and retain enough history to prevent duplicate attempts.

Source: RFC 5321: temporary SMTP failure handling