Soluciona problemas de envío de correo en producción: SMTP, DNS y reintentos

Cómo se ve un “correo que no se envía” en producción

Cuando la gente dice que el correo “funciona en local pero no en producción”, normalmente significa que el código de la app está bien, pero la configuración real es diferente. Producción suele estar detrás de redes más estrictas, usa variables de entorno distintas y depende de DNS y de la cuenta del proveedor que pueden bloquearte o limitarte.

Los síntomas más comunes son fáciles de detectar cuando los nombras:

• Las solicitudes hacen timeout (la app espera y luego se rinde)
• Errores 401/403 (API key incorrecta, contraseña SMTP errónea o cuenta bloqueada)
• Mensajes que aparecen “en cola” para siempre (el proveedor los retiene, o tu worker está atascado)
• Los correos llegan, pero van a spam (entregabilidad, no envío)

Gran parte del trabajo para solucionar problemas de envío en producción suele ser configuración, DNS o límites del proveedor, no un bug en tu plantilla. Una variable de entorno faltante, un dominio nuevo sin SPF/DKIM, o una dirección en la lista de supresión del proveedor puede hacer que un flujo que funcionaba falle de la noche a la mañana.

Antes de cambiar nada, recoge algunos detalles para poder trazar un correo de extremo a extremo:

• Marca temporal exacta (con zona horaria) cuando disparaste el correo
• El texto del error y cualquier código de estado en tus logs
• Detalles de la respuesta del proveedor (ID de mensaje, request ID o el código de respuesta SMTP)
• Dirección del destinatario y el tipo de correo (restablecer contraseña, invitación, recibo)
• Si el problema afecta a todos los usuarios o solo a ciertos dominios (Gmail, Outlook, correo corporativo)

Si heredaste una app generada por IA, aquí es donde se esconden los pequeños errores de configuración. Equipos como FixMyMess suelen empezar mapeando un correo fallido hasta el punto exacto donde se rompe: app, proveedor o buzón.

Cómo funciona realmente el envío de correo (modelo mental simple)

Piensa en el envío de correo como una cadena de transferencia. Tu app crea un mensaje (para, desde, asunto, cuerpo). Luego lo entrega a un remitente (SMTP o una API de correo). Ese remitente lo entrega al servidor de correo del destinatario. Solo al final llega al buzón.

SMTP o una API de correo cambian la “puerta” que usas, no el destino. Con SMTP, tu app inicia sesión y habla con el proveedor como lo haría un cliente de correo. Con una API, tu app hace una petición HTTPS y el proveedor hace la parte SMTP por ti. En ambos casos necesitas: un dominio remitente verificado, permiso para enviar y un mensaje que los proveedores de buzón acepten.

Las fallas suelen ocurrir en uno de estos puntos:

• Capa de app: destinatario incorrecto, bug en la plantilla, falta de dirección from, payload malo
• Capa de red: puertos bloqueados, problemas TLS, timeouts
• Capa de proveedor: error de autenticación, límite de tasa, cuenta pausada, lista de supresión
• Capa de destinatario: filtrado como spam, rebotes o carpetas silenciosas

Algunos términos, en lenguaje llano: un rebote significa que la entrega falló (dirección errónea, buzón lleno o bloqueado). Una queja es cuando alguien marca tu correo como spam. Supresión es cuando tu proveedor deja de enviar a una dirección tras rebotes o quejas. La reputación es tu historial como remitente.

Una parte confusa: tu proveedor puede aceptar el mensaje (tu app registra “enviado”) pero que nunca aparezca. Ejemplo: un correo de restablecimiento de contraseña es aceptado y luego bloqueado silenciosamente por el destinatario porque el DNS de tu dominio no tiene SPF/DKIM/DMARC o tu reputación es baja. Por eso “solucionar problemas de envío en producción” a menudo trata de entregabilidad, no solo de envío.

Si heredaste código generado por IA, FixMyMess suele encontrar rápido la ruptura en esta cadena: reintentos faltantes, envíos duplicados o una rejeción del proveedor que tu app nunca mostró.

Triaging rápido: 10 minutos para acotar el origen

Cuando necesitas arreglar el envío en producción rápido, el objetivo es simple: averiguar si la falla está de tu lado (app/config/red) o del proveedor (cuenta/límites/supresión) antes de cambiar código.

Empieza con una prueba controlada: dispara un solo correo a un buzón que controles (no un lote). Conserva la marca temporal exacta.

Haz estas comprobaciones en orden:

