Diagnóstico de PowerMTA

Cuando el correo deja de entrar, el reloj corre y la tentación es hacer algo, lo que sea, ya. Y ahí está el problema: en una incidencia de entrega, las reacciones de pánico suelen empeorar las cosas. Reintentar más fuerte, subir las tasas, ignorar lo que dicen los rebotes... cada uno de esos impulsos puede convertir un freno pasajero en un bloqueo serio. El diagnóstico de PowerMTA existe para sustituir el pánico por método: leer lo que el motor y los proveedores te están diciendo, identificar la causa real y aplicar el arreglo correcto, que muchas veces es lo contrario de lo que el instinto pide. Esta página explica cómo leemos un problema y cómo trabajamos una incidencia, porque saber qué está pasando es, casi siempre, la mitad de la solución.

¿Por dónde se empieza cuando el correo deja de llegar?

La buena noticia de PowerMTA es que no falla en silencio: cada rechazo viene con un código y un mensaje del proveedor que dice, con bastante precisión, qué ocurre. El primer paso de cualquier diagnóstico es leer eso en lugar de reaccionar al susto. Un parque que entrega mal no es un misterio insondable; es un conjunto de respuestas SMTP que cuentan una historia, si uno sabe leerlas. La diferencia entre un remitente que se recupera rápido y uno que se hunde está, en buena medida, en si escucha esas señales o las atropella. Por eso empezamos siempre por los registros y los rebotes, no por las conjeturas: ahí está escrito qué proveedor te frena, desde cuándo y, a menudo, por qué. Diagnosticar es, antes que nada, un ejercicio de lectura atenta.

4xx o 5xx: la primera cifra lo cambia todo

La distinción más importante de un rechazo está en su primera cifra. Un código 4xx es un fallo temporal: el proveedor no acepta el mensaje ahora, pero podría aceptarlo más tarde, así que lo correcto es reintentar con paciencia, según las reglas de backoff. Un código 5xx es un rechazo permanente: insistir no servirá, y el arreglo está en la configuración, el contenido o la reputación, no en volver a intentarlo. PowerMTA clasifica estas respuestas y actúa en consecuencia, pero solo si está bien configurado para hacerlo. El error clásico —y caro— es tratar un 4xx como si fuera definitivo, o un 5xx como si bastara con reintentar. Leer bien esa primera cifra marca la diferencia entre una recuperación ordenada y un agravamiento, y es lo primero que comprobamos al abrir tus registros.

¿Cómo se va del síntoma a la causa?

Cada síntoma apunta a un puñado de causas probables y a un primer paso sensato. Esta tabla resume los problemas por los que más nos llaman y por dónde se empieza a resolverlos, antes de entrar en el detalle de cada uno.

Diferimientos contra rebotes duros

Dos cosas que se confunden a menudo son los diferimientos y los rebotes duros, y tratarlas igual es un error. Un diferimiento es un «ahora no, vuelve luego»: el proveedor retiene tu correo temporalmente, y con el tiempo y el ritmo adecuados acabará entrando. Un rebote duro es un «esto no existe» o «no lo aceptaré nunca»: insistir solo gasta reputación. Cuando una incidencia mezcla ambos, lo primero es separarlos, porque exigen respuestas opuestas: paciencia y backoff para los diferimientos, supresión inmediata para los rebotes duros. Un parque que reintenta rebotes duros como si fueran diferimientos se hunde solo, y uno que da por muertos los diferimientos pierde entregas que iban a llegar. Distinguirlos bien, leyendo el código y el texto de cada uno, es de las primeras cosas que ordenamos en un diagnóstico.

¿Cómo se lee un código de rebote en la práctica?

Un rebote bien leído dice mucho más que «no entró». Miramos tres cosas en cada uno. El código, que separa lo temporal de lo permanente. El momento de la sesión en que aparece: un rechazo en el saludo, antes de presentar el mensaje, suele apuntar a la IP que conecta, a la carga de conexiones o a una política de TLS o de tráfico, mientras que uno más adelante puede implicar al dominio remitente, al destinatario, al ritmo o al contenido. Y el texto de diagnóstico que acompaña al código, donde el proveedor a menudo nombra la razón y hasta enlaza su portal. Cruzando esas tres pistas en el volumen de tus registros —no en un rebote suelto— sale el patrón: qué proveedor, qué tipo de problema y desde cuándo. Esa lectura es la materia prima del diagnóstico, y la que evita disparar a ciegas.

