Amazon SES "Throttling: Maximum sending rate exceeded" (454): cómo solucionarlo

Qué significa

Toda cuenta de Amazon SES tiene dos cuotas de envío por región de AWS: una velocidad de envío (emails por segundo) y una cuota de envío (emails en 24 horas móviles). Cuando superas una de ellas, SES rechaza el mensaje. Por SMTP, las respuestas son:

454 Throttling failure: Maximum sending rate exceeded
454 Throttling failure: Daily message quota exceeded

A través de la API o de un SDK recibes un error Throttling con el mensaje "Maximum sending rate exceeded" o "Daily message quota exceeded". Un código 4xx es temporal: el mensaje no se ha enviado, pero se puede enviar más tarde. Un mensaje rechazado no se factura.

Por qué ocurre

• Sigues en el sandbox. Las cuentas en sandbox están limitadas por defecto a 1 mensaje por segundo y 200 mensajes cada 24 horas. Consulta cómo salir del sandbox.
• Picos de envío. Tu aplicación envía una lista entera en un bucle con muchos procesos en paralelo. SES tolera picos cortos, no un exceso continuado.
• Las cuotas cuentan destinatarios, no mensajes. Un email con 10 destinatarios cuenta como 10.
• Región equivocada. Las cuotas son por región. Una cuota más alta concedida en us-east-1 no se aplica a eu-west-1.
• Credenciales SMTP antiguas. "Maximum SigV2 SMTP sending rate exceeded" significa que tus credenciales SMTP se crearon antes del 10 de enero de 2019. Sustitúyelas por unas nuevas.
• Si el texto de la limitación no corresponde a ninguna de las dos cuotas, AWS sugiere consultar el AWS Health Dashboard por si hay una incidencia del servicio.

Cómo comprobarlo

Consulta tus cuotas actuales y tu uso con la CLI (o en el Account dashboard de la consola):

aws sesv2 get-account --region eu-west-1

"SendQuota": {
    "Max24HourSend": 50000.0,
    "MaxSendRate": 14.0,
    "SentLast24Hours": 48211.0
}

Compara MaxSendRate con los mensajes que tu código envía realmente por segundo, y SentLast24Hours con Max24HourSend. Tus logs muestran la hora de los errores 454: los picos al inicio de una campaña apuntan a un problema de velocidad; los errores al final del día apuntan a la cuota diaria.

Cómo solucionarlo

Reduce la velocidad y reintenta

Envía a tu MaxSendRate o por debajo, y reintenta los errores 454 con esperas cada vez más largas (AWS sugiere, por ejemplo, 5 s, 10 s, 30 s y luego una pausa más larga). Los SDK de AWS reintentan automáticamente las llamadas a la API, pero tu propia cola debe respetar igualmente la velocidad. Con nodemailer, un transporte con pool puede limitar la velocidad:

const transporter = nodemailer.createTransport({
  host: 'email-smtp.eu-west-1.amazonaws.com', port: 587,
  auth: { user: process.env.SES_SMTP_USER, pass: process.env.SES_SMTP_PASS },
  pool: true,
  maxConnections: 2,
  rateDelta: 1000,  // per second
  rateLimit: 10,    // at most 10 messages per rateDelta
});

Si Postfix retransmite a SES, reduce las entregas en paralelo hacia el relay, por ejemplo con smtp_destination_concurrency_limit = 2 y smtp_destination_rate_delay = 1s en main.cf (el retardo se aplica por destino, aquí el relay de SES). Postfix guarda los mensajes 4xx en su cola y los reintenta automáticamente.

Cuota diaria alcanzada

Espera: la cuota es una ventana móvil de 24 horas, así que la capacidad vuelve a medida que salen los envíos más antiguos. Reparte las campañas grandes en varios días y envía un destinatario por llamada a la API en lugar de largas listas de destinatarios.

Pide cuotas más altas

Abre la consola Service Quotas, selecciona la región correcta, elige AWS services y después Amazon Simple Email Service (SES), y solicita un aumento de Sending quota o Sending rate. AWS dice que tramita estas solicitudes en unas 24 horas y que también puede subir las cuotas automáticamente cuando envías correo de buena calidad cerca de tu límite con tasas bajas de rebotes y quejas.

Incluso con cuotas altas, no pases de unos cientos a decenas de miles de emails al día de golpe: los proveedores de correo reaccionan a los picos repentinos con su propia limitación (consulta SMTP 421 too many connections). Aumenta poco a poco, como se explica en calentar un dominio o una IP nuevos.

Comprueba que está solucionado

Vuelve a lanzar tu proceso de envío y vigila los logs: no debería haber más errores 454 y SentLast24Hours debería mantenerse por debajo de Max24HourSend. Envía un mensaje a tu dirección única de la página de inicio de Delivmail para confirmar que el contenido y la autenticación siguen limpios tras tus cambios, y después reenvía los mensajes que fueron rechazados.