Inicio › Guías

Qué es una DNSBL (RBL) y cómo funcionan las listas negras DNS

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

Una DNSBL (lista negra basada en DNS, también llamada lista de bloqueo DNS o RBL) es una lista de direcciones IP o nombres de dominio que el operador de la lista considera una fuente de spam o de abusos, publicada para que cualquiera pueda consultarla con una búsqueda DNS normal. Los servidores de correo consultan cada remitente que se conecta en una o varias DNSBL y, según el resultado, rechazan el mensaje, lo aceptan o suman ese dato a una puntuación de spam.

Esta guía explica cómo funciona una consulta DNSBL (direcciones IP invertidas, registros A y TXT, formato nibble de IPv6), la diferencia entre listas basadas en IP y basadas en dominios, cómo usan realmente los receptores las respuestas, en qué se diferencian las listas negras de las listas blancas, por qué se listan las direcciones y qué papel tiene una inclusión cuando el correo no se entrega. Se basa en el RFC 5782 y en la documentación oficial de los principales operadores de listas vigente en noviembre de 2026.

Qué significan DNSBL y RBL

El RFC 5782, «DNS Blacklists and Whitelists», usa el término general DNSxL para una zona DNS cuyos registros identifican los hosts de una lista. Una lista negra es una DNSBL; una lista blanca es una DNSWL. Ambas se construyen igual. Solo cambia el significado que el receptor da a una coincidencia.

RBL son las siglas de Real-time Blackhole List. Según el RFC, la primera lista de este tipo se creó en 1997 y se hizo conocida con ese nombre. En sentido estricto, RBL se refiere a esa lista original y a su sucesora, y el RFC señala que el término es una marca de servicio registrada en Estados Unidos. En el uso cotidiano, sin embargo, «RBL» y «DNSBL» se usan casi como sinónimos, así que «qué es una RBL» y «qué es una DNSBL» son en la práctica la misma pregunta.

El RFC 5782 es un documento informativo (Informational), no un estándar de Internet. Lo elaboró el grupo Anti-Spam Research Group del IRTF y recoge el consenso de ese grupo sobre prácticas que mejoran la interoperabilidad entre listas negras y blancas DNS. No describe ni recomienda políticas para añadir o retirar direcciones; el RFC prevé que eso se trate en un documento aparte. En la práctica, cada operador fija su propia política de inclusión y exclusión.

Cómo funciona una consulta DNSBL

Una consulta DNSBL es una consulta DNS normal, así que una comprobación manual no requiere software especial: cualquier cosa capaz de resolver un nombre puede consultar una lista. Eso sí, los operadores pueden fijar condiciones de uso. Los servidores públicos de Spamhaus, por ejemplo, solo son gratuitos para un uso no comercial de bajo volumen, y las consultas a través de resolvedores públicos no reciben respuestas fiables (véase más abajo).

IPv4: invertir la dirección y añadir la zona

Para una dirección IPv4, se escriben los cuatro octetos en orden inverso y se añade el nombre de la zona de la lista. La estructura procede del DNS inverso. El ejemplo del RFC 5782 comprueba 192.0.2.99 en una lista situada en bad.example.com consultando:

99.2.0.192.bad.example.com

El registro A dice «listado»; el TXT dice por qué

• Registro A. Toda entrada listada debe tener un registro A. Por convención, su valor es 127.0.0.2. El valor es una señal, no una dirección, y no debe usarse como tal; las listas usan el rango 127.0.0.0/8 para que un valor usado por error no genere tráfico de red no deseado.
• No listado. Si la dirección no está en la lista, no hay registros para ella, así que la consulta normalmente devuelve NXDOMAIN.
• Registro TXT. Una DNSBL debería publicar un registro TXT que describa el motivo de la inclusión. Los clientes deben comprobar el registro A y pueden comprobar también el TXT.
• Valores distintos para sublistas distintas. Una lista combinada puede devolver distintos valores 127.0.0.x para indicar qué sublista coincidió, o varios registros A a la vez. El significado es propio de cada lista, así que siempre hay que leer la documentación del operador. Nuestra guía de códigos de respuesta de las DNSBL recoge los más habituales.

Desde un terminal (la zona es un marcador de posición):

dig +short 99.2.0.192.bad.example.com A
dig +short 99.2.0.192.bad.example.com TXT

Entradas de prueba

El RFC 5782 exige que las listas IPv4 contengan una entrada para 127.0.0.2 y que no contengan ninguna para 127.0.0.1. Se espera que los clientes comprueben estas entradas de prueba antes de confiar en una zona, y que no usen una zona que las responda de forma incorrecta.

