SMTP 421 temporary deferral: distinguish retryable refusal from uncertain send

Define the decision

A 4xx response indicates a temporary SMTP failure, but the application also needs to know whether the message was accepted. A lost connection after message data can leave an uncertain outcome that should not be treated like a clear pre-acceptance refusal.

Work through the procedure

1. Record the complete response, SMTP stage and attempt identifier.
2. Separate explicit temporary refusal from an unknown acceptance result.
3. For a clear refusal, follow provider retry guidance and reduce the pressure causing the deferral.
4. For an uncertain attempt, inspect provider evidence before authorizing a resend.

Worked example

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

Attempt A: explicit 421 before message submission → temporary refusal
Attempt B: connection lost while waiting for final acceptance → uncertain outcome
Operator decision: these attempts belong in different recovery queues

Read the result

This separation prevents duplicate contact during recovery. The number alone does not reveal whether the cause is load, connection limits or another temporary policy.

Check before moving on

1. Check whether several campaigns share the same mailbox.
2. Keep retries bounded and visible to the campaign owner.

Limits and next action

Zintara’s campaign recovery should respect uncertain-send state. Do not manually reset a paused attempt merely because another connection test now succeeds.

Source: RFC 5321: reply classes and retry context