IP/Dominio de correo en lista negra: cómo verificar y solicitar la eliminación correctamente

Playbook de diagnóstico rápido

Si tienes 20 minutos antes de que el VP pregunte por qué las facturas no llegan, no empieces pidiendo “eliminación de la lista”. Empieza por encontrar el cuello de botella: ¿es una lista RBL real, un bloqueo de reputación del proveedor o tu propia infraestructura colapsando?

Primero: confirma alcance y síntomas (10 minutos)

• ¿Qué flujo está fallando? ¿Transaccional, marketing, restablecimiento de contraseñas, todo?
• ¿Dónde falla? ¿En tiempo SMTP (rechazos), después de la aceptación (carpeta de spam) o nunca sale de tu sistema (cola)?
• ¿Qué cambió? IP nueva, proveedor nuevo, contenido nuevo, lista nueva, autenticación nueva, tasa de envío nueva.

Segundo: lee un rebote real de extremo a extremo (5 minutos)

Elige una única falla y extrae la respuesta exacta del servidor remoto y el código de estado mejorado (como 5.7.1). El rebote es tu traza de pila. Adivinar es como acabar “arreglando SPF” para un buzón comprometido.

Tercero: decide si es un problema de IP, dominio o cuenta (5 minutos)

• Problema de IP: una IP saliente es rechazada; otras IP funcionan; las búsquedas RBL responden; la respuesta SMTP menciona “listed”, “RBL” o “policy”.
• Problema de dominio: varias IP fallan por el mismo dominio; DMARC no alinea; advertencias de “reputación de dominio”; los enlaces/dominios en el contenido activan filtros.
• Problema de cuenta: un único buzón/usuario/servicio envía volumen inusual; los registros muestran picos; los destinatarios reportan spam; ves muchos fallos de autenticación.

Regla: no pidas que te eliminen hasta que puedas explicar, en un párrafo, qué causó la inclusión y qué cambiaste para evitar que se repita. Los equipos de eliminación no están para hacer tu análisis de incidentes.

Qué significa realmente “en lista negra” (y qué no)

La gente dice “estamos en lista negra” como si existiera un único portapapeles global en el cielo. No existe. Hay:

• Listas públicas basadas en DNS (RBL/DNSBL) que publican entradas de IP/dominio que puedes consultar vía DNS.
• Sistemas de reputación privados de proveedores (Gmail, Microsoft, Yahoo, pasarelas corporativas) que no necesitan listarte públicamente para limitarte o marcarte como spam.
• Feeds comerciales de reputación integrados en appliances y productos de seguridad de correo, a veces con puntuaciones opacas.
• Bloqueos por política local en una organización receptora (“bloqueamos todos los remitentes nuevos”, “bloqueamos tu ASN”, “solo aceptamos de proveedores en la lista blanca”).

Además: estar listado no siempre es culpa tuya. Las IP compartidas te penalizan por tus vecinos. Los gateways NAT hacen que múltiples inquilinos parezcan un único remitente. Y ocasionalmente un proveedor bloquea todo un bloque porque es un pantano de abuso y tú eres la rana inocente.

Pero: si administras tu propio SMTP saliente y estás listado, asume que es culpa tuya hasta que se demuestre lo contrario. Esa mentalidad acorta incidentes.

Chiste #1: La reputación de correo es como un puntaje crediticio, excepto que puede bajar 200 puntos porque alguien hizo clic en “spam” estando enfadado y con cafeína.

Datos interesantes y breve historia

• Las listas basadas en DNS se popularizaron a finales de los 90, porque DNS era rápido, distribuido y ya estaba en todas partes—perfecto para consultas “¿esta IP se porta mal?”.
• Las primeras listas eran impulsadas por la comunidad y a menudo controvertidas porque decisiones de política (“open relay”, “rangos de marcado telefónico”) se mezclaban con señales de abuso.
• “Open relay” solía ser la razón nº1 para listar servidores; hoy es más probable que sean cuentas comprometidas, tráfico de bots o mala higiene de listas.
• El contenido no es el único filtro: los sistemas modernos ponderan mucho las señales de interacción (aperturas, respuestas, eliminaciones sin leer) y las tasas de quejas.
• Muchos receptores prefieren fallos temporales (4xx) sobre bloqueos definitivos (5xx) para frenar el spam sin dar retroalimentación clara a los atacantes.
• DMARC (2012) cambió el juego al permitir que los dominios publiquen cómo deben tratarse los correos no autenticados, lo que también mejoró la visibilidad forense.
• Algunos bloqueos “tipo lista negra” son puramente por tasa: envía demasiado rápido desde una IP nueva y pareces una botnet, aun si cada correo es legítimo.
• Las trampas de spam son reales y variadas: las trampas prístinas nunca se suscribieron; las trampas recicladas fueron usuarios reales—tocarlas grita “mala adquisición”.
• IPv6 complicó la reputación porque el espacio de direcciones es enorme; los receptores se apoyan más en dominio/autenticación y menos en historial de IP individual.

