ESP failover mechanism exists

When a primary ESP goes down — API timeout, account suspension, or DNS failure — email stops. Without automatic failover to a secondary ESP, every email queued during the outage either fails permanently or waits for manual operator intervention. CWE-391 (insufficient logging of errors) compounds the problem: a silent primary failure with no secondary means transactional emails — password resets, order confirmations — are silently dropped. The Sending Pipeline & Infrastructure Audit verifies queue resilience; this check verifies that the ESP layer itself has a recovery path that does not require a human in the loop.

Implement automatic failover in your ESP router (e.g., src/lib/email/router.ts) so primary failures trigger the secondary without operator action:

async function sendWithFailover(message: EmailMessage): Promise<void> {
  try {
    await primaryEsp.send(message)
  } catch (primaryErr) {
    logger.warn({ err: primaryErr }, 'Primary ESP failed — attempting failover')
    await secondaryEsp.send(message)
    metrics.increment('esp_failover_used')
  }
}

Both ESPs must have valid credentials loaded from environment variables. Manual failover — where an operator must change an env var and redeploy — does not satisfy this check.