Adaptive throttling on 4xx SMTP responses

SMTP 421 and 450 responses are explicit instructions from the receiving mail server to stop sending and retry later — they are not failures to ignore or retry immediately. RFC5321-s4.2.1 specifies that temporary failures must trigger a retry with increasing delay. Retrying at the same rate after a 421 is the sending equivalent of knocking louder when no one answers — it accelerates the point at which the ISP upgrades the temporary block to a permanent one. Systems that treat 4xx responses as hard failures (discarding the message) also lose deliverability: the message is gone, not deferred.

Track backoff state per ISP in memory (or Redis for multi-worker setups) and check it before dequeueing. Exponential backoff starting at 5 minutes, capped at 160 minutes, with automatic reset on successful delivery:

const ispBackoff = new Map<string, { factor: number; until: Date }>()

export function handleSmtpError(ispDomain: string, code: number): void {
  if (code >= 400 && code < 500) {
    const current = ispBackoff.get(ispDomain)
    const factor = Math.min((current?.factor ?? 1) * 2, 32)
    ispBackoff.set(ispDomain, {
      factor,
      until: new Date(Date.now() + factor * 5 * 60_000)
    })
  } else if (code >= 200 && code < 300) {
    ispBackoff.delete(ispDomain)  // Reset on success
  }
}

export function isIspBackedOff(ispDomain: string): boolean {
  const b = ispBackoff.get(ispDomain)
  if (!b || b.until <= new Date()) { ispBackoff.delete(ispDomain); return false }
  return true
}

In your queue worker, skip ISPs that are backed off and re-queue those jobs at the backoff expiry time. This pattern applies only to direct SMTP; ESP API clients (SendGrid HTTP API, etc.) handle retry internally.