• Verifica que el proveedor esté operativo y que tu cuenta pueda enviar (página de estado, facturación, límites diarios/horarios, modo sandbox).
• Confirma que la dirección remitente y el dominio estén verificados si tu proveedor lo requiere (los desajustes en el from son comunes).
• Abre los logs de producción para el intento de envío y copia el texto exacto del error y cualquier código.
• Confirma que las variables de entorno de producción son correctas (API key/contraseña SMTP, host, puerto, from, región).
• Captura el ID de mensaje del proveedor (o request ID) en la respuesta para trazar el evento en su lado.

El texto del error normalmente te indica la vía en la que estás:

• Errores de autenticación (401, 403, "Invalid login") suelen significar clave errónea, credenciales SMTP equivocadas o permisos bloqueados.
• Timeouts indican bloqueos de egress de red, host/puerto equivocados o problemas de negociación TLS.
• Errores 400 suelen indicar payload malformado (ID de plantilla inválido, dirección de correo incorrecta).
• "Suppressed" o "blocked" apunta a rebotes, quejas o supresión a nivel de cuenta.
• "Sender not verified" señala configuración de dominio o from-address.

Si heredaste una app generada por IA, estos problemas suelen venir de variables de entorno desajustadas o claves de prueba hardcodeadas. FixMyMess normalmente reproduce un envío, copia el message ID y lo mapea a la configuración fallida exacta para que dejes de adivinar.

Paso a paso: diagnosticar desde la app hasta el buzón

Empieza por hacer que el problema sea fácil de repetir. Usa un destinatario conocido (tu propio buzón sirve) y envía una plantilla específica (por ejemplo, “restablecer contraseña”). Cambia una sola cosa a la vez para saber qué lo arregla.

A continuación, captura lo que tu app realmente envió. Para una API de correo, registra el payload de la petición (redactando secretos) y la respuesta completa del proveedor. Para SMTP, captura la conversación SMTP (las respuestas del servidor importan tanto como tus comandos). El objetivo es tener un único registro que puedas señalar y decir: “Este intento de envío ocurrió a esta hora con estos datos”.

Luego sigue el mensaje a través del proveedor. Busca el evento de ese intento y nota si fue:

• Accepted/queued (el proveedor intentará entregar)
• Deferred (problema temporal, volverá a intentar)
• Bounced (rechazo definitivo)
• Blocked (política o reputación)
• Dropped/suppressed (el proveedor se negó a enviar)

Ahora revisa el estado en tu propia app. Confirma que guardaste el ID de mensaje del proveedor y un estado claro que coincida con el evento del proveedor. Un fallo común es mostrar “correo enviado” en la UI mientras el proveedor muestra “dropped” (a menudo por listas de supresión o falta de verificación).

Finalmente, decide si el dominio del destinatario lo rechazó o lo filtró. Si el proveedor dice “delivered” pero el correo falta, revisa spam y cuarentena, luego busca señales de “rejected by recipient” o “spam content”.

Si intentas arreglar el envío en producción y tus logs son caóticos o faltan, FixMyMess puede auditar el flujo de código y los eventos del proveedor para que veas exactamente dónde se rompe la cadena.

Comprobaciones del proveedor de correo (cuenta, límites y supresión)

Antes de meter las manos en el código, confirma que la cuenta del proveedor puede realmente enviar. Muchas situaciones de “correos que no se envían en producción” se reducen a una configuración de cuenta, un límite o un bloqueo silencioso.

Empieza por las credenciales. Si tu app usa una API key o contraseña SMTP, asegúrate de que coincida con el entorno correcto (prod vs staging), la región adecuada y la subcuenta o workspace correcto. La rotación de claves suele romper producción primero porque la clave antigua aún funciona en local.

Luego, verifica las reglas de la dirección From. Muchos proveedores solo permiten enviar desde dominios verificados o buzones específicos. Si un deploy cambió el From a algo como [email protected], el proveedor puede rechazarlo o aceptarlo pero nunca entregarlo.

Los límites de tasa y los topes pueden parecer fallos aleatorios. Puedes ver errores temporales, respuestas de throttling o timeouts durante picos (restablecimientos de contraseña tras un email de marketing, informes nocturnos, picos de registro). Revisa el dashboard del proveedor por alertas de límite que coincidan con tus timestamps.

Una de las cuestiones más insidiosas es la supresión. Si un destinatario rebotó en duro o te marcó como spam una vez, algunos proveedores suprimirán esa dirección y descartarán envíos futuros en silencio. Tu app puede decir “enviado” mientras ese buzón no recibe nada más.