IPv6: el formato nibble

Una dirección IPv6 se escribe completa como 32 dígitos hexadecimales y luego se invierte dígito a dígito (un nibble cada vez), con un punto entre cada uno, seguida de la zona de la lista. El ejemplo del RFC, para 2001:db8:1:2:3:4:567:89ab en ugly.example.com:

b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ugly.example.com

Las listas IPv6 deben contener la entrada de prueba ::FFFF:7F00:2 (127.0.0.2 como dirección IPv4 mapeada) y no deben contener ::FFFF:7F00:1. No todas las listas admiten IPv6, así que conviene revisar la documentación del operador antes de fiarse de una consulta IPv6.

Listas basadas en IP y listas basadas en dominios

Hay dos grandes tipos de listas, según lo que contienen.

En el ejemplo de dominio del RFC 5782, invalid.edu se comprueba en doms.example.net consultando invalid.edu.doms.example.net. Las listas basadas en dominios se conocen a veces como RHSBL (right-hand-side blacklist, lista negra de la parte derecha). Sus entradas de prueba usan nombres reservados: la lista debe contener TEST y no debe contener INVALID.

La Spamhaus Domain Blocklist (dbl.spamhaus.org) es un ejemplo muy utilizado, y su documentación hace algunas observaciones prácticas:

• Solo contiene dominios. Consultarla con una dirección IP siempre devuelve un código de «listado», así que no debe configurarse como una DNSBL de IP genérica. Para consultas de IP, Spamhaus recomienda ZEN (zen.spamhaus.org).
• Se puede consultar un nombre de host completo; coincide si el dominio del host está listado.
• Durante la sesión SMTP se comprueba con la cadena HELO y con el dominio de MAIL FROM. Después de aceptar el mensaje, se comprueba con los dominios de las cabeceras y del cuerpo, como URL y direcciones de contacto.

La consecuencia práctica: una IP de envío limpia no garantiza la entrega. Un dominio de envío listado, o un dominio listado enlazado en el mensaje, puede provocar igualmente un bloqueo.

Cómo usan las DNSBL los servidores receptores

El RFC 5782 describe la configuración típica. Un servidor de correo comprueba un conjunto configurado de DNSxL en cada conexión SMTP entrante. Una coincidencia en una lista negra le lleva a rechazar la conexión; una coincidencia en una lista blanca, a aceptarla. Otra opción es que los resultados alimenten una función de puntuación que los pondera junto con otras señales. Los filtros que actúan después de recibir el mensaje suelen tomar las IP que comprobar de los campos de cabecera Received o de las URI del cuerpo.

¿Rechazar o puntuar?

Esa decisión corresponde al receptor. Las propias preguntas frecuentes de SpamCop califican su lista de herramienta agresiva y recomiendan marcar o desviar el presunto spam, o usar la lista como un factor más de una puntuación, en lugar de rechazar el correo directamente. Presentan los ajustes de rechazo como información para los administradores que no pueden usar un enfoque más matizado.

Riesgos sobre los que se advierte a los receptores

• Se delega el criterio. Usar una DNSxL supone ceder parte de la gestión del servidor al operador de la lista. El RFC dice que hay que asegurarse de que las políticas de la lista sean coherentes con las propias.
• Listas abandonadas. Un operador que cierra una lista podría instalar un comodín que liste todas las direcciones. Las entradas de prueba descritas arriba son la forma en que un cliente lo detecta.
• Caché. Los servidores pueden guardar en caché los resultados, pero deben respetar los TTL y descartar los registros caducados.
• Resolvedores públicos. Las preguntas frecuentes de Spamhaus dicen que las consultas a través de Google Public DNS devolverán en la mayoría de los casos «no listado», de modo que se pasan por alto inclusiones reales. Los códigos 127.255.255.x son errores, como 127.255.255.254 para una consulta a través de un resolvedor público bloqueado, y no deben interpretarse como «listado». Spamhaus señala que algunos servidores rechazan por error todo el correo por este motivo y recomienda usar un resolvedor propio.

Este es uno de los motivos por los que dos herramientas de comprobación pueden no coincidir sobre la misma dirección: pueden estar consultando a través de resolvedores distintos.

Listas negras y listas blancas (DNSBL frente a DNSWL)

Una DNSBL y una DNSWL se consultan de la misma forma, pero una coincidencia significa lo contrario. Según el RFC 5782, los administradores de red suelen usar las DNSBL para bloquear tráfico y las DNSWL para aceptar tráfico de forma preferente. Una misma lista puede incluso servir como lista negra en un contexto y como lista blanca en otro.

