Soft bounce tracking with escalation to suppression

Soft bounces (4xx SMTP responses) indicate temporary conditions — a full mailbox, a server outage, a transient policy block. A single soft bounce warrants a retry. But an address that soft-bounces three or more times within a week is not temporarily unavailable: it is either abandoned, over quota indefinitely, or rejecting your domain specifically. RFC5321-s4.2.1 establishes that repeated temporary failures should eventually be treated as permanent. Without escalation logic, the system will retry indefinitely, accumulating poor delivery metrics and flagging the sending IP as one that ignores bounce signals.

Track soft bounces per address in a separate event table and escalate to permanent suppression after 3 events within a 7-day rolling window:

const SOFT_BOUNCE_THRESHOLD = 3
const WINDOW_DAYS = 7

export async function handleSoftBounce(email: string, reason: string): Promise<void> {
  await db.softBounceEvent.create({
    data: { email: email.toLowerCase(), reason, bouncedAt: new Date() }
  })

  const windowStart = new Date(Date.now() - WINDOW_DAYS * 86_400_000)
  const recentCount = await db.softBounceEvent.count({
    where: { email: email.toLowerCase(), bouncedAt: { gte: windowStart } }
  })

  if (recentCount >= SOFT_BOUNCE_THRESHOLD) {
    await db.suppression.upsert({
      where: { email: email.toLowerCase() },
      update: { reason: 'soft_bounce_escalated', updatedAt: new Date() },
      create: {
        email: email.toLowerCase(),
        reason: 'soft_bounce_escalated',
        source: 'soft_bounce_escalation',
        suppressedAt: new Date()
      }
    })
  }
}

Ensure the pre-send isAddressSuppressed check covers escalated soft bounces as well as hard bounces — they write to the same suppression table.