Si tu app depende de eventos, confirma que los webhooks siguen conectados. Un webhook mal configurado puede hacer que tu app piense que el envío falló (o tuvo éxito) cuando el proveedor dice lo contrario.

Estas son las comprobaciones rápidas en el lado del proveedor:

• Confirma que la key/usuario SMTP activo es el desplegado en producción.
• Busca errores de verificación de From address o dominio.
• Revisa caps diarios y límites de ráfaga en la ventana del fallo.
• Busca la dirección de prueba en las listas de supresión.
• Verifica la entrega de eventos/webhooks y la configuración de firmas.

Si heredaste una app generada por IA, estas configuraciones suelen estar hardcodeadas o inconsistentes entre entornos. FixMyMess normalmente mapea la configuración de la cuenta del proveedor con la configuración real que usa tu build de producción y elimina las discrepancias.

Problemas SMTP: puertos, TLS, auth y bloqueos de red

Si puedes disparar un correo en la app pero nada llega, SMTP suele ser el eslabón débil. La trampa más grande: las redes de producción se comportan distinto a tu portátil.

Puerto y host van primero. Muchos proveedores aún mencionan el puerto 25, pero en hosting real suele estar bloqueado para evitar spam. Prefiere el puerto que recomiende tu proveedor para envío autenticado (comúnmente 587 con STARTTLS, o 465 con TLS implícito).

TLS: STARTTLS vs TLS implícito

STARTTLS significa que te conectas en texto claro y luego subes a TLS. TLS implícito (a menudo 465) empieza cifrado de inmediato. Mezclarlos provoca errores de handshake como “wrong version number” o “EOF”. También revisa:

• Que el hostname SMTP coincida con el certificado (usar una IP puede romper la validación)
• Que el reloj de tu servidor esté correcto (hora incorrecta puede fallar chequeos de cert)

Auth y bloqueos de red

Los fallos de auth suelen ser simples: usuario equivocado, contraseña equivocada o usar un login humano en lugar de credenciales SMTP/API. Algunos proveedores exigen una contraseña de aplicación, token o allowlist de IPs.

Los bloqueos de red son comunes en hosts cloud y contenedores. Reglas de salida, firewalls, NAT o gateways corporativos de egress pueden descartar tráfico SMTP en silencio.

Para probar sin adivinar, ejecuta una comprobación de conectividad desde el mismo entorno que tu app (la misma VM, contenedor o función):

nc -vz smtp.yourprovider.com 587
openssl s_client -starttls smtp -connect smtp.yourprovider.com:587

Si la prueba de puerto falla, es red. Si la prueba TLS conecta pero falla auth, son credenciales o política del proveedor. Esta separación clara es la forma más rápida de arreglar problemas de envío en producción.

Si heredaste una app generada por IA donde las configuraciones SMTP están dispersas entre código y variables de entorno, FixMyMess puede auditar y reparar la configuración rápidamente para que el envío funcione de forma fiable tras los deploys.

Problemas con APIs de correo: errores de auth, bugs en el payload y timeouts

Cuando usas una API de correo (en lugar de SMTP), “el correo no se envía” frecuentemente significa que tu app nunca creó la petición de envío, o el proveedor la rechazó antes de llegar a la cola. Empieza por revisar el código de estado y el mensaje de la respuesta del proveedor para la petición exacta.

Lee el código de estado como una pista

La mayoría de fallos caen en unos pocos grupos:

• 400 Bad Request: tu JSON está mal (faltan campos requeridos, ID de plantilla inválido, codificación inválida).
• 401 Unauthorized: la API key falta, expiró o es del entorno equivocado.
• 403 Forbidden: la key existe pero no tiene permisos, o el dominio/from address no está permitido.
• 429 Too Many Requests: alcanzaste límites de tasa; reduce la velocidad y reintenta con backoff.
• 202/200 pero sin correo: la API aceptó, pero después fue suprimido, rebotó o bloqueado por política.

Los bugs en el payload son comunes tras un deploy: un campo renombrado, una lista “to” vacía, HTML con caracteres inválidos o una variable de plantilla que ya no existe. Los adjuntos también pueden romper envíos. Muchos proveedores imponen límites de tamaño, y las funciones serverless pueden hacer timeout subiendo archivos grandes.

Si tu proveedor usa peticiones firmadas, la deriva del reloj puede causar fallos aleatorios de autenticación. Asegúrate de que la hora del servidor sea correcta.