dnswl.org (list.dnswl.org) es un ejemplo de lista blanca. Su documentación dice que las respuestas tienen la forma 127.0.x.y, donde x es una categoría e y un nivel de confianza de 0 (ninguna) a 3 (alta). Sugiere que los hosts listados se salten el greylisting y las comprobaciones de listas negras, que los de confianza media y alta se salten el filtrado de spam y que nunca se omita el análisis antivirus. Hasta qué punto exime una entrada en una lista blanca sigue siendo decisión del receptor.

Motivos habituales por los que se lista una IP o un dominio

Cada operador fija sus propios criterios, y muchos no hacen públicos los desencadenantes exactos. Los motivos siguientes proceden de la documentación publicada por los operadores.

• Denuncias de spam y trampas de spam. La SpamCop Blocking List contiene IP que enviaron correo denunciado por usuarios de SpamCop, con un peso adicional para el correo enviado a trampas de spam (direcciones recopiladas o creadas por spammers). Sus preguntas frecuentes dicen que, sin nuevas denuncias, una inclusión dura solo 24 horas, y que las direcciones se retiran automáticamente cuando cesan las denuncias.
• Dispositivos infectados o comprometidos. La Spamhaus XBL lista IP automáticamente ante indicios como malware, aplicaciones de «VPN gratuita» que hacen pasar tráfico de terceros por el dispositivo, la participación en ataques de fuerza bruta o los intentos de retransmitir correo con credenciales robadas. Si la causa persiste, la IP vuelve a listarse la próxima vez que se conecta.
• Errores de configuración y mala higiene de las listas. La Spamhaus CSS menciona nombres HELO que no coinciden con el DNS directo, sitios web e instalaciones de CMS comprometidos, configuraciones inseguras y listas de correo mal mantenidas. Indica que hay que identificar y corregir la causa antes de la eliminación.
• Inclusiones por política. La Spamhaus PBL abarca espacio de direcciones, a menudo de banda ancha residencial, que no debería enviar correo directamente. Spamhaus dice que una inclusión en la PBL no se debe a nada que haya hecho el usuario final; se espera que el correo de esos rangos salga a través de un servidor SMTP autenticado.
• Infraestructura compartida. En un hosting compartido, los envíos de otro cliente pueden afectar a la IP que se usa. Consulte qué hacer cuando la IP de un hosting compartido está en una lista negra.

Qué papel tienen las DNSBL cuando el correo no se entrega

Una inclusión en una DNSBL es una de las posibles causas de que el correo no se entregue, no la única. Las direcciones erróneas, los buzones llenos, los problemas del lado del destinatario y la falta de autenticación también pueden provocar rebotes. Cuando hay una lista implicada, el mensaje de rebote suele nombrarla o incluir una URL de consulta.

1. Leer el rebote. Anote el código de respuesta y cualquier nombre de lista o URL que aparezca en el texto.
2. Identificar la IP y el dominio de envío. Use las líneas Received de las cabeceras o pregunte a quien administra el servidor.
3. Comprobar las listas principales a la vez. Use el comprobador de listas negras y luego confirme cualquier coincidencia en la página de consulta del propio operador.
4. Corregir la causa. Revise las causas descritas arriba. Las solicitudes hechas antes de corregir la causa suelen acabar en una nueva inclusión.
5. Seguir el proceso de ese operador. Algunas listas caducan solas, otras admiten una solicitud de eliminación y otras solo aceptan solicitudes del propietario de la red. La decisión de retirar la inclusión corresponde siempre al operador de la lista, y una solicitud no es una promesa de eliminación.

Los receptores aplican además su propio filtrado, así que puede que el correo no vuelva a fluir en el mismo momento en que termina una inclusión. Para la secuencia completa de diagnóstico, consulte correo en lista negra: cómo leer el rebote y, para la autenticación, configuración de SPF, DKIM y DMARC. Si no logra identificar la causa, puede pedirnos ayuda.

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: Domain Blocklist (DBL)
• Spamhaus: Exploits Blocklist (XBL)
• Spamhaus: Combined Spam Sources (CSS)
• Spamhaus: Policy Blocklist (PBL)
• SpamCop FAQ: What is the SpamCop Blocking List (SCBL)?
• SpamCop FAQ: How do I configure my mailserver to reject mail based on the blocklist?
• dnswl.org: Return codes and recommended usage

Guías relacionadas

Todas las guías →