Verificar la lista: IP, dominio y bloqueos “no lista negra”

Necesitas responder tres preguntas:

1. ¿Qué identificador exacto está bloqueado? IP, hostname, nombre HELO, remitente de sobre (envelope sender), dominio From:, dominio DKIM d=, dominio de URL, o alguna mezcla.
2. ¿Quién está bloqueando? ¿Una RBL, un proveedor, una pasarela corporativa o tu propio upstream (smart host) negándose a retransmitir?
3. ¿Es un rechazo duro, una demora temporal o un silencioso envío a spam? Cada uno requiere un enfoque diferente.

IP vs dominio: por qué importa la distinción

La reputación de IP trata de la máquina desde la que envías. Está afectada por patrones de volumen, golpes de trampas de spam y tasas de queja ligadas a esa IP. Rotar la IP puede aliviar el dolor inmediato—pero a costa de parecer un spammer que rota IPs. Eso no es ventaja.

La reputación de dominio trata de la identidad que reclamas. Si tu dominio es tóxico—por phishing, mala alineación de autenticación o años de correo basura—cambiar IPs no te salvará. Los receptores no son peces dorados.

También revisa tu rDNS y HELO

Es 2026 y algunos sistemas aún te fallan por la misma razón que en 2006: sin registro PTR, HELO que no coincide o un hostname que parece parte de un pool residencial dinámico. No es “justo”, son las reglas de la carretera.

Leer los rebotes como un SRE

Los incidentes de entregabilidad son incidentes de alfabetización de logs. Un rebote no es “el correo falló”. Es un error estructurado de un sistema remoto, a menudo con:

• Un código de respuesta SMTP (550, 421, etc.)
• Un código de estado mejorado (5.7.1, 4.7.0)
• Una cadena semihumana (“blocked using…”, “policy reasons”, “rate limit”, “authentication required”)

Los fallos duros (5xx) significan “no reintentes; arregla algo.” Los fallos temporales (4xx) significan “intenta más tarde” pero en la práctica pueden significar “no estamos seguros de que seas legítimo; baja el ritmo y limpia.” Si reintentas agresivamente, puedes convertir un problema temporal en un cráter de reputación permanente.

Piénsalo así: el receptor está haciendo respuesta a incidentes contigo. Te están limitando por ser el vecino ruidoso.

Causas raíz: los sospechosos habituales y los sigilosos

1) Buzón o clave API comprometida

Este es el clásico. Un usuario es phisheado, el atacante envía un pico de spam mediante tu infraestructura legítima y tu IP/dominio queda implicado. Busca:

• Picos de volumen repentinos
• Nuevos países/ASNs en registros de autenticación
• Asuntos, URLs o adjuntos inusuales
• Explosión de quejas y rebotes en minutos

2) Mala higiene de listas (direcciones recicladas, listas compradas)

Si compraste una lista, no compraste prospectos—compraste el historial de abuso de otra persona. Las trampas de spam no se fijan en tu intención. Se fijan en que les enviaste correo.

3) Desalineación de autenticación (SPF/DKIM/DMARC)

Puedes tener SPF y DKIM “pasando” y aun así fallar DMARC porque el dominio autenticado no se alinea con el dominio visible From:. Los receptores cada vez tratan la desalineación como “huele a suplantación”.

4) Errores de infraestructura: rDNS, HELO, TLS y caos oportunista

Faltar PTR o usar un HELO genérico puede activar filtros de política. La falta de TLS no siempre es fatal, pero puede ser una señal entre muchas. Algunos receptores penalizan comportamientos SMTP raros: pipelining extraño, cabeceras mal formadas, Message-IDs defectuosos.

5) Picos de tasa/volumen (legítimos pero sospechosos)

Enviar 10x tu volumen diario normal después de meses de silencio no es “un gran lanzamiento”. Es un patrón de botnet. Calienta IPs/dominios nuevos. Aumenta lentamente. Mide las quejas como si fueran SLOs de latencia.

6) Contaminación de IP compartida

