Inicio › Guías

Monitorización de listas negras: scripts, API y alertas por webhook

Publicado 2026-11-03 ／ Actualizado 2026-11-03 ／ Por Yuki Nakazawa

Monitorizar listas negras consiste en consultar periódicamente varias listas de bloqueo DNS (DNSBL) para las IP y los dominios de envío, y lanzar una alerta solo cuando cambia un resultado. Detectar una inclusión en el momento en que se produce, y no cuando los clientes avisan de correos rebotados, deja tiempo para encontrar la causa y solicitar la eliminación antes de que el daño se extienda.

Hay dos formas prácticas de hacerlo: ejecutar uno mismo un pequeño script con dig y cron, o delegar las comprobaciones en un servicio mediante una API y webhooks. En ambos casos, dos detalles deciden si el monitor dice la verdad: las listas como Spamhaus rechazan las consultas enviadas a través de resolvedores públicos, que producen respuestas engañosas, y los códigos de error nunca deben contarse como inclusiones.

Las reglas de los operadores de listas citadas aquí se basan en sus páginas oficiales vigentes en noviembre de 2026. Las políticas cambian, así que conviene confirmarlas antes de fiarse de una configuración. Para entender cómo funcionan las DNSBL, consulte qué es una DNSBL (RBL).

Qué vigilar y qué listas consultar

Lo primero es anotar los objetos que de verdad hay que vigilar.

• Direcciones IP de envío. Son las direcciones desde las que envía realmente el servidor de correo o el proveedor de correo. El sitio web y el correo suelen salir de máquinas distintas, así que conviene confirmar la dirección en las cabeceras Received de un mensaje enviado. Si se envía por IPv6, también hay que vigilar esas direcciones.
• Dominios. El dominio de la dirección From y cualquier dominio que aparezca en los enlaces de los mensajes. Los dominios se comprueban en listas de bloqueo de dominios, que son distintas de las listas de IP.

El formato de consulta se define en el RFC 5782. En IPv4 se invierten los octetos y se añade la zona de la lista, de modo que 192.0.2.99 en una lista se convierte en 99.2.0.192 seguido del nombre de la zona. En IPv6 la dirección se escribe como 32 nibbles hexadecimales en orden inverso. Un dominio simplemente se antepone a la zona. Una entrada listada devuelve un registro A, por convención dentro de 127.0.0.0/8; una no listada devuelve NXDOMAIN. El RFC señala además que las listas deberían publicar un registro TXT que explique el motivo de la inclusión.

Conviene vigilar varias listas y no solo una, porque no todos los receptores usan las mismas. El significado de cada código de retorno varía según el operador; nuestra guía de códigos de retorno de las DNSBL recoge los más habituales.

Por qué los resolvedores públicos dan respuestas erróneas

Un error habitual en la monitorización casera es enviar las consultas a través de un resolvedor público como Google Public DNS (8.8.8.8) o Cloudflare (1.1.1.1). Las preguntas frecuentes oficiales de Spamhaus sobre el uso de DNSBL explican lo que ocurre:

• El uso gratuito de las DNSBL de Spamhaus exige que el uso no sea comercial y que las consultas no procedan de un resolvedor público o abierto, ni de una IP con DNS inverso genérico.
• A través de resolvedores abiertos gratuitos como Google Public DNS, las consultas recibirán en la mayoría de los casos una respuesta de no listado (NXDOMAIN). Dicho de otro modo, una IP listada puede parecer limpia.
• Las consultas a través de un resolvedor público también pueden recibir 127.255.255.254. Es un código de error, no una inclusión. Del mismo modo, 127.255.255.252 indica un error tipográfico en el nombre de la DNSBL y 127.255.255.255 indica un número excesivo de consultas. Spamhaus indica que estos códigos no deben interpretarse como que el objeto consultado está listado.
• Los resolvedores que reescriben las respuestas NXDOMAIN devuelven en su lugar una dirección IP, así que nunca se ve el NXDOMAIN correcto.

La principal recomendación de las preguntas frecuentes es usar un resolvedor DNS propio. Para quienes deban seguir con un resolvedor público, Spamhaus remite a su Data Query Service (DQS); conviene revisar sus condiciones para saber qué es gratuito. Las preguntas frecuentes sugieren dig txt whoami.fastly.net para ver qué resolvedor se está usando realmente.

El RFC 5782 añade una comprobación de coherencia integrada: una lista IPv4 debe contener una entrada para 127.0.0.2 y no debe contener 127.0.0.1, y los clientes deberían comprobar periódicamente estas entradas de prueba para confirmar que la lista funciona. En el ejemplo de Spamhaus, 2.0.0.127.zen.spamhaus.org devuelve 127.0.0.10, 127.0.0.4 y 127.0.0.2, mientras que 1.0.0.127.zen.spamhaus.org devuelve NXDOMAIN. Un monitor debería comprobar esto primero y descartar la ejecución si falla.

