¿Por qué mi aplicación dejó de enviar correos?

Mira primero el registro del proveedor, no el tuyo

Lo confuso de este fallo es que nada parece roto. Tu código se ejecutó, la función de envío devolvió, no saltó ninguna excepción y tus propios registros muestran mensajes saliendo. Eso es porque tu registro de aplicación anota lo que tu código decidió hacer, y el registro del proveedor anota lo que le pasó al mensaje. Cuando los dos no coinciden, el proveedor tiene razón. Abre su vista de actividad y filtra por la ventana en la que se detuvieron los envíos: normalmente verás o silencio a partir de una marca de tiempo, lo que significa que tu código dejó de llamar, o una serie de rechazos con un motivo adjunto, lo que significa que llamó y fue rechazado.

Haz eso antes de cambiar código, rotar una clave de API o reenviar nada. Cada una de esas acciones dificulta el diagnóstico, y una de ellas empeora el problema: una ráfaga de reenvíos contra una cuenta ya marcada por volumen es la manera clásica de convertir una pausa temporal en una permanente.

Las cuatro cosas que de verdad detienen el envío

En orden aproximado según la frecuencia con que cada una resulta ser la respuesta:

• Un límite del plan al que llegaste creciendo Los topes de envío diarios y mensuales son la causa más común y la que peor sienta, porque nada de tu sistema cambió: cambiaron tus registros de usuarios. El límite se cruza un martes idéntico a cualquier otro martes, y lo que se descarta es lo que estaba encolado al final, que suele ser el correo de notificaciones y de ciclo de vida antes que los correos de acceso enviados a primera hora.
• Una pausa del proveedor Los proveedores detienen cuentas ante cambios bruscos de volumen, ante una tasa de rebotes duros por encima de un umbral y ante quejas de spam. Esta suele venir con un correo de aviso, enviado a la dirección que estuviera en la cuenta cuando se creó, que en un equipo pequeño muchas veces ya no es el buzón de nadie.
• Autenticación de dominio rota Los registros SPF, DKIM y DMARC viven en el DNS, así que se rompen cuando el DNS cambia: una migración de registrador, un registro que reemplazó en vez de añadir, una verificación caducada, una clave de firma rotada. Esta se degrada antes de detenerse: primero falla la entrega en un proveedor de buzón, luego sube la tasa de rebotes, luego llega la pausa.
• Tu propio código dejó de llamar Una variable de entorno que falta en un entorno, un worker de cola que murió en silencio, un feature flag que quedó apagado tras un despliegue, una actualización del SDK que cambió un campo obligatorio. Si el registro del proveedor muestra silencio en lugar de rechazos, esta es tu rama, y la respuesta está en tu historial de despliegues, no en el panel del proveedor.

Lee el cuerpo, no el código de estado

Esto es lo que convierte un incidente de diez minutos en uno de tres días, y hemos cometido el error más de una vez en nuestro propio sistema. Una llamada rechazada no llega de forma fiable como un error. Llega como un HTTP 200 con el fallo dentro del cuerpo de la respuesta, y el código que solo comprueba el código de estado anota un éxito. Nos ha pasado exactamente con esa forma con varios proveedores distintos: uno responde 200 con un indicador de éxito en falso dentro del cuerpo cuando a un token le falta un permiso; otro aceptó una publicación en redes, informó de un fallo de validación en el cuerpo, y nuestro sistema — que solo leía el envoltorio — registró la publicación como publicada y así se lo dijo al cliente. No se había publicado nada.

La regla que salió de ahí es corta, y vale para el correo igual que para todo lo demás: considera un envío exitoso solo cuando el cuerpo de la respuesta diga que el proveedor lo aceptó, registra el motivo literal del proveedor cuando no lo haga, y alerta sobre esa cadena en vez de sobre tu propio resumen de ella. La línea de estado describe la conversación con la API. El cuerpo describe el correo.

La misma disciplina cubre la limitación de tasa. Un proveedor que responde 429 te está diciendo algo útil y temporal, y el código sin reintentos escalonados convierte eso en pérdida permanente, porque el mensaje se descarta y no se reintenta nunca. Estuvimos sin esos reintentos más tiempo del debido, y lo que acabó sacándolo a la luz no fue una alerta. Fue que alguien se puso a mirar.

Haz que el próximo se oiga

El arreglo que importa no es subir el límite, es darse cuenta antes de llegar a él, y la alerta debe ir sobre la proporción, no sobre el recuento. «Hemos gastado el 80% de la cuota de hoy a las 14:00» es accionable; «hemos enviado 100 mensajes» deja de significar algo en cuanto cambia el plan. Nuestro propio volumen cruzó los cien mensajes al día a medida que crecían los registros de usuarios, contra un techo de plan gratuito de exactamente cien: unos 107 el día que por fin miramos, tras habernos quedado en 99 de 100 a principios de esa semana. Ninguna parte del sistema dijo una palabra. La mejora de plan fue la mitad fácil. La alerta que aún nos debíamos era la mitad que importaba, y el motivo de que faltara es que el tope nunca había estado cerca, así que nadie lo había pensado como un número que se mueve.

Dos cosas más que merece la pena hacer ya que estás aquí. Ten una segunda vía de entrada a la cuenta para cuando no llegue un correo que lleva un acceso, por los motivos de nuestra página sobre por qué fallan los inicios de sesión con enlace mágico. Y separa el correo que lleva un acceso o un recibo del correo que lleva una campaña — por dominio de envío como mínimo, e idealmente por proveedor — para que una campaña que dispara un umbral de quejas no pueda tumbar tus restablecimientos de contraseña. Nuestra página sobre cómo montar correos de ciclo de vida cubre qué va en cada flujo. Construir AgentCeres — el AI Growth Officer en agentceres.com — nos enseñó la prioridad por la vía cara: los mensajes que el cliente pidió de verdad son los que se protegen primero.