Si estás en una IP saliente compartida (común en ciertos niveles de ESP), otro inquilino puede provocarte límites. La solución suele ser aburrida: cambiar a una IP dedicada o a un pool mejor con aplicación de políticas.

Tareas prácticas (comandos, salidas, decisiones)

Estas son las tareas que ejecuto durante un incidente de reputación de correo. Cada una incluye: comando, salida de ejemplo y la decisión que informa. Ajusta rutas y nombres de servicio a tu entorno (Postfix/Exim/Exchange/PowerMTA/etc.).

Tarea 1: Identificar la IP pública de salida realmente usada para SMTP saliente

cr0x@server:~$ ip route get 8.8.8.8
8.8.8.8 via 203.0.113.1 dev eth0 src 198.51.100.23 uid 0
    cache

Qué significa: Tu probable IP de egress es 198.51.100.23. Si estás detrás de NAT, confirma con tu equipo de firewall; no supongas.

Decisión: Usa esta IP para chequear RBLs y validar rDNS.

Tarea 2: Confirmar que tu MX no está mal apuntado (verificación de dominio)

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Qué significa: El enrutamiento de correo entrante parece normal. Esto no arregla problemas salientes, pero evita perseguir fantasmas causados por una zona DNS rota.

Decisión: Si el MX está mal, arregla DNS primero; las zonas mal gestionadas suelen romper SPF/DKIM/DMARC también.

Tarea 3: Validar que existe un registro SPF y que es sintácticamente razonable

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:198.51.100.23 include:_spf.mailvendor.example -all"

Qué significa: SPF autoriza tu IP y un proveedor. El -all es estricto (bueno) si es correcto (peligroso) si está incompleto.

Decisión: Si tus IPs actuales no están cubiertas, arregla SPF antes de pedir eliminación; de lo contrario los receptores seguirán rechazando.

Tarea 4: Comprobar la política DMARC y expectativas de alineación

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s"

Qué significa: Se requiere alineación estricta para SPF y DKIM. Excelente para anti-spoofing, implacable para configuraciones de proveedores descuidadas.

Decisión: Si los proveedores envían con dominios desalineados, arregla su configuración o relaja la alineación temporalmente—luego vuelve a endurecerla.

Tarea 5: Verificar que DKIM está publicado (selector existe)

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Qué significa: La clave pública DKIM está presente. Eso es necesario pero no suficiente; el firmado debe ocurrir realmente.

Decisión: Si falta, publica DKIM antes de pedir que alguien confíe en ti de nuevo.

Tarea 6: Confirmar rDNS (PTR) para la IP saliente

cr0x@server:~$ dig +short -x 198.51.100.23
mailout1.example.com.

Qué significa: PTR existe y parece un host de correo, no un nombre de pool aleatorio.

Decisión: Si PTR falta o es genérico, arréglalo con tu ISP/proveedor cloud. Muchos receptores desconfían de IPs sin PTR sensato.

Tarea 7: Comprobar que la DNS directa coincide con el PTR (higiene básica)

cr0x@server:~$ dig +short A mailout1.example.com
198.51.100.23

Qué significa: Reverse-confirmed reverse DNS es consistente. Algunos filtros tratan discrepancias como una débil señal negativa.

Decisión: Si no coincide, arregla el registro A o el PTR; no lo dejes “más o menos”.

Tarea 8: Probar banner SMTP, nombre HELO y TLS desde afuera

cr0x@server:~$ openssl s_client -starttls smtp -connect mailout1.example.com:25 -servername mailout1.example.com -crlf
CONNECTED(00000003)
220 mailout1.example.com ESMTP Postfix
...
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250 HELP

Qué significa: El banner SMTP es sensato; STARTTLS se ofrece. Si ves errores de certificado, algunos receptores te bajarán en la puntuación.

Decisión: Si TLS está roto, arregla la cadena de certificados/hostname; es una victoria rápida y mejora señales de confianza.

Tarea 9: Buscar picos de volumen saliente y remitentes top (ejemplo Postfix)

cr0x@server:~$ sudo pflogsumm -d yesterday /var/log/mail.log | sed -n '1,80p'
Postfix log summaries for yesterday

Grand Totals
------------
messages delivered: 12480
messages rejected: 3120
bytes delivered: 912m
hosts/domains: 438

Per-Sender message counts
-------------------------
  8200  alerts@example.com
  2100  marketing@example.com
   960  noreply@example.com

Qué significa: Un remitente (alerts@example.com) domina el volumen. Podría ser una tormenta de alertas real o una cuenta comprometida.