Los logs: dónde está escrito todo

La verdad de una incidencia está en los registros, no en las impresiones. PowerMTA guarda un rastro detallado de cada intento de entrega: el código de respuesta, el motivo, el proveedor, la hora, la cola implicada. Ese registro es la escena del crimen, y leerlo bien es la diferencia entre saber qué pasa y adivinarlo. Miramos la contabilidad para ver el panorama —cuánto entra, cuánto se difiere, cuánto rebota y por dónde— y los registros detallados para reconstruir el porqué de un caso concreto. Un parque con buenos registros se diagnostica en horas; uno con registros pobres obliga a esperar a que el problema se repita para poder verlo. Por eso, cuando empezamos, lo primero que pedimos es acceso de lectura a esos datos: ahí está escrito casi todo lo que necesitamos saber.

# ¿Qué proveedores devuelven qué códigos, ordenados por volumen?
$ pmta show queues | grep -E "outlook|hotmail" | head
outlook.com   recipients 84120   status 550 5.7.606   bloqueado

# Confirma que es un bloqueo de IP, no de contenido o auth — cuenta el código
$ grep "5.7.606" /var/log/pmta/acct-*.csv | wc -l
84120        # todo el ecosistema Microsoft de golpe — contrasta con SNDS

# ¿Es solo Microsoft, o Gmail también difiere? (lee el patrón)
$ awk -F, '{print $7}' /var/log/pmta/acct-*.csv | sort | uniq -c | sort -rn | head
  84120 550 5.7.606     # solo Microsoft
  41880 250 2.0.0       # Gmail sigue entregando normal

¿Por qué síntomas nos llaman los remitentes?

Las llamadas se parecen más de lo que parece. La más frecuente: «Gmail nos está diferiendo y no sabemos por qué». Le sigue Microsoft, con sus bloqueos súbitos y su famoso código de la familia 550. Luego están las colas que crecen y no bajan, las tormentas de rebotes que aparecen tras una campaña, y la caída lenta de colocación en bandeja que nadie relaciona con una causa concreta hasta que las ventas bajan. A veces es un parque nuevo que nunca llegó a entregar bien; otras, uno que funcionó durante años y de repente se rompió. Detrás de esa variedad hay, casi siempre, un repertorio acotado de causas, y reconocer el síntoma es el primer paso para acertar con la causa en lugar de probar suerte.

¿Qué significa el 421 de Gmail?

El caso más común tiene también el peor manejo habitual. Cuando Gmail devuelve un 421 4.7.0, está poniendo un freno temporal por reputación, ritmo o poca interacción, no levantando un muro permanente. Gmail ajusta dinámicamente cuánto tráfico acepta de cada remitente, y cuando superas su umbral, te pide que bajes el ritmo con ese código. La trampa es tratarlo como un fallo definitivo y responder reintentando a tope: eso refuerza justo la señal que disparó el freno y lo agrava. Lo correcto es lo contrario: bajar el ritmo, dejar que el backoff haga su trabajo y reconstruir confianza, con lo que el 421 se desvanece solo a medida que la reputación se estabiliza. Si el origen fue un calentamiento apresurado, lo identificamos y lo corregimos. Es un problema que casi siempre se resuelve con paciencia y método, rara vez con fuerza.

¿Qué significan los códigos 550 5.7.515 y 5.7.606 de Microsoft?