Para arreglar envíos en producción sin duplicados, usa claves de idempotencia. Así, si reintentas tras un timeout, el proveedor lo trata como el mismo envío y no manda dos copias.

Si heredaste código generado por IA que comete estos errores, FixMyMess puede auditar la ruta de envío y endurecer los reintentos para que se comporte de forma predecible bajo carga.

Configuración de dominio: SPF, DKIM y DMARC sin confusión

Muchos reportes de “correo que no se envía” en realidad son “el correo se envía, pero nunca llega al buzón”. Si necesitas arreglar la entrega en producción, empieza por asegurarte de que tu dominio demuestra que el mensaje está autorizado.

SPF: quién puede enviar

SPF es un registro TXT de DNS que lista qué servidores pueden enviar correo por tu dominio. Debes tener exactamente un registro SPF por dominio.

v=spf1 include:YOUR_PROVIDER.com -all

Los problemas comunes de SPF son simples: múltiples registros TXT de SPF (entran en conflicto), un registro en el hostname equivocado (puesto en un subdominio cuando envías desde el dominio raíz, o al revés), o un include desactualizado tras cambiar de proveedor.

DKIM y DMARC: probar que eres tú

DKIM añade una firma para que los buzones verifiquen que el correo no fue modificado y realmente coincide con tu dominio. Si DKIM está configurado pero “desalineado” (por ejemplo, tu From es midominio.com pero la firma DKIM es de otro dominio), la colocación en el buzón puede verse afectada.

DMARC une SPF y DKIM. Empieza con monitorización para no bloquear correo legítimo por accidente, y luego aprieta:

• Comienza con p=none para recopilar informes y detectar sorpresas
• Pasa a p=quarantine cuando las fuentes legítimas estén confirmadas
• Llega a p=reject cuando estés seguro de que nadie más debería enviar

Los errores de DNS son comunes: copiar el registro en el subdominio equivocado, olvidar un punto en un hostname o esperar a que el TTL expire. Para confirmar que los cambios están activos, consulta DNS desde otra red y revisa las cabeceras de un mensaje real en “Authentication-Results” mostrando SPF, DKIM y DMARC como PASS.

Si heredaste una app generada por IA con código de correo desordenado y dominios remitentes poco claros, FixMyMess puede auditar la configuración y señalar exactamente qué falla antes de tocar producción.

Triggers de spam y fundamentos de entregabilidad

A veces “el correo no se envía” en realidad es “se entregó, pero nadie lo ve”. Tu proveedor puede mostrar éxito, pero el mensaje cae en Spam o en la pestaña Promociones porque los proveedores de buzón aplican su propio filtrado.

Los triggers de spam comunes son sorprendentemente pequeños: asuntos gritando o engañosos (“URGENT”, “RE: invoice”), acortadores de enlaces, demasiados enlaces y HTML roto (falta versión en texto plano, imágenes muy grandes o formato desordenado). Incluso una sola línea sospechosa puede pesar más que todo lo demás.

La reputación importa tanto como el contenido. Los dominios nuevos y las identidades nuevas empiezan con poca confianza. Si pasas de 0 a miles de correos de la noche a la mañana, los filtros se ponen más estrictos. Calienta gradualmente y mantén bajas las tasas de queja.

Las direcciones “no-reply” suelen salir mal. La gente responde cuando algo parece raro. Si esa respuesta rebota o desaparece, obtendrás más quejas. Usa un remitente real y un Reply-To claro que tu equipo monitorice.

Mantén separados los correos transaccionales y de marketing: distintos dominios o subdominios remitentes, y preferiblemente distintos streams del proveedor. Así un pico de marketing no daña los restablecimientos de contraseña.

Si los mensajes se entregan pero siguen en spam, prueba esto:

• Envía una versión simple y plana (menos HTML, menos enlaces) y compara resultados
• Elimina acortadores y URLs con mucho tracking
• Haz que el asunto coincida con el cuerpo y la intención
• Pide a algunos destinatarios que marquen “No es spam” y que respondan una vez
• Revisa saltos bruscos de volumen tras un deploy o campaña

Envío fiable: reintentos, rebotes y evitar duplicados

El correo falla en producción por razones que no tienen nada que ver con DNS o plantillas. La diferencia entre “flaky” y “fiable” suele ser cómo reintentas, qué recuerdas y cuándo paras.

Una política de reintentos simple

Reintenta solo cuando el proveedor o la red tengan un problema temporal. Si la dirección es inválida o el dominio rechaza, reintentar solo genera ruido y puede dañar tu reputación.