Decisión: Investiga remitentes top y correlaciónalos con despliegues/incidentes. Si está comprometido, desactiva credenciales y purga la cola.

Tarea 10: Inspeccionar la cola de correo en busca de patrones atascados/rebotados

cr0x@server:~$ mailq | head -n 30
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5*    4210 Fri Jan  3 09:12:11  noreply@example.com
                                         user1@bigmail.example
                                         (host mx.bigmail.example[203.0.113.55] said: 421 4.7.0 Temporary rate limit)
F6G7H8I9J0     3988 Fri Jan  3 09:12:14  marketing@example.com
                                         user2@bigmail.example
                                         (host mx.bigmail.example[203.0.113.55] said: 550 5.7.1 IP listed in RBL)

Qué significa: Tienes tanto límites temporales como bloqueos duros. Es común cuando la reputación está decayendo; los proveedores empiezan con 4xx y luego pasan a 5xx.

Decisión: Reduce el envío de inmediato y prioriza arreglar la inclusión/autenticación. Para 4xx, retrocede; para 5xx, para y remedia.

Tarea 11: Extraer la respuesta SMTP remota exacta de los logs (un mensaje)

cr0x@server:~$ sudo grep -F "A1B2C3D4E5" /var/log/mail.log | tail -n 5
Jan  3 09:12:12 mailout1 postfix/smtp[22190]: A1B2C3D4E5: to=<user1@bigmail.example>, relay=mx.bigmail.example[203.0.113.55]:25, delay=1.2, delays=0.1/0/0.5/0.6, dsn=4.7.0, status=deferred (host mx.bigmail.example[203.0.113.55] said: 421 4.7.0 Temporary rate limit)

Qué significa: El código mejorado 4.7.0 y “Temporary rate limit” indican que es throttling, no una RBL. No presentes una solicitud de delisting por esto.

Decisión: Implementa limitación/backoff y mejora señales de reputación; trátalo como política del proveedor, no como “lista negra”.

Tarea 12: Buscar cuentas locales comprometidas que envían correo (logs de auth + submission)

cr0x@server:~$ sudo zgrep -h "sasl_username=" /var/log/mail.log* | awk -F'sasl_username=' '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head
12034 sales@example.com
  220 ops@example.com
   74 hr@example.com

Qué significa: Un usuario SASL es responsable de la mayoría de envíos autenticados. Si eso no es esperado, probablemente esté comprometido o una app lo esté usando mal.

Decisión: Desactiva/resetear esa cuenta, rota contraseñas/keys API, añade MFA y revisa el contenido saliente. Luego purga el spam en cola.

Tarea 13: Comprobar si tu IP está en una DNSBL que puedas consultar (ejemplo con Spamhaus ZEN)

cr0x@server:~$ ip=198.51.100.23; rev=$(echo $ip | awk -F. '{print $4"."$3"."$2"."$1}'); dig +short ${rev}.zen.spamhaus.org
127.0.0.2

Qué significa: Una respuesta tipo loopback indica “listed” (el valor específico insinúa la categoría). Sin respuesta usualmente significa “no listado”.

Decisión: Si estás listado, detén campañas salientes, remedia la causa y luego sigue el procedimiento de delisting de esa lista. No rotes IP y finjas que no pasó.

Tarea 14: Verificar que el nombre HELO coincida con algo real (y no sea localhost)

cr0x@server:~$ postconf -n | grep -E '^myhostname|^smtp_helo_name'
myhostname = mailout1.example.com
smtp_helo_name = mailout1.example.com

Qué significa: Tu identidad HELO es consistente. Si HELO es localhost o una cadena aleatoria, algunos receptores desconfiarán.

Decisión: Ajusta HELO/myhostname a un FQDN estable con DNS coincidente.

Tarea 15: Comprobar controles de tasa salientes (evitar convertir 4xx en 5xx)

cr0x@server:~$ postconf -n | grep -E '^default_destination_rate_delay|^smtp_destination_concurrency_limit|^smtp_destination_rate_delay'
default_destination_rate_delay = 0s
smtp_destination_concurrency_limit = 20
smtp_destination_rate_delay = 0s

Qué significa: No estás limitando el ritmo de entrega. Si un proveedor te está limitando, concurrencia 20 puede ser demasiado alta.

Decisión: Añade retrasos conservadores y reduce concurrency por destino mientras la reputación se recupera.

Tarea 16: Detectar crecimiento repentino de la cola (síntoma a nivel sistema)

cr0x@server:~$ postqueue -p | tail -n 1
-- 1247 Kbytes in 318 Requests.

