SMTP 421 means 'try again later'. The receiving server is not refusing your message; it is signalling that it is throttling, in maintenance, or temporarily unable to accept new mail. Retrying is the right response, but the retry policy determines whether you help or hurt your sender reputation.
Retrying too quickly turns a temporary throttle into a reputation event. The receiving server's throttle is a signal that you are sending too fast; retrying on the same schedule amplifies the problem. Exponential backoff with jitter is the standard remedy.
Retrying forever is also wrong. Bound the attempt count or elapsed retry window, retain the enhanced status and diagnostic text, and alert when repeated temporary failures point to a persistent routing, TLS, or reputation problem.
For PulsePigeon's HTTP API, a 429 response carries rate or warm-up backpressure and may include Retry-After; 5xx responses are transient platform errors. The published SDKs define typed rate-limit and server errors; direct REST callers should classify the documented HTTP response. Consult the HTTP API error reference and SDK method reference for that HTTP interface; these guides do not define the SMTP server's retry schedule.
Deferred delivery events are part of PulsePigeon's reputation model. A deferred rate above 20% blocks warm-up advancement, which keeps sustained temporary failures from being hidden by successful accepts at the API boundary.