Comprobar lista negra de correo: lo que omiten las webs

Comprobar lista negra de correo no equivale a saber si su mensaje llegará al buzón. Al introducir su IP de envío en una herramienta multilista, obtiene una tabla de filas verdes y rojas. Esa tabla responde a una pregunta muy concreta: ¿aparece esta dirección hoy en un conjunto de listas DNS públicas? No dice si Gmail, Outlook o una pasarela corporativa aceptarán su próximo envío. Tratar ambas preguntas como una sola es donde se tuercen la mayoría de las cronologías de incidentes.

Esta guía explica qué consulta realmente una comprobación, cómo ejecutarla con dig, qué códigos significan «limpio» y cuáles significan «su consulta fue rechazada», y cómo integrarla en la monitorización para dejar de hacerla a mano a las 2 de la madrugada.

Una comprobación de lista negra es solo una consulta DNS

Cada lista negra DNS (DNSBL) funciona del mismo modo. Se invierten los octetos de la dirección IPv4, se añade la zona de la lista y se pide un registro A. La RFC 5782 define esta convención: para 192.0.2.99 consultada contra bad.example.com, la consulta es 99.2.0.192.bad.example.com. Si la dirección está listada, la respuesta cae en el rango 127.0.0.0/8. Si no lo está, no hay registro.

Ese es todo el mecanismo. Las herramientas web en las que pega una IP lanzan decenas de estas consultas en paralelo y dan formato a las respuestas.

# ¿Está 203.0.113.25 listada en Spamhaus ZEN?
dig +short 25.113.0.203.zen.spamhaus.org A

# Una lista basada en dominios funciona igual, sin invertir nada:
dig +short example.com.dbl.spamhaus.org A

Una salida vacía significa que no está listada. Una respuesta 127.x.x.x significa que sí lo está, y los últimos octetos indican qué sublista ha coincidido. Ejecútelo desde una máquina que controle, con su propio resolver, y podrá automatizarlo, registrarlo y generar alertas.

Compruebe la dirección desde la que sale el correo, no la de su web

El primer error es consultar la IP equivocada. Su sitio de marketing, su API y su relay de envío suelen ser tres direcciones distintas. La que importa es la IP que aparece en la cabecera Received de un mensaje que llegó de verdad a un buzón.

Si envía a través de un ESP con infraestructura compartida, esa IP no es suya, y el listado tampoco. Si envía desde una IP dedicada, es completamente suya, incluido lo que hizo el anterior ocupante de ese rango.

Tome la IP de envío de un mensaje entregado, no de un ajuste del panel. Después compruebe tres cosas por separado: la IP de envío, los dominios del remitente y del sobre, y todos los dominios que aparecen en sus enlaces, incluidos los hosts de seguimiento y de baja. Las listas basadas en URI, como URIBL y SURBL, puntúan los enlaces del cuerpo del mensaje, así que una IP limpia no protege un mensaje que apunta a un dominio listado.

Un resultado limpio desde un resolver público puede ser un rechazo disfrazado

Este es el modo de fallo que las páginas genéricas de comprobación nunca mencionan. Spamhaus no responde a consultas que llegan a través de resolvers públicos o abiertos, y lo indica con un código de retorno en lugar de con un listado. Spamhaus documenta 127.255.255.254 como código de error, no como resultado de reputación, y señala que nunca debe usarse para rechazar correo.

Se derivan dos consecuencias. Si su script interpreta cualquier respuesta 127.x como «listada», una consulta rechazada desde un resolver de nube le avisará de un listado que no existe. Si interpreta «ninguna respuesta útil» como «limpia», se le escaparán en silencio listados reales, porque el rechazo también puede manifestarse como una respuesta vacía o NXDOMAIN.

La solución es ejecutar las consultas desde un host con su propio resolver recursivo y un DNS inverso correcto, o usar el servicio de consulta gratuito al que Spamhaus remite a quienes usan sus espejos públicos. Y valide la zona antes de fiarse de ella. La RFC 5782 exige que las listas IPv4 tengan una entrada para 127.0.0.2 y ninguna para 127.0.0.1, así que puede probar su configuración así:

dig +short 2.0.0.127.zen.spamhaus.org A   # debe devolver una respuesta 127.x
dig +short 1.0.0.127.zen.spamhaus.org A   # no debe devolver nada

Si ambas devuelven vacío, la ruta de su resolver está rota o rechazada. Corríjalo antes de leer ningún resultado procedente de ella.

La mayoría de los incidentes de entrega no son incidentes de listas negras

En una revisión de rebotes, lo primero que hacemos antes de cualquier consulta es leer qué respondió exactamente el servidor receptor. Un listado produce un rechazo específico. Los problemas de reputación en un proveedor de buzones producen otro distinto, y ninguna lista pública los mostrará.

La documentación de Google para remitentes es directa al respecto. Una respuesta 550 5.7.1 puede significar que la IP de envío está en una lista de suspendidos, a menudo por mala reputación de IP compartida, mientras que 5.7.26 apunta a una autenticación fallida. Para remitentes masivos, Google exige SPF, DKIM y DMARC, DNS directo e inverso válidos en la IP de envío, TLS y una tasa de spam inferior al 0.30% en Postmaster Tools. Los requisitos de remitente de Gmail recomiendan como objetivo el 0.10%.

Léalo como un orden de operaciones. Si el texto del rebote nombra una zona DNSBL, tiene un problema de listado. Si menciona reputación, autenticación o límite de velocidad, una comprobación de lista negra saldrá limpia y habrá perdido una hora confirmándolo.

• Nombra una zona o URL DNSBL: está listada en esa lista concreta. Ejecute la consulta y use la página de retirada de esa lista.