Pocos errores frustran tanto como el S3150 de Microsoft, y conviene explicarlo con franqueza. Llega como un 550 5.7.1 —es decir, un rechazo permanente— que dice que parte de tu red está en su lista de bloqueo, y te remite a un portal que a veces ni carga. La comunidad ha reconstruido a lo largo de los años que se asocia a un bloqueo a nivel de IP por su filtro de protocolo, y que se devuelve como permanente aunque la causa de fondo suele ser temporal: reputación o ritmo. Esa contradicción es el problema: un código permanente para algo que no lo es genera rebotes, supresiones y direcciones marcadas como muertas que no lo están. Y Microsoft no publica límites claros, así que el consejo de «envía más despacio» se queda sin un número al que apuntar. Lo trabajamos por sus canales de deslistado y corrigiendo la reputación, pero te diremos desde el principio qué parte depende de ellos.

5xx súbito y masivo: un bloqueo en marcha

Cuando los rechazos permanentes se disparan de golpe contra un proveedor concreto, casi siempre es un bloqueo activo, y la reacción importa. Más que el goteo normal de direcciones muertas, es una pared que un proveedor acaba de levantar contra tu IP o tu dominio, por reputación o por política. El instinto de seguir empujando es el peor posible: cada intento confirma el motivo del bloqueo. Lo primero es parar de presionar a ese proveedor, identificar exactamente qué IP o dominio está bloqueado y leer el motivo que da el rechazo. A partir de ahí, el camino es corregir la causa de reputación y, si hay un portal de deslistado, usarlo. Un 5xx masivo y súbito es de las pocas situaciones donde la velocidad de reacción —en el sentido de parar, no de empujar— cambia de verdad el desenlace.

¿Podéis sacarnos de una lista negra y cómo funciona el deslistado?

Cuando el problema es una lista negra, la honestidad es la mejor política. Aparecer en una lista como las de Spamhaus o en la de un proveedor frena tu entrega, y salir de ella es posible, pero no por arte de magia: la mayoría de las listas exigen que primero corrijas la causa que te metió ahí —una IP comprometida, una lista sucia, un pico de quejas— antes de retirarte, y algunas reponen el listado si detectan que el problema sigue. Por eso el deslistado en serio es siempre dos pasos: arreglar el origen y luego solicitar la salida, en ese orden. Lo tratamos a fondo en la página de salida de listas negras, pero en una incidencia el principio es el mismo: deslistar sin arreglar la causa solo compra tiempo en lugar de resolver el problema.

El backoff que empeora las cosas

En muchas incidencias, el agravante no es el proveedor, sino el propio backoff mal configurado. La función está para que, cuando un proveedor te frena, el motor reduzca el ritmo a esa cola y reintente más despacio hasta que la situación mejore. Pero un backoff mal puesto —patrones que no atrapan los avisos reales, modos que no vuelven a la normalidad, reintentos demasiado agresivos— puede provocar colas desbocadas y bucles de reintento que empeoran justo lo que pretendían arreglar. Por eso, ante una cola que no baja o un proveedor que se cierra, revisamos siempre el backoff: a menudo el problema que parece del proveedor es, en realidad, la respuesta torpe de tu propio motor a la señal del proveedor. Ajustarlo bien convierte una espiral en una recuperación ordenada.

Los arreglos que lo empeoran

Buena parte del diagnóstico es impedir que el pánico haga más daño. Hay reacciones instintivas que casi siempre agravan una incidencia, y las frenamos. Reintentar a toda velocidad un 421 le grita al proveedor justo lo que le molestó. Insistir sobre un 5xx permanente malgasta recursos y manda señales de remitente descuidado. Subir las tasas para «vaciar» una cola que no baja añade presión sobre un proveedor que ya te estaba conteniendo. Quitar el backoff porque «va lento» elimina la red que te protegía. Y cambiar diez cosas a la vez hace imposible saber qué ayudó y qué hizo daño. La primera regla de una incidencia es no empeorarla, y a veces el movimiento más valioso que hacemos las primeras horas es detener los arreglos que ya estaban en marcha.

Picos de quejas: la causa silenciosa

