¿Cómo encontrar la dirección abuse@ de un alojador?

Actualizado el 26 de septiembre de 2026

Una vez identificado el servidor correcto, aún hay que saber a quién escribir para conseguir que lo corten. La buena noticia: casi siempre existe una dirección, prevista exactamente para eso. La menos buena: no siempre es fácil de encontrar a la primera. Aquí va el método, paso a paso.

Por qué existen las direcciones abuse@

En 1997, la RFC 2142 fijó una convención que sigue usando hoy casi la totalidad de los alojadores y operadores de red: toda organización que gestione máquinas conectadas a Internet debe exponer un buzón abuse@ para recibir notificaciones de uso abusivo (spam, intrusiones, phishing…), además de otros buzones estándar como postmaster@ o webmaster@. No es una simple costumbre: es una norma, lo que explica por qué funciona de forma tan generalizada, desde los pequeños alojadores hasta los mayores operadores mundiales.

Identificar al operador: de la IP al ASN

Todo parte de una dirección IP: la del servidor que aloja la página de phishing, o la que se encuentra en la línea Received de un correo (véase cómo encontrarla en la cabecera). A partir de ahí, el método sigue siempre el mismo camino:

WHOIS o RDAP de la IP: un simple comando whois 203.0.113.45, o un sitio RDAP en línea, indica qué organización declaró ese bloque de direcciones. La respuesta contiene muy a menudo directamente un campo abuse-mailbox u OrgAbuseEmail: es la respuesta más rápida, cuando está presente.
El ASN, si el WHOIS de la IP no basta: cada bloque de direcciones IP está vinculado a un ASN (Autonomous System Number), una especie de número de identidad del operador de red que lo explota. Herramientas como bgp.he.net permiten encontrar el ASN a partir de la IP, y luego la organización asociada.
Verificación del contacto: una vez identificada la organización, se busca «nombre de la organización + abuse» o se consulta su página de soporte: la mayoría de los grandes alojadores documentan su procedimiento de notificación.

Esquema en cuatro etapas: una dirección IP sospechosa, encontrada en la cabecera o la URL del sitio de phishing; una consulta WHOIS o RDAP de la IP, que indica quién declaró ese bloque, con el campo abuse-mailbox a menudo ya presente en la respuesta; si no basta, el operador de red identificado por su ASN señala a la empresa que explota ese bloque de IP; por último la dirección abuse@, el buzón previsto desde 1997 por la RFC 2142 para estas notificaciones concretas, ejemplo abuse@alojador.example. Leyenda: se sube hasta encontrar un verdadero responsable; una IP no basta, hace falta la organización que la explota y puede actuar sobre ella. — Figura 1: de la dirección IP a la dirección abuse@, la cadena a remontar cuando la respuesta no es inmediata.

Comprobar que el contacto es el correcto

Adivinar una dirección abuse@ solo a partir del nombre de dominio del sitio de phishing es un error frecuente: abuse@secure-login.example probablemente no existe, ya que ese dominio pertenece al propio estafador, no al alojador. La dirección abuse@ correcta es la de la organización que posee el servidor (encontrada a través de la IP, no del nombre de dominio del sitio trampa). Para un dominio que hay que suspender en lugar de un servidor que hay que cortar, hay que buscar una dirección distinta, la del registrador (véase quién controla qué entre registrador, alojador y CDN).

Casos en los que la dirección abuse@ no es evidente

El WHOIS no siempre responde con claridad. Se repiten tres situaciones:

Los grandes alojadores en la nube (AWS, OVH, Azure, Google Cloud…) sustituyen con frecuencia la dirección de correo por un formulario web dedicado, a veces incluso exigido para que la notificación se tramite con rapidez.
El registrador del dominio a veces expone, vía RDAP, un enlace directo «report abuse» en lugar de una dirección de correo clásica.
El silencio, o una negativa: algunos operadores, especialmente en el extranjero, responden con lentitud o no responden en absoluto. En ese caso, el CERT nacional o la plataforma oficial del país siguen siendo un recurso: en España, por ejemplo, el Instituto Nacional de Ciberseguridad (INCIBE).

Esquema de tres ramas que parten de una pregunta: ¿ninguna dirección abuse@ visible o que responda? Primera rama, un gran alojador en la nube como AWS, OVH o Azure, donde un formulario web sustituye al correo. Segunda rama, el registrador del dominio, donde el RDAP da un enlace report abuse directo a su formulario. Tercera rama, silencio total o una negativa, donde el CERT nacional o la plataforma oficial del país, por ejemplo INCIBE, sigue siendo un recurso. Leyenda: un contacto de recurso, nunca cero; casi siempre existe una puerta de entrada, formulario, ticket o plataforma nacional. Se documenta cada intento, fecha, canal utilizado, referencia del ticket, útil para insistir o escalar más adelante. — Figura 2: cuando la dirección abuse@ clásica no es evidente, casi siempre queda otra puerta de entrada.

Se guarda constancia de cada intento: fecha, canal utilizado (correo, formulario, ticket), y número de referencia si lo hay. Eso es lo que permite insistir con utilidad, o pasar al siguiente nivel sin partir de cero.

Preparar la notificación

Una vez encontrada la dirección correcta, la notificación en sí debe seguir siendo fácil de tramitar para quien la recibe:

el elemento concreto afectado: la dirección IP para un alojador, el nombre de dominio para un registrador;
la URL exacta de la página de phishing, o la cabecera completa si la notificación parte de un correo;
la fecha y hora de detección, con el huso horario;
enlaces neutralizados, del tipo hxxps://secure-login[.]example, para que no se produzca ningún clic accidental al leer.

Lo esencial que hay que recordar

Desde 1997 (RFC 2142), el buzón abuse@ es la norma esperada en todo operador de red.
El camino clásico es IP → WHOIS/RDAP → (ASN si hace falta) → dirección abuse@.
El contacto válido es el de la organización que posee el servidor (vía la IP), no el adivinado a partir del nombre de dominio del sitio trampa.
Los grandes alojadores en la nube usan a menudo un formulario web en lugar de una dirección de correo.
Sin respuesta, el CERT nacional o una plataforma oficial siguen siendo un recurso.

Esto es precisamente lo que automatiza Baitback: a partir de un correo o un enlace, la herramienta localiza el servidor implicado, su operador, y su dirección exacta de notificación, y luego prepara el mensaje listo para enviar.

Para ir más lejos: registrador, alojador, CDN: quién puede actuar realmente, o la anatomía completa de un informe eficaz.