Un enfoque práctico que sirve para la mayoría de apps:

• Reintenta en timeouts, 429 rate limits y errores SMTP 4xx (temporales).
• No reintentes en “destinatario inválido”, “mailbox no existe” y fallos 5xx permanentes.
• Usa backoff exponencial (por ejemplo: 1 min, 5 min, 20 min, 1 hr) con algo de aleatoriedad.
• Límita los intentos (3-6 en total) y para si el usuario cancela la acción (como pedir un nuevo restablecimiento).
• Separa “enviar ahora” de “enviar más tarde” para que la petición web no se quede colgada.

El backoff importa: hacer reintentos cada pocos segundos puede causar rate limits, parecer sospechoso y convertir un incidente pequeño en uno más grande.

Para evitar correos duplicados, almacena cada intento con una clave de mensaje estable. Por ejemplo: password_reset:<user_id>:<token_id>. Si se ve la misma clave otra vez, trátalo como idempotente y no envíes doble.

Rebotes, quejas y qué vigilar

Si recibes un rebote o una queja, deja de enviar a esa dirección y notifícalo al usuario (“No pudimos entregar a este correo. Por favor actualízalo.”). Mantén métricas básicas para que los problemas aparezcan rápido:

• Tasa de éxito de entrega, tasa de rebotes, tasa de quejas
• Conteo de reintentos y tiempo en estado “pendiente”
• Respuestas del proveedor (códigos de estado, mensajes de error)

Si tu código fue generado rápidamente y la lógica de colas es caótica, FixMyMess puede auditar la canalización de envío y hacer que reintentos, idempotencia y logging sean fiables sin rehacer toda la app.

Errores comunes que mantienen el correo roto

Muchos equipos intentan arreglar el envío cambiando una configuración a la vez. El problema es que la ruptura suele venir de algunos hábitos evitables que ocultan la falla real.

Uno de los más grandes es el mal manejo de secretos. API keys hardcodeadas, contraseñas SMTP comprometidas en repositorios o tokens impresos en logs pueden ser rotados o bloqueados sin que lo notes. Peor aún, a veces los secretos se filtran en código del lado cliente, de modo que cualquiera puede copiarlos y enviar spam desde tu cuenta.

Otra trampa común es la confusión de dominios remitentes. Si envías desde un dominio que no controlas, o mezclas varios dominios From entre entornos (staging y prod), la alineación SPF/DKIM puede fallar y los mensajes caer en spam o ser rechazados.

Los dashboards de proveedores también pueden llevar a error. “Accepted” generalmente significa que el proveedor tomó el mensaje, no que llegó al buzón. Un buzón aún puede descartarlo más tarde por reglas de spam, política DMARC o una lista de supresión.

Aquí errores que mantienen el problema vivo silenciosamente:

• No tener alertas por picos de rebotes, webhooks fallidos o caídas súbitas en volumen de envíos.
• Tratar reintentos como “enviar otra vez” sin clave de idempotencia, causando duplicados.
• Reintentar todo error igual, incluyendo fallos permanentes como direcciones inválidas.
• Ignorar listas de supresión y preguntarse por qué algunos usuarios nunca reciben correo.
• Usar “no-reply” o asuntos genéricos que disparan filtros de spam con más frecuencia.

Ejemplo: tras un deploy, los correos de restablecimiento “se envían” pero nunca llegan. El código cambió el From a un subdominio nuevo, pero los registros DNS nunca se añadieron. El proveedor acepta el mensaje y luego los receptores lo rechazan. Si heredaste código de correo generado por IA con dominios mezclados o logging inseguro, FixMyMess puede auditar el flujo de extremo a extremo y señalar la ruptura exacta.

Ejemplo: fallos en correos de restablecimiento tras un deploy

Despliegas una nueva versión un viernes. Minutos después, llegan tickets de soporte: “No recibo el correo para restablecer la contraseña.” En producción, esto puede parecer “el correo no se envía”, pero la causa real suele ser una de tres: DNS, auth del proveedor o un cambio en el código.

Primero, revisa los logs de la app para el intento de envío. Una regresión en el código suele mostrarse como un nuevo error como Missing API key, 535 Authentication failed o ECONNREFUSED. Si los logs dicen “sent” pero los usuarios no ven nada, pasa al proveedor.

Abre el feed de eventos o actividad del proveedor. Pistas típicas:

• Muchos eventos 401/403: tu deploy cambió o borró una variable de entorno (API key, usuario/contraseña SMTP).
• Muchos eventos suppressed/blocked: tocaste una lista de rebotes o un límite de envío.
• Aceptado por el proveedor pero sin entrega: es más probable un problema de dominio o spam.