Detrás de muchas caídas de entrega hay un pico de quejas que nadie vio venir. Cuando demasiada gente marca tu correo como spam —tras una campaña a una lista vieja, un cambio de remitente o un contenido que no esperaban—, los proveedores reaccionan rápido y sin avisar de forma evidente: empiezan a diferir, a mandar a spam o a bloquear. La queja es una señal potentísima y, a diferencia de un rebote, no siempre deja un rastro tan claro en tus registros, así que hay que buscarla en los bucles de retroalimentación y en la correlación con lo que enviaste. En una incidencia, comprobamos si un pico de quejas explica la caída, porque si la causa es esa, ajustar el motor no arregla nada: el problema está en a quién y qué enviaste. Identificarlo a tiempo evita perseguir la avería en el sitio equivocado.

La autenticación como causa oculta

A veces el diferimiento no viene del ritmo ni de la reputación, sino de una autenticación rota que el rebote no nombra de forma obvia. Un fallo de alineación de SPF, DKIM o DMARC puede traducirse en diferimientos o en correo que cae en spam sin un mensaje que grite «tu autenticación falla». Por eso, en una incidencia de colocación o de diferimientos sin causa aparente, comprobamos la autenticación como sospechosa habitual: que las firmas estén activas y alineadas, que el SPF no rebase su límite de consultas, que DMARC sea coherente con lo que envías. Es una causa oculta porque rara vez se presenta con su nombre, y porque un parque que «siempre funcionó» puede romperse aquí tras un cambio de DNS o de proveedor. Descartarla pronto evita perseguir fantasmas en el motor cuando el problema está en un registro.

Cuando un parque nuevo nunca arrancó

No todas las incidencias son de un parque que se rompió; algunas son de uno que nunca llegó a funcionar. Un PowerMTA recién montado que entrega mal desde el primer día suele arrastrar uno de unos pocos pecados de origen: un calentamiento que se saltó o se aceleró, una autenticación incompleta, una configuración copiada sin entender, o IPs con un historial que no se comprobó antes de usarlas. Diagnosticar un parque nuevo es distinto de rescatar uno veterano: en lugar de buscar qué cambió, buscamos qué nunca estuvo bien. Revisamos los cimientos uno a uno —autenticación, calentamiento, segmentación, límites— y los ponemos en orden, porque un arranque torcido no se endereza enviando más, se endereza volviendo a la base. Es frustrante descubrir que el problema estuvo ahí desde el principio, pero también es la clase de avería que, una vez vista, se arregla de raíz.

Cuando uno que funcionaba se rompió de golpe

El caso contrario, y el más angustioso, es el del parque que funcionó durante años y un día deja de entregar. Aquí la pregunta clave es qué cambió, porque algo lo hizo, aunque no sea evidente. Un cambio de DNS que rompió la autenticación, una IP nueva sin calentar metida en producción, un proveedor que endureció sus reglas, un salto de volumen por una campaña inusual, una actualización mal aplicada: la lista de sospechosos es conocida. Diagnosticar un parque veterano roto es, sobre todo, reconstruir la línea de tiempo —qué se tocó, cuándo empezó el problema— y cruzarla con lo que dicen los rebotes. Muchas veces la causa es un cambio reciente y pequeño con un efecto grande, y encontrarlo es cuestión de mirar el antes y el después con método. Lo que «siempre funcionó» rara vez se rompe solo.

Qué necesitamos de ti para empezar

Para diagnosticar rápido, cuanto más contexto nos das, antes llegamos a la causa. Lo esencial es poco: acceso de lectura a tu configuración de PowerMTA y a tus registros y contabilidad, que es donde está el rastro. Más allá de eso, ayuda mucho una línea de tiempo de lo que pasó: cuándo empezó el problema, qué notaste primero —diferimientos, rebotes, caída de aperturas— y, sobre todo, qué se tocó en las fechas cercanas, como un cambio de DNS, una IP nueva, una campaña inusual, una actualización o un proveedor nuevo. Esos «¿qué cambió?» son a menudo el hilo que desenreda toda la madeja, porque un problema que empezó un martes suele tener una causa de ese lunes. Si tienes a mano ejemplos concretos de rebotes, mejor todavía: un puñado de mensajes de rechazo reales dice más que una descripción general. Con eso empezamos a leer de inmediato, sin pedirte que te conviertas en experto: tú nos cuentas qué ves y qué cambió, y nosotros traducimos los códigos en una causa y un plan.