Qué significa: 318 mensajes en cola pueden ser normales o un incendio, según la línea base. Lo clave es la tendencia.

Decisión: Si la cola crece y los errores remotos son 4xx/5xx, pausa flujos no esenciales y enfócate en la remediación. No “sigas enviando”.

Solicitar la eliminación correctamente (sin empeorar)

La eliminación no es atención al cliente. Es una compuerta de riesgo. Tu trabajo es presentar una historia creíble: “Esto pasó, esto cambiamos y así lo evitaremos.” Si no puedes hacerlo, le pides a un sistema de seguridad que se desactive.

Paso 1: Contener el incidente

• Detén la hemorragia: pausa streams de marketing/masivos; conserva solo el correo transaccional crítico si puedes segmentarlo limpiamente.
• Bloquea remitentes comprometidos: desactiva cuentas, rota credenciales, revoca tokens, aplica MFA.
• Purgar entradas maliciosas en cola: no sigas reintentando spam; extiende el daño y molesta a los receptores.
• Preserva evidencia: logs, muestras de spam, marcas temporales de picos. Las necesitarás para solicitudes de delisting y postmortems internos.

Paso 2: Arreglar la causa raíz antes de pedir perdón

Arreglos “reales” que los equipos de delisting respetan:

• Corregir rDNS y HELO
• Arreglar la alineación SPF/DKIM/DMARC
• Implementar limitación de tasa y backoff
• Eliminar fuentes de listas que generan trampas/quejas
• Proteger buzones y aplicaciones comprometidas
• Segmentar tráfico: transaccional vs marketing en subdominios/IPs separados

Paso 3: Solicitar la eliminación con una narrativa de incidente precisa

Cuando envíes una solicitud de delisting, incluye:

• Las IP(s) y dominios bloqueados (exactos)
• Qué lo provocó (compromiso, mala configuración, higiene de listas, IP compartida)
• Qué cambiaste (controles específicos, fechas, configuración)
• Señales de prueba de mejora (volumen reducido, autenticación ahora pasa, cola limpia)
• Un correo de contacto que realmente llegue a una persona

Y no mientas. Los operadores de listas negras tienen logs, trampas y telemetría. Si afirmas “nunca enviamos spam” mientras tu IP golpea 10k destinatarios/minuto, no estás negociando—estás audicionando para una negación permanente.

Chiste #2: Presentar una solicitud de delisting sin arreglar el compromiso es como repintar el coche mientras aún está en llamas.

Paso 4: Prepárate para un “no” o un “espera”

Algunas listas expiran entradas automáticamente tras un periodo limpio; otras requieren revisión manual; algunas no eliminarán bloques de rangos residenciales/dinámicos. “No” no es personal. Es un límite de política. Si tu negocio depende del correo, necesitas una arquitectura de envío que respete esos límites.

Recuperación de reputación tras la eliminación

Ser eliminado no significa ser confiable. Significa “no marcado activamente por esa lista”. Ahora debes reconstruir la reputación, especialmente con los grandes proveedores de buzones.

Calienta el envío con intención

• Empieza con tus destinatarios más comprometidos (aperturas/respuestas recientes, clientes activos).
• Sube el volumen gradualmente durante días/semanas, no horas.
• Mantén bajas las tasas de queja afinando criterios de lista y añadiendo una baja clara.
• Vigila las demoras (4xx) como señales tempranas; a menudo preceden re-listados.

Separa preocupaciones: transaccional vs marketing

El correo transaccional (restablecimientos, recibos) no debe compartir el destino del marketing masivo. Usa separaciones:

• Subdominios (por ejemplo, mail.example.com vs news.example.com)
• Selectores/llaves DKIM separados
• IPs de envío (idealmente dedicadas para transaccional crítico)

Monitorea como operador, no como marketer

Haz seguimiento de:

• Códigos de respuesta SMTP a lo largo del tiempo (límites vs bloqueos)
• Profundidad de cola y tasas de reintento
• Tasas de pase/alineación de autenticación
• Señales de queja (donde estén disponibles)
• Colocación en carpeta de spam (las pruebas con semillas son imperfectas, pero la tendencia ayuda)

Una cita operativa que realmente me gusta, parafraseando a W. Edwards Deming: no puedes mejorar lo que no mides (idea parafraseada).

Tres microhistorias corporativas desde el frente

Microhistoria 1: El incidente provocado por una suposición equivocada