A continuación, descarta DNS rápidamente. Si rotaste dominios, cambiaste el From o migraste de proveedor, un desajuste SPF/DKIM/DMARC puede convertir correo real en spam o provocar rechazo. También puedes ver advertencias del proveedor como “DKIM not aligned” o “SPF softfail.”

Las soluciones suelen ser:

• Corregir las vars de entorno en producción (y reiniciar la app para que las cargue).
• Verificar SPF/DKIM/DMARC para el dominio exacto que usas en From.
• Añadir reintentos seguros para timeouts (backoff corto) y usar una clave de idempotencia para que los reintentos no generen duplicados.

Finalmente, añade un monitor simple: cada 5 minutos, dispara un restablecimiento de prueba a un buzón que controles y alerta si no hay evento “delivered” del proveedor en 2 minutos. Si necesitas ayuda para arreglar el envío en producción rápido, FixMyMess puede auditar código, configuración y DNS juntos para que no tengas que adivinar.

Checklist rápido antes de volver a desplegar

Antes de redeployar, haz una prueba limpia desde producción y sigue la traza de extremo a extremo. El objetivo es probar si el mensaje salió de tu app, llegó a tu proveedor y tuvo oportunidad de aterrizar en el buzón.

Comprobaciones pre-despliegue (10 minutos)

Haz estos pasos en orden. Cada uno puede explicar la mayoría de los reportes de “correo que no se envía”.

• Envía una prueba sencilla a un buzón que controles y captura el ID de mensaje del proveedor (o el ID de cola SMTP). Confirma también que el proveedor no tiene una caída y que tu cuenta no está pausada, limitada o suprimiendo a ese destinatario.
• Confirma que tu dominio From está configurado correctamente: SPF y DKIM existen, y DMARC está presente. Asegúrate de que el dominio del From coincida con lo que tu proveedor firma (la alineación importa).
• Verifica secretos de producción: la API key o usuario/contraseña SMTP correctos están cargados en producción (no en staging) y tienen permiso para enviar desde tu dominio elegido.
• Repasa el contenido del correo: evita asuntos spammy, revisa que los enlaces sean válidos y asegúrate de que las plantillas no tienen variables faltantes (HTML roto puede perjudicar la entregabilidad).
• Revisa la fiabilidad: los reintentos están limitados, cada intento queda logueado y la llamada de envío es idempotente para que un timeout no cree duplicados.

Si aún no puedes arreglar el envío en producción tras esto, probablemente necesites un diagnóstico más profundo a nivel de app (workers de cola, reglas de egress de red o eventos/webhooks del proveedor). FixMyMess puede auditar la ruta de envío y endurecerla para que los envíos sean previsibles tras cada deploy.

Próximos pasos si el problema reaparece

Si sigues arreglando el correo una y otra vez, trátalo como un problema de fiabilidad, no como un bug puntual. Empieza por decidir qué comprobarás cada semana, incluso cuando todo parezca bien. La mayoría de fallos de correo muestran señales tempranas con un aumento lento de rebotes o quejas.

Un monitor semanal simple puede ser:

• Envios fallidos (errores de API o rechazos SMTP)
• Tasa de rebotes (duros vs suaves)
• Quejas por spam
• Crecimiento de la lista de supresión (destinatarios bloqueados)
• Latencia media de envío y conteo de timeouts

Luego, escribe tu configuración “conocida buena” en un lugar: incluye dominio remitente, formato de From, nombre del proveedor, región de envío y los registros DNS exactos que esperas (SPF, DKIM, DMARC). Cuando ocurra un deploy o cambio de entorno, podrás comparar rápidamente qué cambió en lugar de adivinar.

A continuación elige una mejora pequeña que reduzca incidentes repetidos. Buenas opciones son mejor logging de errores (almacenar códigos de respuesta del proveedor), lógica de reintentos más segura (reintentar solo errores temporales con backoff) o manejo de webhooks que registre rebotes y supresiones para que no sigas reintentando direcciones muertas.

Si intentas arreglar el envío en producción en una app generada por herramientas de IA, los problemas recurrentes suelen venir de drift de configuración, secretos expuestos o flujos de autenticación rotos alrededor de restablecimientos de contraseña e invitaciones. FixMyMess puede hacer una auditoría de código gratuita para encontrar esas causas raíz y reparar el código y la configuración de despliegue para que el envío sea estable.