Inicio › Guías

IP de hosting compartido en lista negra: qué puede corregir y qué no

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

Cuando la IP de un hosting compartido aparece en una lista negra, lo primero es averiguar quién controla esa IP y en qué lista exacta está, con qué código de retorno. Después hay que limpiar todo lo que dependa de uno mismo y enviar al proveedor de hosting las pruebas de la consulta para que pueda actuar. En una IP compartida, la causa puede ser otro cliente, y en algunas listas solo el propietario de la red puede solicitar la eliminación.

Una IP de VPS o de nube recién asignada también puede aparecer «en lista negra» desde el primer día, ya sea por el historial de un usuario anterior o porque el rango está listado como uno que no debería enviar correo directamente. Sea cual sea la situación, la decisión de retirar la inclusión corresponde siempre al operador de la lista.

Esta guía se basa en las páginas oficiales de Spamhaus, AWS, Google Cloud y Microsoft Azure vigentes en noviembre de 2026. Las restricciones y los procedimientos cambian, así que conviene confirmar la redacción actual antes de actuar. Para una visión general de los rebotes relacionados con listas negras, consulte nuestra guía sobre correos bloqueados por listas negras.

Primero: qué IP y qué lista

«Mi servidor está en una lista negra» puede significar cosas muy distintas, y la solución depende de los detalles. Antes de hacer nada, conviene responder a tres preguntas.

1. ¿Qué IP envía realmente el correo? La IP que aloja el sitio web no es necesariamente la que entrega el correo. Lea el mensaje de rebote, que a menudo cita la IP rechazada, y revise las cabeceras Received de un mensaje enviado para confirmar la dirección de salida real.
2. ¿Quién controla esa IP? En un hosting compartido es una dirección compartida con otros clientes. En un servidor dedicado, un VPS o una instancia en la nube está asignada a usted, aunque el rango que la rodea sigue perteneciendo al proveedor. El plan de hosting o el panel de control indicará si el correo saliente usa una dirección compartida.
3. ¿En qué lista está? Las listas difieren en su significado y en quién puede resolverlas. Pase la IP por nuestro comprobador de listas negras para ver todas las listas principales a la vez, y anote los nombres de las listas y los códigos de retorno.

Con esas tres respuestas suele quedar claro si se trata de algo que se puede corregir por cuenta propia, algo que tiene que corregir el proveedor o una señal de que conviene cambiar por completo la forma de enviar el correo.

Cómo leer los resultados y los códigos de retorno

Spamhaus ZEN (zen.spamhaus.org) es la lista combinada de IP de Spamhaus. Una IP listada devuelve una dirección del rango 127.0.0.x, y el último número indica qué lista subyacente coincidió. Para las IP de hosting compartido y de nube, estos son los códigos que conviene distinguir:

Una entrada en la PBL no es una acusación. Es una declaración de política: el correo de esta dirección debería enviarse, con autenticación, a un servidor que lo retransmita. Spamhaus anima activamente a los ISP y a otras redes a listar todos los rangos que no deberían enviar correo, y eso incluye expresamente los servidores web.

Los códigos 127.255.255.252, 127.255.255.254 y 127.255.255.255 son errores, no inclusiones. Las preguntas frecuentes de Spamhaus sobre el uso de DNSBL advierten además que un resolvedor público gratuito como Google Public DNS (8.8.8.8) devolverá en la mayoría de los casos «no listado», y por eso distintas herramientas pueden no coincidir. En caso de duda, compruebe el resultado en el comprobador de reputación de Spamhaus. Para los procedimientos completos de cada lista, consulte cómo funciona la eliminación en Spamhaus.

Qué se puede corregir por cuenta propia y qué no

Lo que se puede cambiar depende de lo que se haya contratado.

Descartar la propia cuenta en un hosting compartido

• Buzones comprometidos. Revise los registros de envío y las carpetas de enviados en busca de ráfagas de correo que no se hayan enviado a propósito. Si las encuentra, cambie las contraseñas de inmediato.
• Un sitio web hackeado. Las instalaciones de CMS y los plugins desactualizados son una vía habitual para que los atacantes suban scripts de envío de correo.
• Formularios abusados. Los formularios de contacto cuya respuesta automática permite al visitante elegir el destinatario o el texto pueden convertirse en un cañón de spam.
• Calidad de las listas. Enviar a listas compradas o a direcciones que nunca dieron su consentimiento es una forma segura de dañar una IP compartida para todos, incluido uno mismo.

Si nada de esto da resultado, la causa probable es otra persona en la misma dirección. Las preguntas frecuentes de Spamhaus sobre el puerto 25 lo dicen sin rodeos: en los grupos de IP compartidas, la mayoría de los afectados por una inclusión no son quienes tienen el dispositivo infectado. En ese caso, lo que corresponde es reunir las pruebas y entregárselas al proveedor.