Una compañía SaaS mediana ejecutaba su propio Postfix para correo transaccional y usaba un ESP separado para marketing. Una mañana, los correos de restablecimiento de contraseña empezaron a rebotar en un proveedor de buzones importante con un rechazo estilo 550 5.7.1 mencionando “policy”. El equipo asumió, con confianza, que “el ESP nos puso en lista negra”.

Esa suposición guió las primeras seis horas de trabajo: reuniones con marketing, comprobaciones frenéticas del contenido de campañas y una solicitud al ESP para “arreglar su reputación de IP”. Mientras tanto, el sistema transaccional seguía reintentando, acumulando cola, y soporte recogía tickets de clientes enfadados como si fueran Pokémon.

Cuando alguien finalmente sacó un único rebote de los logs transaccionales, el rechazo referenciaba la IP saliente de la propia compañía—no el pool del ESP. Una mirada rápida a los logs de submission mostró una cuenta de servicio interna enviando miles de correos “factura lista” a direcciones que no existían desde hacía años. Una migración reciente había reproducido una antigua cola de trabajos, resucitando esencialmente una lista muerta.

Arreglaron el bug del job, purgaron la cola y limitaron la entrega. La inclusión se limpió sola tras un periodo limpio, pero la lección real quedó: nunca adivines qué sistema está fallando. Confirma la ruta de envío primero, luego diagnostica. No puedes discutir con logs. Solo puedes malinterpretarlos.

Microhistoria 2: La optimización que salió mal

Un equipo fintech quería entrega más rápida para alertas sensibles al tiempo. Ajustaron la concurrencia de Postfix y quitaron retrasos porque “la latencia importa”. Lo lograron. Los mensajes llegaban más rápido—hasta que una nueva integración de alertas empezó a enviar ráfagas durante la volatilidad del mercado.

Para los proveedores receptores, el patrón era indistinguible de un remitente comprometido: picos repentinos, contenidos repetidos y alta concurrencia. La primera señal no fue una lista negra. Fueron demoras: 421 4.7.0 limitiaciones de tasa. El equipo interpretó eso como “inestabilidad del proveedor” y subió aún más la concurrencia para “forzar el envío”.

Así se convierte una luz amarilla en colisión. El proveedor escaló de throttling a rechazos duros. Luego listas secundarias empezaron a marcar la IP porque los reintentos parecían un run de spam persistente. La optimización—eliminar el backoff—amplificó el modo de fallo.

La solución fue irónicamente un paso atrás: reintroducir pacing por destino, limitar la concurrencia e implementar supresión de alertas para que el mismo destinatario no recibiera bombardeos. La entrega se hizo algo más lenta en picos, pero mucho más fiable. La empresa aprendió una verdad SRE: rendimiento sin bucles de control es solo una falla más rápida.

Microhistoria 3: La práctica aburrida pero correcta que salvó el día

Un proveedor de salud tenía una política que sonaba aburrida en revisiones de diseño: correo transaccional solo desde un subdominio e IP dedicados, con alineación DMARC estricta y credenciales separadas por aplicación. Era molesto. La gente se quejaba de “demasiados registros DNS” y “configuración extra para proveedores”.

Entonces se comprometió el buzón de un contratista y el atacante usó la plataforma corporativa para enviar phishing a externos. El dominio corporativo sufrió un golpe de reputación y parte del correo saliente de usuarios empezó a ir a spam.

Pero las notificaciones críticas para pacientes siguieron fluyendo porque provenían del dominio e IP transaccional aislados, con autenticación limpia y volumen controlado. Los receptores lo trataron como una identidad separada con historial separado. El impacto en soporte fue contenido. El impacto en cumplimiento fue contenido. El impacto en liderazgo fue contenido—siempre lo más difícil.

Siguió habiendo un incidente y se hizo la limpieza, pero la separación de preocupaciones evitó que un fallo de entregabilidad se convirtiera en un outage operativo. La práctica aburrida no era glamorosa. Era efectiva. Ese es el trabajo.

Errores comunes: síntoma → causa raíz → solución

1) “Estamos listados en todas partes”

Síntoma: Algunos destinatarios rebotan, otros no; el equipo interno dice “todo está bloqueado”.

Causa raíz: Mezcla de fallos diferentes: un proveedor limitando tasa (4xx), otro usando una RBL específica (5xx) y otros mandando a spam silenciosamente por reputación de dominio.

Solución: Categoriza fallos por destino y código. Construye una tabla: proveedor → cadena de error → IP/dominio involucrado → acción (throttle/arreglar auth/delist).

2) “SPF pasa, así que la autenticación está bien”