¿Cómo trabajáis una incidencia de PowerMTA?

Nuestra forma de trabajar una incidencia es deliberadamente metódica, porque la prisa mal llevada es la que rompe. Primero estabilizamos: detenemos los arreglos que empeoran y contenemos el daño. Luego diagnosticamos sobre datos —tus registros, tus rebotes, tu reputación— hasta tener la causa identificada, más allá de una simple sospecha. Después aplicamos la corrección correcta, que a menudo es bajar, esperar y ajustar antes que empujar, y validamos que la entrega se recupera de verdad. Y, por último, dejamos claro qué pasó y qué evitará que vuelva. Todo ello con cobertura en husos horarios de Europa, Norteamérica y Latinoamérica, porque las incidencias de entrega no respetan el horario de oficina. La diferencia entre un incidente gestionado y uno sufrido es tener a alguien con el contexto y la calma para leer la situación antes de actuar.

El reloj importa: la rapidez de diagnóstico

En una incidencia de entrega, el tiempo es dinero de verdad. Cada hora que tu correo no entra es correo que no convierte, y cada día que un problema de reputación se prolonga es más difícil de revertir, porque el daño se acumula. Por eso la rapidez de diagnóstico es una ventaja competitiva antes que un lujo: cuanto antes se identifica la causa, antes se detiene el daño y empieza la recuperación. Esa velocidad no viene de actuar rápido a ciegas —eso empeora—; viene de saber dónde mirar y reconocer los patrones al instante, que es lo que da haber visto el mismo problema muchas veces. Llegar con el contexto y el método ya puestos ahorra las horas más caras de una incidencia: las primeras, cuando el daño todavía se puede contener.

¿Un incendio o el patrón detrás?

Apagar el fuego de hoy importa, pero la pregunta que de verdad ahorra dinero es por qué se prendió. Muchas incidencias son síntomas de un problema de fondo: un calentamiento mal hecho que producirá más 421, una segmentación pobre que mezcla reputaciones, un backoff frágil que volverá a desbordar, una lista que sigue ensuciándose. Resolver el incidente sin mirar el patrón garantiza el siguiente. Por eso, al cerrar una incidencia, te decimos si fue un caso aislado o la punta de algo mayor, y qué haría falta para que no se repita. Esa lectura es lo que separa un parche de una solución, y a menudo es el argumento para pasar de llamarnos cuando hay fuego a tenernos vigilando para que no lo haya. Hay un error que vemos repetirse y que cuesta tardes enteras: tratar un único rebote como si fuera el diagnóstico. Un 421 suelto no dice nada por sí mismo; el mismo 421 repitiéndose desde un solo proveedor durante una hora dice que la reputación con ese proveedor se está cayendo, y un 5.7.606 que aparece de golpe en todos los destinatarios de Microsoft dice que el bloqueo es de IP y que el siguiente paso es revisar SNDS antes que tocar el copy. La diferencia entre leer la línea y leer el patrón es, casi siempre, la diferencia entre arreglar la causa en una tarde y perseguir un síntoma durante una semana mientras la reputación sigue drenándose.

Diagnóstico puntual o vigilancia continua

El diagnóstico vale por sí solo: nos llamas cuando algo se rompe, lo resolvemos y sigues tu camino, con el problema entendido y corregido. Para muchos, sin embargo, la lección de una incidencia es que vigilar sale más barato que apagar fuegos. Ahí, el diagnóstico se convierte en el punto de entrada a una operación gestionada que detecta los problemas antes de que estallen, o a una optimización que corrige las causas de fondo. No condicionamos una cosa a la otra: resolver tu incidencia es útil tanto si seguimos juntos como si no. Y si el origen resulta estar fuera del motor, lo abordamos con la auditoría general de entregabilidad.

Si estás en mitad de una incidencia, el primer paso es entender qué pasa: la auditoría de 25 puntos da una lectura rápida de tu envío y de tu PowerMTA, y nos orienta sobre dónde mirar. Desde ahí actuamos con datos, no a ciegas.