Opción 1: un script con dig y cron

Este es un script mínimo que comprueba una dirección IPv4 en Spamhaus ZEN y en SpamCop (bl.spamcop.net, que según la documentación de SpamCop responde 127.0.0.2 para una IP listada). Sustituya la dirección y las zonas por las suyas.

#!/bin/sh
# Consultar el resolvedor recursivo propio (p. ej., unbound en el mismo host), nunca uno público
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # Si la entrada de prueba 127.0.0.2 no resuelve a un código de inclusión, no fiarse de esta ejecución
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

Qué hace el script:

• Solo un estado NXDOMAIN cuenta como limpio, 127.255.255.x es un error y cualquier otro 127.x es una inclusión. Todo lo que quede fuera de 127.0.0.0/8 se trata como una anomalía, por ejemplo un resolvedor que reescribe respuestas.
• Un tiempo de espera agotado hace que dig termine con un código distinto de cero, mientras que SERVFAIL y REFUSED terminan con 0. Ninguno de ellos se trata como limpio; el script registra un error.
• Los códigos de retorno son propios de cada lista. Algunas listas usan 127.0.0.1 para indicar, por ejemplo, que se rechazó una consulta, así que conviene leer la documentación de cada lista que se añada y ampliar la sentencia case cuando haga falta.

Después, cron puede comparar cada ejecución con la anterior y enviar correo solo cuando algo haya cambiado:

# Example: run hourly, send mail only when the output differs from the last run
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

El intervalo de una hora es solo un ejemplo. Spamhaus ofrece acceso gratuito para un uso no comercial de bajo volumen, y los clientes que superan su umbral de volumen de consultas necesitan una opción de pago; conviene revisar las condiciones de cada lista a medida que crece el número de IP vigiladas. Las preguntas frecuentes aconsejan además repetir los comandos varias veces para confirmar que los resultados no cambian.

Opción 2: la API por lotes y los webhooks de DNSBL Checker

Si se prefiere no mantener un resolvedor ni reglas de interpretación para cada lista, se puede dejar que un servicio haga las comprobaciones. A continuación se describe la API v1 de este sitio, limitada a lo que hace realmente la implementación del servidor. La referencia está en /en/api-docs y las claves se emiten en la página de miembros, en /account. Para registrarse solo hace falta una dirección de correo, y el inicio de sesión se hace con un enlace enviado por correo.

Autenticación y límites

• Las claves empiezan por dnsbl_ y se muestran una sola vez, justo después de emitirse; solo se guarda un hash. Volver a emitir una clave invalida la anterior.
• Envíe la clave en la cabecera X-API-Key en cada solicitud. Solo HTTPS; las solicitudes a http:// se redirigen a https://, así que conviene llamar a https:// desde el principio.
• Los límites son 1.000 comprobaciones al día (cada destino cuenta como una), 100 destinos por lote y 50 monitores registrados. Si se supera el límite diario, se recibe 429 con daily_limit_exceeded y una marca de tiempo resets_at.

Comprobaciones por lotes

Envíe un array targets con nombres de dominio o direcciones IP a POST /api/v1/batch:

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

Si algún destino aún está pendiente de comprobación, la respuesta es 202 con un batch_id. Consulte GET /api/v1/batch/{batch_id} cada pocos segundos hasta que status sea done (ejemplo abreviado; los números y el nombre de la lista son ilustrativos, no un resultado real):

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

• verdict es listed si al menos una lista indica una inclusión y, en caso contrario, clean. Las listas que agotaron el tiempo de espera o respondieron con un código de error como 127.255.255.x se cuentan en error_count y nunca como inclusiones.
• Un lote devuelve un resultado guardado si existe uno de los últimos 30 días. Para la monitorización programada, hay que mirar siempre checked_at.
• Los destinos mal formados se devuelven en rejected con un motivo y no se cuentan. Si se pasa una URL, solo se usa el nombre de host. Los rangos reservados para documentación, como 192.0.2.0/24, se rechazan, así que conviene probar con una IP de envío real.

Monitorización por webhook

Registre un target y una callback_url con POST /api/v1/monitors. A partir de ahí, cada destino registrado se comprueba una vez al día sin usar la caché (la primera comprobación se hace en el plazo de aproximadamente un día desde el registro), y se envía un POST en JSON a la URL indicada solo en la primera comprobación (monitor.initial) y cuando el veredicto cambia entre listado y limpio (monitor.status_changed).

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