Síntoma: Los receptores siguen marcando correo como spam o rechazan con errores de política.

Causa raíz: DMARC no alinea; SPF pasa por otro dominio (p. ej., dominio de rebotes del proveedor), o DKIM firma con un d= no alineado.

Solución: Asegura que el dominio visible From: se alinea con SPF MAIL FROM o DKIM d=. Haz cumplir identidad consistente entre sistemas.

3) “Vamos a conseguir una IP nueva”

Síntoma: El equipo sugiere rotar IP como arreglo rápido.

Causa raíz: Tratar el incidente de reputación como un problema DHCP. Los proveedores ven cambios de IP repentinos como comportamiento evasivo, especialmente si el dominio sigue igual.

Solución: Cambia IPs solo como parte de una migración controlada con warmup, y solo después de detener el abuso y arreglar autenticación/higiene.

4) “Pedimos eliminación pero nada cambió”

Síntoma: Eliminado de una RBL; la entregabilidad sigue mala.

Causa raíz: El bloqueo real es la reputación del proveedor, no la RBL. O estás listado en múltiples feeds, o la reputación del dominio está dañada.

Solución: Verifica qué entidad te está rechazando. Reduce quejas, arregla alineación, baja la velocidad y reconstruye compromiso. El delist de una RBL a veces es necesario, rara vez suficiente.

5) “Seguimos reintentando; al final pasará”

Síntoma: La cola crece, tormentas de reintentos, aparecen más bloqueos.

Causa raíz: Reintentos agresivos contra deferidos 4xx parecen comportamiento abusivo y pueden escalar penalizaciones de reputación.

Solución: Implementa backoff exponencial, reduce concurrencia y pausa correo no crítico hasta que las demoras bajen.

6) “Solo un proveedor nos bloquea, así que es su bug”

Síntoma: Gmail (o Microsoft, o Yahoo) rechaza; dominios más pequeños aceptan.

Causa raíz: Los grandes proveedores tienen modelos de reputación más estrictos y más telemetría; los dominios pequeños pueden filtrar menos (o estar menos protegidos).

Solución: Trata los bloqueos de grandes proveedores como tu sistema de alerta temprana. Arregla tus señales; no busques receptores más laxos.

7) “Limpiamos, pero nos re-listaron”

Síntoma: Recuperación breve seguida de otra inclusión.

Causa raíz: La causa raíz no se eliminó completamente (credencial aún activa, fuente de listas mala, automatización mal configurada), o el warmup fue demasiado agresivo.

Solución: Re-audita remitentes, rota todas las claves relevantes, aplica controles de tasa y reinicia el warmup con solo destinatarios comprometidos.

Listas de verificación / plan paso a paso

Checklist A: Primera hora de respuesta (contención)

1. Congela envíos masivos (marketing, resúmenes, notificaciones de baja prioridad).
2. Confirma la(s) IP(s) de envío usadas por el flujo que falla (no supongas).
3. Extrae 3 rebotes reales de 3 destinos principales; registra códigos SMTP y mejorados.
4. Revisa cuentas comprometidas por usuarios SASL top o tokens API.
5. Purgar spam en cola (con cuidado; no borres correo transaccional legítimo sin backups).
6. Habilita throttling por destino; reduce concurrencia.

Checklist B: Remediación el mismo día (hacer el sistema confiable)

1. Arreglar rDNS y HELO a nombres DNS estables y coincidentes.
2. Confirmar que SPF cubre todos los remitentes y no excede límites de lookup por abuso de includes.
3. Asegurar que DKIM firme realmente los mensajes salientes y se alinee con From: donde sea requerido.
4. Revisar configuración DMARC y ajustar configuraciones de proveedores.
5. Asegurar autenticación: MFA para buzones, keys API con alcance limitado, principio de menor privilegio para submission SMTP.
6. Segmentar streams: transaccional vs marketing con subdominios/IPs separados cuando sea posible.

Checklist C: Ejecución de delisting (cuando estés listo)

1. Identificar listas exactas que afectan entregabilidad (desde mensajes de rebote y consultas DNSBL).
2. Confirmar que ya no emites tráfico abusivo (volumen normal, cuentas comprometidas cerradas, cola limpia).
3. Redactar una nota de incidente concisa: qué pasó, cuándo, qué se cambió, cómo se prevendrá recurrencia.
4. Enviar solicitudes de delisting con identificadores correctos (IP, dominio, rangos según requiera cada lista).
5. Rastrear resultados por lista/proveedor; no asumas que una aprobación arregla todo.