Cómo comunicarlo al proveedor de hosting

Spamhaus indica que las solicitudes de eliminación de la SBL debe enviarlas el ISP responsable de la IP listada, y aconseja a los usuarios en general que hablen con su ISP para resolverlo. Para un cliente de hosting compartido, ese ISP es la empresa de hosting. Un ticket de soporte que solo dice «mi correo no llega» suele ir de un lado a otro. Un ticket que incluye lo siguiente suele avanzar más rápido:

1. La IP de envío, confirmada en las cabeceras o en el rebote.
2. La lista y el código de retorno, por ejemplo zen.spamhaus.org devolviendo 127.0.0.2.
3. Cuándo y con qué se comprobó, incluido lo que mostró el comprobador de reputación oficial si se usó.
4. El texto del rebote, en concreto la línea en la que el servidor receptor explica el rechazo.
5. Lo que ya se ha descartado, como el cambio de contraseñas y un análisis limpio del sitio.
6. Lo que se solicita: una investigación, una solicitud de eliminación al operador de la lista si procede o el traslado del correo saliente de la cuenta a otra IP.

Un ejemplo breve:

Our outbound IP 192.0.2.10 returns 127.0.0.2 (SBL) on zen.spamhaus.org.
We confirmed this on the official Spamhaus checker at 10:00 UTC on 2026-11-03.
We have reset all mailbox passwords and found no unexpected files on our site.
Please investigate, request removal if appropriate, or advise whether our mail
can be sent from a different IP.

El proveedor puede necesitar tiempo, e incluso cuando actúa, la decisión final es del operador de la lista. Si hay correo que no puede esperar, conviene considerar la opción del relay que se describe más abajo como solución paralela. Si no logra averiguar dónde está el problema, también puede pedirnos ayuda.

Restricciones del puerto 25 y DNS inverso en VPS y nube

Si se gestiona un servidor de correo propio en un VPS o en una instancia en la nube, puede surgir un problema antes de que entre en juego cualquier lista negra: muchos proveedores restringen el puerto TCP 25 saliente, el que se usa para la entrega de correo entre servidores. La documentación oficial de AWS, Google Cloud y Microsoft Azure dice lo siguiente.

• Amazon EC2 (AWS). De forma predeterminada, EC2 solo permite el tráfico saliente por el puerto 25 hacia direcciones IPv4 privadas; el tráfico hacia direcciones IPv4 e IPv6 públicas está bloqueado. Se puede solicitar que se elimine la restricción. Para el correo a terceros, AWS recomienda aprovisionar direcciones IP elásticas (Elastic IP) y asignarles registros de DNS inverso estáticos, y señala que esto puede ayudar a evitar que el correo se marque como spam. Antes de crear el registro inverso debe existir un registro DNS directo (A) que resuelva a la IP elástica.
• Google Cloud (Compute Engine). El tráfico de salida al puerto TCP 25 de direcciones IP externas está bloqueado de forma predeterminada. El bloqueo se elimina automáticamente cuando Google Cloud determina que un proyecto es de bajo riesgo, y el estado de un proyecto puede verse en un banner de las páginas de redes de VPC o de políticas de firewall de la consola. SMTP sobre TLS en los puertos 465 y 587 queda fuera del bloqueo. Google recomienda usar un proveedor de correo externo de confianza, lo que, según indica, mejora la reputación de la IP.
• Microsoft Azure (máquinas virtuales). El puerto 25 saliente está bloqueado en todos los tipos de suscripción salvo el Enterprise Agreement estándar y el Microsoft Customer Agreement para empresas (MCA-E). Las suscripciones Enterprise Dev/Test están bloqueadas de forma predeterminada, pero pueden quedar exentas mediante el diagnóstico del portal. Los servicios de relay SMTP autenticado, normalmente en el puerto 587, no tienen restricciones en ningún tipo de suscripción, y Microsoft los recomienda. Incluso con el puerto 25 abierto, Microsoft señala que no hay garantía de que los dominios externos acepten el correo.

Un puerto 25 bloqueado es un problema de entrega, no de reputación, y abrir el puerto no mejora en nada la reputación de la IP. Si se quiere una exclusión de la PBL de Spamhaus para una dirección de nube o VPS, la IP debe ser estática, ejecutar realmente un servidor de correo saliente, tener un DNS directo e inverso correctos y estar asignada a usted. Spamhaus exige además que el puerto 25 saliente esté cerrado para todos los demás dispositivos que haya detrás.

Pasar a una IP dedicada o a un relay SMTP autenticado