• El signing_secret de la respuesta se muestra una sola vez. Cada envío lleva una cabecera X-DNSBL-Signature: sha256=..., el HMAC-SHA256 del cuerpo sin procesar calculado con ese secreto como clave. Verifíquelo en su lado.
• callback_url debe ser https en el puerto 443 y resolver a una IP pública; no se siguen las redirecciones y el tiempo de espera es de 10 segundos, así que conviene poner en cola el trabajo pesado y responder rápido.
• Si el endpoint devuelve algo distinto de 2xx, o la conexión falla, el envío se reintenta en la siguiente comprobación diaria. El motivo aparece como last_delivery_error en GET /api/v1/monitors, y DELETE /api/v1/monitors/{monitor_id} elimina un monitor.

import hmac, hashlib
expected = "sha256=" + hmac.new(secret.encode(), raw_body, hashlib.sha256).hexdigest()
ok = hmac.compare_digest(expected, request.headers.get("X-DNSBL-Signature", ""))

Diseño de alertas: frecuencia, varias listas y falsas alarmas

Un monitor solo es útil si alguien sigue leyendo sus alertas al cabo de unos meses. Uno que salta constantemente acaba ignorado enseguida.

Frecuencia

• Hay que separar la frecuencia de las consultas de la frecuencia de los avisos. Consulte de forma programada, pero avise solo cuando cambie el estado. Un mensaje diario de «todo en orden» entierra la única alerta que importa.
• El RFC 5782 dice que los TTL de una lista deberían reflejar la rapidez con que cambia, y que las listas de fuentes de spam pueden usar TTL de minutos. Elija el intervalo sabiendo que algunas inclusiones aparecen y caducan rápidamente.
• Un volumen elevado de consultas puede infringir las condiciones de uso de una lista o hacer que se reciba 127.255.255.255 (consultas excesivas) en lugar de respuestas reales.

Varias listas

• Incluya el nombre de la lista en cada alerta. Las listas difieren en cuántos receptores las usan, así que se puede avisar de inmediato para las listas que más importan a los destinatarios y agrupar el resto en un resumen.
• El webhook descrito arriba solo salta cuando el veredicto cambia entre listado y limpio. Si un destino ya está listado y luego aparece en una segunda lista, no se envía ningún evento. Para detectar ese caso, vigile last_listed_count en GET /api/v1/monitors o ejecute un lote y lea listed_on.

Falsos positivos y respuestas transitorias

• Registrar los errores aparte de las inclusiones. Spamhaus advierte a los operadores que no rechacen ni filtren correo basándose en sus códigos de error; la misma lógica se aplica a la monitorización. Un tiempo de espera agotado o una respuesta 127.255.255.x nunca deberían activar una alerta de inclusión.
• Para no reaccionar ante un único resultado extraño, avise solo tras dos resultados idénticos consecutivos, o repita la consulta unos minutos después antes de enviar nada.
• Si los errores persisten, cabe sospechar un cambio de resolvedor o un cambio por parte de la lista, y lo primero es mirar el resultado de la entrada de prueba.
• Una IP residencial en la Spamhaus PBL es una inclusión por política, no una acusación: significa que la dirección no debería enviar correo directamente. Decida para cada lista qué cuenta como alerta (véase la eliminación en Spamhaus).

Qué hacer cuando se detecta una inclusión

1. Confirmarla. Compruebe la página de consulta del propio operador y anote el nombre de la lista, la hora y cualquier motivo que se muestre.
2. Corregir primero la causa. Busque cuentas comprometidas, formularios web abusados, equipos infectados, mala higiene de las listas y nombres de DNS inverso (PTR) o HELO que no coinciden. Solicitar la eliminación mientras la causa persiste suele llevar a una nueva inclusión.
3. Seguir el proceso de eliminación de esa lista. La decisión de retirar la inclusión corresponde a cada operador, y presentar una solicitud no garantiza que se levante. Si no se controla la IP, como ocurre en un hosting compartido, hay que contactar con el proveedor de hosting o el ISP.
4. Dejar que el monitor confirme el resultado. Los receptores también aplican sus propios filtros, así que conviene vigilar la entrega después de que el veredicto vuelva a limpio.

Para una consulta puntual de una IP o un dominio, use el comprobador de listas negras. Si rastrear la causa o gestionar las solicitudes resulta excesivo, puede pedirnos ayuda. Para el proceso completo de diagnóstico cuando el correo rebota, consulte correo bloqueado por listas negras.

Preguntas frecuentes

Páginas oficiales consultadas

Los datos de este artículo se contrastaron con las páginas oficiales que se indican a continuación en el momento de su publicación. Las políticas y el funcionamiento pueden cambiar sin previo aviso, por lo que conviene consultar las páginas oficiales antes de tomar decisiones importantes.

• RFC 5782: DNS Blacklists and Whitelists
• Spamhaus FAQ: DNSBL Usage
• Spamhaus: Using our public mirrors? Check your return codes now
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?

Guías relacionadas

Todas las guías →