Checklist D: Recuperación y prevención (la parte que te mantiene fuera de listas)

1. Calentar gradualmente con destinatarios comprometidos; subir volumen con guardrails.
2. Instrumentar resultados SMTP (tasas 4xx/5xx por dominio) y alertar por anomalías.
3. Implementar higiene de listas: opt-in confirmado cuando sea posible, eliminar rebotes, respetar bajas rápidamente.
4. Ejecutar auditorías periódicas de autenticación (SPF/DKIM/DMARC se desalinean con cada proveedor añadido).
5. Documentar un runbook de entregabilidad igual que documentas un runbook de outage.

Preguntas frecuentes

1) ¿Cómo sé si es una blacklist de IP versus reputación de dominio?

Si los rebotes mencionan tu IP explícitamente (“listed”, “RBL” o muestran la IP), está centrado en la IP. Si varias IP fallan por el mismo From: dominio o DMARC falla, es centrado en dominio. A menudo son ambos.

2) Si estoy en una RBL, ¿todos me bloquearán?

No. Los receptores eligen qué listas usar (si alguna). Algunos no usan listas públicas y confían en scoring interno. Trata los mensajes de rebote de cada destino como la fuente de la verdad.

3) ¿Debería detener todo el correo mientras estoy listado?

Detén lo masivo no crítico de inmediato. Para correo transaccional crítico, a veces puedes continuar con throttling agresivo y solo a destinatarios comprometidos—pero solo si estás seguro de haber contenido la fuente del abuso.

4) ¿Puedo pagar a alguien para que me quite de las listas negras?

Algunos servicios “ayudan”, pero si no arreglan la causa raíz, te venden un ciclo más corto hasta volver a estar listado. Paga por trabajo de ingeniería: autenticación, segmentación, higiene, monitorización.

5) ¿Por qué recibo errores 4xx “rate limit” en vez de un mensaje claro de blacklist?

Porque los receptores prefieren ralentizar a remitentes sospechosos sin dar a los spammers una señal clara de sí/no. Además, el throttling es reversible y más barato que rebotar millones de mensajes.

6) ¿DMARC p=reject mejora la entregabilidad?

Puedes mejorar la confianza con el tiempo al prevenir el spoofing de tu dominio, pero no arreglará mágicamente un programa de envíos malo. Si tus sistemas no están alineados, te romperá tu propio correo primero. Despliega en etapas.

7) Usamos una IP compartida en un ESP. ¿Qué podemos hacer?

Pide moverte de pool, reduce los factores que generan quejas y asegúrate de que tu autenticación alinee. Si el correo es crítico, reserva presupuesto para una IP dedicada y un plan de warmup. Los pools compartidos están bien hasta que no lo están.

8) ¿Cuánto tarda la recuperación de reputación?

De “un día” a “semanas”. Si fuiste comprometido y se esparció spam, espera una cola larga. La velocidad de recuperación depende más de conducta limpia consistente que de cuántos formularios rellenes.

9) ¿Cuál es la desconfiguración técnica más común que veo durante un delisting?

Autenticación desalineada: SPF pasa por un dominio, DKIM firma otro y From: muestra un tercero. Los receptores ven eso como confusión de identidad en el mejor caso y spoofing en el peor.

10) ¿Qué pasa si estamos bloqueados por la reputación del bloque de red de nuestro proveedor de hosting?

Pasa. Si tu ASN/rango se considera de alto abuso, puede que necesites mover el correo saliente a un proveedor de correo reputado, usar un relay con fuerte enforcement o migrar espacio IP y calentar correctamente.

Conclusión: próximos pasos que realmente funcionan

Si sacas una lección operativa de esto: la eliminación es el último paso, no el primero. El camino más rápido hacia la entrega restaurada es aburrido y medible en ingeniería.

1. Extrae rebotes reales y clasifica fallos (RBL vs política del proveedor vs throttling).
2. Contén el abuso: detén lo masivo, bloquea cuentas comprometidas, purga entradas maliciosas en cola.
3. Arregla identidad e higiene: rDNS/HELO, alineación SPF/DKIM/DMARC, TLS sensato, limitación de tasa.
4. Pide eliminación solo cuando estés limpio, con una narrativa de incidente creíble.
5. Calienta y monitorea como monitorizas latencia: tendencias, alertas, guardrails.

Tu objetivo no es “ser eliminado”. Tu objetivo es “ser el tipo de remitente que nadie necesita listar”. Eso es un problema de sistemas. Trátalo como tal.