• 550 5.7.1 con texto sobre «reputación de IP»: reputación en el lado del proveedor, a menudo en una IP compartida. Revise Postmaster Tools y la tendencia de volumen y quejas.

• 5.7.26: la autenticación falló. Revise la alineación de SPF, DKIM y DMARC.

• 4.7.28 o texto sobre límites de velocidad: envía demasiado rápido para su reputación actual. Limite el ritmo y luego vuelva a subirlo gradualmente.

No use un comprobador puntual como su monitorización

Una consulta aislada le dice el estado en el momento en que pulsó Intro. Los listados suelen ser transitorios, y muchos aparecen tras un pico que usted mismo provocó: una importación en frío, un envío masivo de repermiso o un formulario comprometido que alguien usó para retransmitir spam.

Las herramientas que cobran por «sacarle de 100 listas negras» venden un servicio para un problema que la mayoría de esas listas no tiene. Muchas de las listas de una comprobación multilista típica tienen un impacto insignificante en los grandes proveedores de buzones, y la retirada suele ser gratuita y de autoservicio en la propia página del operador. Perseguir cada fila roja le hace perder tiempo que debería dedicar a las dos o tres listas que consultan sus destinatarios.

Ordene las listas según el tráfico que envía. Mire qué receptores aparecen en sus rebotes, localice las listas que esos receptores consultan públicamente y vigile esas. Todo lo demás es ruido que puede revisar cada mes.

Convierta la comprobación en una tarea programada con un umbral de alerta

Esta es la versión mínima que aguanta en producción. Se ejecuta desde un host con un resolver real, valida la zona primero y distingue tres resultados: listada, no listada y consulta rechazada.

import socket

def dnsbl(ip: str, zone: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        answer = socket.gethostbyname(f"{rev}.{zone}")
    except socket.gaierror:
        return "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # código de error, no un resultado de reputación
    return f"listed:{answer}"

# Compruebe la zona antes de confiar en ella (entradas de prueba de la RFC 5782)
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

Ejecútelo cada 15 a 60 minutos por IP de envío y por dominio de envío, registre cada resultado con marca de tiempo y avise solo ante una transición de not_listed a listed. Avise por separado de refused, porque significa que su monitorización está ciega, no que su reputación haya cambiado.

Acompáñelo con las señales que las listas negras suelen retrasar. La tasa de quejas de los paneles de Postmaster, la tasa de rebotes por dominio receptor y la tasa de aplazamientos por hora se mueven antes de que aparezca un listado, y son los números que le dicen si conviene pausar un envío. Si ya envía logs y métricas a una pila de monitorización, el resultado de la consulta es solo una serie temporal más.

Cuatro herramientas encajan en este flujo, según dónde esté el problema.

Postmark es un servicio solo transaccional, así que sus restablecimientos de contraseña no comparten vía de envío con el boletín de otra persona. Si sus listados siguen remontándose a un vecino en infraestructura compartida, separar el envío transaccional del de marketing es la solución estructural.

Resend es la opción orientada a desarrolladores si quiere una API limpia y una superficie pequeña que instrumentar. Merece la pena cuando su equipo va a programar de todos modos sus propias comprobaciones de entregabilidad.

SendGrid tiene el historial más largo a gran volumen y ofrece IP dedicadas, lo que significa que la reputación, y la exposición a listas negras, son solo suyas. Descártelo si no puede dedicar personal al calentamiento y la monitorización que exigen las IP dedicadas.

Better Stack es la pieza para el lado de las tareas programadas: comprobaciones tipo uptime, alertas y enrutamiento de guardia para el script de consulta de arriba, de modo que un nuevo listado llegue a una persona y no a un archivo de logs.

Cuando esté listado, corrija la causa antes de pedir la retirada

Retirar un listado sin encontrar la causa le compra unos pocos días. El operador de una lista que vuelve a ver la misma dirección con el mismo comportamiento la listará de nuevo, y algunos operadores escalan los listados repetidos.

Trabaje en este orden:

1. Pare o limite el envío desde la IP listada. Más tráfico malo prolonga el listado y añade nuevos.

2. Lea el registro de listado del operador. Muchos indican la evidencia: un acierto en una trampa de spam, un pico o un informe de abuso de relay.

3. Encuentre el origen. Revise los endpoints de formularios por posible abuso de relay abierto, mire las importaciones de listas recientes y revise cualquier integración nueva que haya empezado a enviar en la última semana.

4. Corrija la causa y use el proceso de retirada del propio operador. Algunas listas caducan los listados automáticamente tras un período de calma.

5. Reanude con un volumen reducido, primero a sus destinatarios más activos, y vigile la tasa de quejas y los aplazamientos durante una semana.

El DNS inverso ausente es un factor recurrente. Google incluye los registros PTR válidos entre sus requisitos de remitente, y una IP de envío sin uno parece de baja confianza para muchos receptores antes de que se evalúe el contenido.

Si su producto envía correos de activación, facturación o seguridad, un listado es una incidencia de disponibilidad para esos flujos. Trátelo así: enrute el correo transaccional por una vía aislada del volumen de marketing. Lo que vale la pena copiar, aunque elija otros proveedores, es que un evento de lista negra debería cambiar por dónde va un mensaje, no si su lógica de activación funciona.

Qué pondríamos en marcha esta semana

Tres cosas, por orden de rentabilidad. Primero, una consulta programada con validación de zona y un estado refused diferenciado, ejecutada desde un host con su propio resolver. Segundo, el desglose por dominio receptor de sus rebotes, para saber qué listas importan a su tráfico. Tercero, un runbook escrito que empiece por el texto del rebote y termine en el paso de retirada, para que quien esté de guardia no improvise.

¿Qué dominio de envío no notaría si estuviera listado durante un día?