Si una IP compartida se ve perjudicada una y otra vez por sus vecinos, o el proveedor de nube no abre el puerto 25, cambiar la forma de enviar suele ser más práctico que perseguir exclusiones.

Un relay SMTP externo y autenticado

En lugar de que el servidor entregue el correo directamente al destinatario, entrega cada mensaje a un servidor de envío autenticado que lo entrega en su nombre. Es exactamente el modelo que describe Spamhaus para los rangos listados en la PBL: se espera que el correo se envíe con autenticación a un relay, que puede gestionar el ISP de conexión o un servicio de correo externo. Las preguntas frecuentes de Spamhaus sobre el puerto 25 añaden que los usuarios finales deberían usar los puertos 587 o 465 con SMTP AUTH. Azure y Google Cloud recomiendan relays autenticados o servicios de correo de terceros, y Microsoft señala que estos servicios se usan en parte para mantener la reputación de IP de la que depende la entrega.

• Configure el nombre de host, el puerto (lo habitual es 587) y las credenciales del relay tal como indica su proveedor.
• Actualice el registro SPF del dominio para incluir el relay y configure la firma DKIM para él. Consulte cómo configurar SPF, DKIM y DMARC.
• Revise los límites de envío del relay antes de trasladar a él correo de gran volumen.

Una IP dedicada

Una IP dedicada aísla del comportamiento de otros clientes, pero no mejora automáticamente la reputación. Las directrices para remitentes de Spamhaus enumeran los factores que influyen en la reputación, entre ellos el proveedor de servicios, el vecindario de la IP, la infraestructura que hay detrás de la dirección y el historial de la IP.

• Las direcciones nuevas reciben un escrutinio adicional. Las mismas directrices dicen que los dominios HELO sin historial de envío se someten a un filtrado adicional, y que una IP o un nombre de host HELO que cambia debe tratarse como nuevo y calentarse de forma gradual. Están prohibidos los servicios de calentamiento que generan tráfico artificial.
• Configurar un DNS inverso con sentido. Spamhaus advierte que un DNS inverso genérico o autogenerado en una IP dedicada puede perjudicar la reputación.
• Comprobar la nueva IP antes de usarla. Una dirección puede arrastrar una inclusión de su usuario anterior, así que conviene consultarla antes de empezar a enviar.

Cómo evitar que vuelva a ocurrir

• Alinear el nombre de host, el HELO y el DNS inverso. Las preguntas frecuentes de Spamhaus sobre la CSS dicen que el DNS directo de la IP debe coincidir con el valor HELO configurado en el servidor y que el HELO debe ser un nombre de dominio completo (FQDN). Mencionan valores como localhost.localdomain como errores habituales.
• Limitar el puerto 25 a los servidores de correo. En un VPS que también ejecuta otras cargas de trabajo, cierre el puerto 25 saliente para todo lo que no sea el servidor de correo.
• Mantener protegidos los sitios y las cuentas. Actualice el CMS y los plugins, no reutilice contraseñas y active la autenticación de dos factores cuando sea posible.
• Revisar la configuración de correo saliente del panel de control. Las preguntas frecuentes sobre la CSS describen una opción de Plesk que pone el nombre de cada dominio en el saludo SMTP. Advierten que, cuando varios dominios del servidor comparten una IP, el correo de algunos o todos esos dominios puede ser marcado como spam por los receptores que usan la Spamhaus XBL, y que la opción debe usarse con extremo cuidado. Compruebe el ajuste equivalente en su propio panel y siga las indicaciones del proveedor o del fabricante del panel.
• Vigilar con regularidad. Una IP compartida puede cambiar de estado por acciones de otros. Compruébela periódicamente con nuestro comprobador de listas negras y avise pronto al proveedor cuando algo cambie.

Incluso después de una exclusión, los receptores aplican su propio filtrado, así que puede que la entrega no se recupere de inmediato. Las inclusiones en la CSS suelen caducar unos tres días después de la última detección, pero la IP vuelve a listarse si el problema se sigue detectando, y las autoeliminaciones son limitadas.

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.

• Spamhaus: Policy Blocklist (PBL)
• Spamhaus: Spamhaus Blocklist (SBL)
• Spamhaus FAQ: DNSBL Usage (return codes and public resolvers)
• Spamhaus FAQ: Combined Spam Sources (CSS)
• Spamhaus FAQ: Port 25 General Questions
• Spamhaus: Sender Guidelines
• AWS: Amazon EC2 service quotas (Restriction on email sent using port 25)
• AWS: Create a reverse DNS record for email on Amazon EC2
• Google Cloud: Sending email from an instance
• Google Cloud: VPC firewall rules (Blocked and limited traffic)
• Microsoft Learn: Troubleshoot outbound SMTP connectivity in Azure

Guías relacionadas

Todas las guías →