{"id":1787,"date":"2026-10-02T05:51:16","date_gmt":"2026-10-02T05:51:16","guid":{"rendered":"https:\/\/ip4.market\/blog\/?p=1787"},"modified":"2026-10-02T05:51:16","modified_gmt":"2026-10-02T05:51:16","slug":"como-limpiar-la-reputacion-de-un-bloque-ipv4-adquirido","status":"publish","type":"post","link":"https:\/\/ip4.market\/blog\/es\/como-limpiar-la-reputacion-de-un-bloque-ipv4-adquirido\/","title":{"rendered":"C\u00f3mo limpiar la reputaci\u00f3n de un bloque IPv4 adquirido"},"content":{"rendered":"

Limpiar reputaci\u00f3n IPv4<\/strong> es, probablemente, lo primero con lo que chocas cuando compras un bloque de direcciones en el mercado de segunda mano. Y no es un detalle menor: una parte considerable de los prefijos \/24 que se venden hoy arrastran historiales negativos de sus anteriores due\u00f1os. Spam, escaneo de puertos, actividad de botnets o, simplemente, a\u00f1os funcionando bajo CGNAT de alg\u00fan ISP peque\u00f1o. En IP4 Market vemos este escenario todos los d\u00edas. La buena noticia es que, con m\u00e9todo, la mayor\u00eda de bloques se recuperan en plazos de entre dos semanas y tres meses. En esta primera parte explico por qu\u00e9 la reputaci\u00f3n pesa tanto, c\u00f3mo auditar el historial del prefijo antes de desplegarlo y qu\u00e9 implica el delisting en las principales DNSBL, Spamhaus incluida.<\/p>\n

Por qu\u00e9 la reputaci\u00f3n de un bloque IPv4 importa m\u00e1s de lo que crees<\/h2>\n

La reputaci\u00f3n de un prefijo no es una abstracci\u00f3n. Tiene consecuencias muy concretas en el d\u00eda a d\u00eda. Un bloque con historial contaminado provoca entregas de correo en carpeta de SPAM o rechazos directos (bounces 550), bloqueos CAPTCHA para usuarios que navegan desde esas IP, rechazos de registro en servicios como Microsoft 365 o Google, y problemas de peering con operadores que filtran por reputaci\u00f3n \u2014bastantes proveedores de tr\u00e1nsito tier 1 lo hacen\u2014.<\/p>\n

El caso m\u00e1s habitual en Espa\u00f1a y Latinoam\u00e9rica es casi siempre el mismo: una operadora regional compra un \/24 para montar CGNAT o servicios de hosting, y semanas despu\u00e9s descubre que sus clientes no pueden enviar correo porque el bloque lleva a\u00f1os en tres o cuatro listas negras. El coste no es solo t\u00e9cnico (soportes saturados, churn de clientes). Tambi\u00e9n es comercial: las campa\u00f1as de email marketing de tus clientes dejan de funcionar y el prefijo pierde valor como activo.<\/p>\n

Hay algo m\u00e1s. La reputaci\u00f3n es acumulativa y persistente. Cisco Talos, Barracuda o Google Postmaster Tools conservan hist\u00f3ricos de a\u00f1os. Por eso la limpieza debe empezar antes de poner tr\u00e1fico en producci\u00f3n. No despu\u00e9s.<\/p>\n

Auditor\u00eda previa: c\u00f3mo comprobar el historial del prefijo antes de usarlo<\/h2>\n

Antes de cerrar cualquier compra \u2014o, en el peor de los casos, antes de anunciar el prefijo v\u00eda BGP\u2014 conviene auditar el bloque de forma sistem\u00e1tica. Este es el proceso que recomendamos:<\/p>\n

    \n
  1. Consulta en agregadores de reputaci\u00f3n:<\/strong> revisa Cisco Talos Intelligence, MXToolbox (consulta decenas de DNSBL de golpe) y Spamhaus Lookup. Anota en qu\u00e9 listas aparece y desde cu\u00e1ndo.<\/li>\n
  2. Analiza el hist\u00f3rico BGP:<\/strong> herramientas como BGPlay de RIPE NCC o Hurricane Electric BGP Toolkit permiten ver qu\u00e9 AS ha anunciado el prefijo, cu\u00e1ndo y desde d\u00f3nde. Un bloque que salt\u00f3 entre cinco AS en dos a\u00f1os es se\u00f1al de alerta, sin m\u00e1s.<\/li>\n
  3. Revisa el registro WHOIS\/RDAP en el RIR correspondiente:<\/strong> comprueba que no haya reclamaciones activas, que el recurso est\u00e9 limpio en RIPE Database y que el LOA y la transferencia se hayan ejecutado correctamente.<\/li>\n
  4. Comprueba ROT (Reputation of Traffic) y certificados hist\u00f3ricos:<\/strong> buscadores como Shodan o Censys muestran qu\u00e9 servicios estuvieron expuestos en esas IP. Un bloque que alberg\u00f3 proxies abiertos o paneles de phishing necesitar\u00e1 limpieza adicional.<\/li>\n<\/ol>\n

    En IP4 Market facilitamos este paso: nuestra plataforma trabaja con vendedores verificados y publica informaci\u00f3n de contexto de los bloques, lo que reduce mucho el riesgo de adquirir un prefijo con historial problem\u00e1tico.<\/p>\n

    Limpieza de listas negras: DNSBL, Spamhaus y delisting paso a paso<\/h2>\n

    Identificadas las listas donde figura el bloque, el delisting sigue un patr\u00f3n parecido en casi todas las DNSBL. Aunque con particularidades que importan:<\/p>\n

    Spamhaus (SBL, XBL, PBL, DROP)<\/h3>\n

    Spamhaus es la m\u00e1s cr\u00edtica y tambi\u00e9n la m\u00e1s estricta. Si tu bloque aparece en el SBL (Spamhaus Block List), normalmente hay una raz\u00f3n documentada: spam activo, un proveedor anterior con mala gesti\u00f3n o incluso presencia en el DROP por ser espacio secuestrado. El proceso:<\/p>\n

      \n
    • Accede al lookup de Spamhaus e identifica el motivo concreto de la inclusi\u00f3n.<\/li>\n
    • Corrige la causa ra\u00edz. Nadie te delista un bloque que sigue emitiendo spam. Revisa si hay servidores comprometidos, formularios abusados o relays abiertos en el rango.<\/li>\n
    • Solicita la eliminaci\u00f3n desde el propio sistema de Spamhaus (requiere registro gratuito) aportando evidencia de que ya eres el titular leg\u00edtimo del recurso: contrato de compra, actualizaci\u00f3n del registro RIPE y documento de transferencia.<\/li>\n
    • Arma te de paciencia. Los primeros delistings tras un cambio de titularidad tardan d\u00edas y es frecuente tener que insistir. Spamhaus valora la trayectoria: evitar nuevas incidencias durante las primeras semanas es clave.<\/li>\n<\/ul>\n

      Otras DNSBL habituales<\/h3>\n

      Barracuda, SpamCop, CBL\/Abuseat, SORBS y PSBL suelen tener procesos m\u00e1s simples: formulario de delisting con la IP, una justificaci\u00f3n breve y, a veces, verificaci\u00f3n autom\u00e1tica de que el bloque ha dejado de emitir tr\u00e1fico sospechoso. SpamCop expira sola si no hay nuevas denuncias (en d\u00edas, normalmente). SORBS puede ponerse terca y, en casos extremos, toca escalar por su sistema de tickets.<\/p>\n

      \n

      Consejo pr\u00e1ctico:<\/strong> configura monitoreo continuo con alertas (por ejemplo, comprobaciones diarias contra las principales DNSBL desde tu propia monitorizaci\u00f3n o con herramientas como MXToolbox Monitoring). Una reinclusi\u00f3n detectada en 24 horas se resuelve mucho m\u00e1s r\u00e1pido que una detectada tres semanas despu\u00e9s, cuando ya te est\u00e1n llegando quejas de clientes.<\/p>\n<\/div>\n

      Con las listas principales limpias y el prefijo registrado correctamente a tu nombre en el RIR, ya tienes la base. En la segunda parte del art\u00edculo cubriremos la configuraci\u00f3n t\u00e9cnica que sostiene esa reputaci\u00f3n a largo plazo: rDNS, RPKI\/ROA, autenticaci\u00f3n de correo (SPF, DKIM, DMARC) y buenas pr\u00e1cticas de gesti\u00f3n del rango.<\/p>\n

      Configuraci\u00f3n t\u00e9cnica para reconstruir la confianza: rDNS, SPF, RPKI y ROA<\/h2>\n

      Digamos que ya diste el primer paso: el prefijo est\u00e1 registrado a tu nombre en el RIR correspondiente y las listas negras m\u00e1s cr\u00edticas ya no te se\u00f1alan. Ahora toca lo menos vistoso pero lo que de verdad sostiene la reputaci\u00f3n a largo plazo. Empecemos por el rDNS (registro PTR inverso)<\/strong>. La regla es simple: cada direcci\u00f3n IP que env\u00eda correo o aloja servicios debe resolver a un nombre de host v\u00e1lido, y ese nombre debe resolver de vuelta a la misma IP. Resoluci\u00f3n directa e inversa coherente, sin excepciones. Un ejemplo: si env\u00edas correo desde 185.45.67.10, el PTR debe apuntar a algo como mail.tudominio.es<\/em> y ese registro A debe devolver exactamente 185.45.67.10. Gmail, Outlook y los grandes receptores penalizan directamente los rangos sin PTR coherente. No negocian esto.<\/p>\n

      El segundo pilar es la autenticaci\u00f3n de correo, y aqu\u00ed conviene no improvisar. Publica un registro SPF<\/strong> que declare \u00fanicamente los servidores autorizados a enviar en nombre de tu dominio (solo los necesarios, nada de “vamos a incluirlo todo por si acaso”), firma todos los mensajes con DKIM<\/strong> usando claves RSA de 2048 bits como m\u00ednimo, y remata con una pol\u00edtica DMARC<\/strong> que arranque en p=none<\/em> con los reportes activados. \u00bfPor qu\u00e9 empezar tan blandos? Porque as\u00ed pasas gradualmente a p=quarantine<\/em> o p=reject<\/em> cuando verifiques que no hay env\u00edos leg\u00edtimos fallando. Este escalonado evita bloqueos autogenerados durante la migraci\u00f3n. Los hay, y duelen.<\/p>\n

      En el plano de enrutado, crea un ROA<\/strong> (Route Origin Authorization) en el RIR y firma tu anuncio BGP bajo RPKI<\/strong> con la m\u00e1xima longitud de prefijo ajustada a tu rango real. Un \/24 anunciado con un ROA que solo permita longitud 24 impide secuestros de origen, y cada vez m\u00e1s operadores serios lo exigen como requisito para dar tr\u00e1nsito. Un detalle que se olvida a menudo: si trabajas con un proveedor mediante LOA, el ROA debe autorizar el ASN de ese proveedor, no el tuyo. Parece obvio. Hasta que alguien lo hace mal y se queda sin anuncio.<\/p>\n

      C\u00f3mo limpiar reputaci\u00f3n IPv4 de forma sostenible y evitar futuras inclusiones<\/h2>\n

      Limpiar una vez no sirve de nada si el rango vuelve a ensuciarse en semanas. Lo he visto pasar m\u00e1s de una vez: esfuerzo de semanas tirado a la basura por descuidar el d\u00eda a d\u00eda. Estas pr\u00e1cticas mantienen el prefijo sano:<\/p>\n