Otro dominio detrás de un enlace: ¿señal de alarma o algo inofensivo?

Si pasas el ratón por encima de suficientes enlaces de tu bandeja de entrada, lo notarás enseguida: la dirección que hay detrás de un enlace casi nunca coincide exactamente con su texto. El correo de tu banco dice www.harbourline.example y el enlace lleva a login.harbourline.example. Un boletín menciona una tienda y enlaza a un servicio de envíos masivos. Un aviso de paquetería nombra a una empresa de mensajería y enlaza a algo totalmente distinto. Algunas de estas diferencias son el pan de cada día; una de ellas es precisamente la forma en que funciona el phishing. La clave está en saber qué parte del nombre de host mirar.

Lee el nombre de host de derecha a izquierda

Primero localiza el tramo entre https:// y el primer /, ? o # (o el final de la dirección si no aparece ninguno). Ese tramo puede contener más que el nombre de host: lo que va antes de una @ no es el host, y tampoco lo es un número de puerto al final, como :8443. En https://[email protected]/ el host es account-review.example.

Un nombre de host se lee de derecha a izquierda. En mail.harbourline.example, .example es el dominio de nivel superior y harbourline.example es el dominio registrable: el nombre que una persona o empresa ha registrado y controla. Todo lo que queda a su izquierda (mail., www., login.) es un subdominio que el titular crea o deja en manos de otro. Así que mail.harbourline.example y www.harbourline.example comparten dominio registrable, lo que suele significar, aunque no siempre, que los controla la misma parte (las excepciones, más abajo). Algunos países usan sufijos de dos partes: en www.phpfreelance.co.uk el sufijo es .co.uk, de modo que el dominio registrable es phpfreelance.co.uk.

Ese lado izquierdo es también donde los atacantes se disfrazan. En harbourline.example.account-review.example el nombre conocido no es más que una etiqueta sobre el dominio de otro: el dominio registrable, a la derecha del todo, es account-review.example. Una campaña de 2025 contra Booking.com usó la misma idea con un carácter japonés que parece una barra, de modo que el dominio del atacante, www-account-booking[.]com, quedaba escondido tras un texto que parecía una ruta de booking.com. Desmonté ese ejemplo en el artículo sobre Reveal URLs.

Cuándo otro dominio es una señal de alarma

Una diferencia se convierte en señal de alarma cuando el enlace lleva a un dominio registrable distinto del que nombra su texto y el destino tiene pinta de imitación. Las formas habituales:

• Una ortografía parecida. harb0urline.example con un cero en lugar de la "o", una letra duplicada o cambiada de sitio, o la marca con una palabra tranquilizadora añadida: harbourline-secure.example, harbourline-support.example. Una ortografía distinta no demuestra que el titular sea otro, pero nada en el nombre indica que lo haya registrado el titular de harbourline.example, así que tómalo como un motivo para mirar con más atención.
• La marca como adorno. harbourline.example.account-review.example: la marca aparece, pero solo como etiqueta de subdominio sobre el dominio registrable de un desconocido.
• Letras de otro alfabeto. Los nombres de dominio internacionalizados pueden contener letras de otras escrituras, y algunas son idénticas a las latinas. El 3 de octubre de 2026, Have I Been Squatted mostró una imitación de apple.com cuyas cinco letras eran todas cirílicas y que Chrome 154 seguía mostrando en Unicode, con un certificado válido. El correo web tampoco se comportó igual: en su prueba con 20 dominios de remitente internacionalizados, "Gmail decoded everything, and Outlook Web decoded nothing": Gmail Web mostró los dominios de remitente en Unicode, Outlook Web en su forma xn--. Esa prueba trataba de cómo se muestra la dirección del remitente, no de los enlaces ni de los filtros de phishing de ninguno de los dos servicios. En la zona .com contaron 733.509 dominios internacionalizados y 161.894 pares de dominios parecidos, y advierten de que un nombre parecido no es necesariamente malicioso. Sus propios 20 dominios de prueba eran investigación, no una campaña activa.
• Una dirección visible que lleva a otra parte. El propio texto dice https://www.harbourline.example/account, pero el enlace va a un dominio que no tiene nada que ver. Los boletines lo hacen a veces para medir clics (lo verás más abajo). Un servicio de envíos o de seguimiento que reconozcas explica por qué el nombre de host es distinto, pero no hace que el enlace sea seguro, como muestran más abajo los casos de SendGrid y Trezor. Si no reconoces el destino, trátalo como una discrepancia.

Cuándo suele ser inofensivo

Muchas diferencias tienen una explicación de lo más corriente. Conocerlas evita que veas un ataque en cada boletín y te dice dónde, aun así, conviene ir con cuidado.

• Subdominios del mismo dominio registrable. Texto harbourline.example, destino mail.harbourline.example o login.harbourline.example: el mismo dominio registrable, lo que suele ser inofensivo. Pero no demuestra que la página la gestione la misma parte: un titular puede apuntar un subdominio a un servicio de otra empresa, y si ese registro DNS sigue ahí cuando el servicio se da de baja (un registro DNS "colgante", en inglés dangling), otra persona puede hacerse con el subdominio. Microsoft documenta esta toma de control de subdominios (subdomain takeover) y señala que se usa en campañas de phishing.
• Seguimiento de clics en boletines. Los servicios de envío suelen hacer pasar cada clic primero por su propia dirección de seguimiento, que luego te reenvía a la página real. Un enlace cuyo texto dice www.harbourline.example puede apuntar, por tanto, a algo como click.mailer.example/…. En los boletines es normal y, como ya señalé en el artículo sobre el phishing de enlaces, las URL de seguimiento parecen sospechosas incluso cuando son inofensivas. Pero también significa que el destino inmediato del enlace no es donde vas a acabar, y que una plataforma de envío de confianza también puede repartir phishing: en enero de 2026, según se informó, unos atacantes usaron cuentas de clientes de SendGrid comprometidas para enviarlo.
• Servicios de redirección y de reescritura de enlaces. Los buscadores, el seguimiento de clics publicitarios y algunos servicios de seguridad del correo para empresas (que reescriben los enlaces para que cada clic pase antes por su escáner) ponen todos su propio nombre de host delante del real.
• Acortadores de URL. Un enlace como short.example/a1B2 no es phishing en sí mismo, pero oculta el destino por completo, así que no hay nada con lo que comparar el texto. Trátalos con cuidado: si el mensaje trata de dinero, contraseñas o tu cuenta, no hagas clic; entra en la web por tu cuenta.

Cuando cada salto parece de confianza

Los casos más difíciles son los enlaces en los que no se ve nada raro. Tres ejemplos de 2026:

• Una cadena de direcciones de Google. El 4 de septiembre de 2026, el KnowBe4 Threat Lab describió una campaña que encadenaba enlaces de phishing a través de servicios de Google, como meet.google.com/linkredirect, google.com/url?q= y el seguimiento de clics de DoubleClick, de modo que la pasarela de correo veía "trusted Google domains at every hop" antes de que el enlace llegara a la infraestructura propia de los atacantes.
• Una página de inicio de sesión real que te reenvía. El 2 de marzo de 2026, Microsoft describió el abuso de las redirecciones de OAuth: enlaces que empiezan en login.microsoftonline.com o accounts.google.com, construidos para fallar a propósito, tras lo cual el servicio de inicio de sesión redirige el navegador a una dirección registrada por el atacante.
• Un remitente auténtico. El 9 de septiembre de 2026, un atacante que había logrado acceder a Brevo, la plataforma de boletines que usa Trezor, envió un correo de phishing desde la propia cuenta de Trezor. Su enlace invitaba a descargar una aplicación que pedía la copia de seguridad del monedero (publicación de Trezor del 10 de septiembre de 2026, actualizada el 17 de septiembre).

La lección: un primer nombre de host de confianza, o un remitente auténtico, no dice nada del destino final. Si una dirección de confianza lleva dentro una segunda dirección, por ejemplo después de url=, q=, dest= o redirect_uri=, esa segunda dirección puede indicar adónde te enviarán más tarde. No muestra dónde termina la cadena: el nombre del parámetro no demuestra nada sobre lo que hace el servicio con él, y la dirección incrustada puede ser solo otro paso intermedio, como en la cadena que describió KnowBe4. Para todo lo que te pida iniciar sesión o pagar, el enlace más seguro es el que escribes tú, o la aplicación oficial. La copia de seguridad del monedero es otra cosa: no la introduzcas nunca porque te la pida un mensaje. Trezor dice que nunca te pedirá la copia de seguridad del monedero; sigue las instrucciones de recuperación del propio fabricante de tu monedero.

Cómo decide Reveal URLs qué marcar

Reveal URLs es mi propia herramienta gratuita y de código abierto, así que lee esta sección como mi descripción de mi propio trabajo. Su regla es deliberadamente estrecha y previsible:

1. De los enlaces web que anota muestra la URL inmediata real: en Chrome, Edge, Firefox, Safari y Thunderbird, justo encima del enlace; en Gmail, como una tarjeta en la barra lateral; y en Outlook, en un panel de tareas.
2. Cuando el texto visible del enlace contiene una URL o un host, compara esa dirección con la URL inmediata real al nivel del dominio registrable.
3. Si pertenecen a sitios distintos, resalta el destino, en rojo por defecto (es un ajuste que puedes cambiar). Un subdominio corriente como mail.example.com frente a example.com se deja en paz; una imitación se marca.
4. Cuando el texto no contiene ninguna dirección, como un botón "Pagar ahora", el destino se sigue mostrando, solo que no en rojo: no hay ningún host en el texto con el que compararlo.

Estas son las reglas de comparación de nombres de host para los enlaces web corrientes. Los ajustes por sitio y los hosts excluidos pueden desactivar la anotación, y las versiones para navegadores y Thunderbird aplican reglas aparte a algunos enlaces que no son web: un enlace javascript: o data: se marca siempre.

La tabla de abajo usa los dominios de ejemplo reservados example.com, example.net y example.org, porque Reveal URLs solo reconoce una dirección en el texto de un enlace cuando termina en un sufijo público real. Los nombres inventados harbourline.example del resto del artículo ilustran el razonamiento, no lo que muestra el producto.

Hay dos cosas que deliberadamente no hace. No sigue las redirecciones: muestra adónde apunta el propio enlace, no adónde te enviará después un rastreador, un acortador o un servicio de inicio de sesión. Y no juzga si un sitio es seguro. Un enlace sin discrepancia no es automáticamente seguro. Que no aparezca en rojo solo significa que no se ha resaltado ninguna discrepancia: puede que el texto y el destino compartan dominio registrable, pero también puede que Reveal URLs no haya reconocido la dirección del texto o que un ajuste lo haya desactivado para ese sitio. Ni siquiera que los dominios coincidan demuestra que una página sea segura. Cuando el texto es un botón o palabras sin dirección, no hay nada que comparar: fíjate entonces en el destino que muestra Reveal URLs.

Las plataformas de alojamiento pueden dar a distintas personas subdominios de un mismo dominio de la plataforma, como alice.github.io y bob.github.io. Reveal URLs compara a nivel de dominio registrable según la lista de ICANN, así que no marca uno frente al otro, aunque puedan controlarlos personas distintas. Que compartan el dominio de la plataforma no significa que la misma persona controle ambas páginas.

Las URL largas se acortan junto al enlace, a 100 caracteres por defecto; en los ajustes puedes mostrar más. Si ves puntos suspensivos, mira la dirección completa antes de decidir: las versiones para navegadores y Thunderbird también la muestran al pasar el ratón por encima de la URL mostrada. La comparación usa siempre la URL completa, pero no la sigue.

Por eso algunos de los casos inofensivos de antes pueden salir en rojo igualmente: un enlace de boletín que nombra www.example.com pero apunta al rastreador de un servicio de envíos, como click.example.org, lleva, de hecho, primero a otro sitio. El recuadro rojo no dice "phishing"; dice "el texto y el destino no coinciden, échale un vistazo". Del mismo modo, puede que los casos difíciles de la sección anterior no salgan en rojo, porque la URL inmediata es de verdad de Google o de Microsoft. Precisamente al leer esa URL completa puedes fijarte en la segunda dirección que lleva escondida.

La antigüedad del dominio: una señal más

La regla que aplica Reveal URLs compara el texto visible de un enlace con el dominio de su propio destino. La antigüedad de un dominio es una señal aparte, que te toca valorar a ti como lector.

Un banco, una empresa de mensajería o una gran tienda online suelen tener su dominio desde hace años. Si un enlace que dice venir de un nombre tan consolidado lleva a un dominio registrado la semana pasada, es sospechoso, aunque el nombre parezca verosímil e incluso aunque el texto y el destino coincidan. En un análisis de 2019, Unit 42 de Palo Alto Networks constató que más del 70 % de los dominios recién registrados (según su definición, registrados o con cambio de titular en los últimos 32 días) eran "malicious", "suspicious" o "not safe for work", y que las campañas de phishing utilizan con frecuencia este tipo de dominios. El mismo informe recoge también motivos de lo más normales para un dominio nuevo: el lanzamiento de un producto, una marca o campaña nueva, un congreso o una web personal.

La antigüedad es, por tanto, una señal y no un veredicto, en ninguno de los dos sentidos. Un dominio nuevo puede ser totalmente legítimo y uno antiguo puede estar comprometido: la campaña de la cadena de Google que veíamos antes llevaba a sus víctimas, entre otros sitios, a subdominios .de comprometidos. La antigüedad añade contexto a lo que ya ves; por sí sola no decide nada.

Para comprobarla, un servicio de consulta de datos de registro como ICANN Lookup muestra los datos de registro actuales de un nombre de dominio, que suelen incluir la fecha en que se creó. Y si escaneas códigos QR: mi propia aplicación QR Quishing Detector, que pronto llegará a Google Play y a la App Store, tiene una consulta opcional de la antigüedad de registro del dominio. Viene desactivada por defecto, y la antigüedad que muestra es información para ti: no cambia la puntuación de riesgo de la aplicación.

Mira el destino antes de hacer clic

Reveal URLs es gratuito y de código abierto (AGPL-3.0-only). Ya está disponible para Chrome, Edge, Firefox, Safari y Thunderbird, como complemento de Gmail y como complemento de Outlook para Outlook en la web y en el escritorio. Las extensiones de navegador y el complemento de Thunderbird hacen todo su trabajo en tu propio dispositivo; el complemento de Gmail se ejecuta en los servidores de Google, porque es ahí donde se ejecutan los complementos de Gmail.

Otro dominio detrás de un enlace es una pregunta, no una respuesta. Lee el nombre de host desde la derecha, busca el dominio registrable y pregúntate si ese dominio pertenece a quien nombra el texto. Para saber más sobre cómo funciona Reveal URLs, consulta Reveal URLs: detecta enlaces de phishing antes de hacer clic; sobre por qué las aplicaciones de correo deberían mostrar siempre la URL, Phishing de enlaces en el correo: por qué tu aplicación debería mostrar siempre la URL; y sobre por qué un remitente que parece auténtico no basta, Código anti-phishing: una señal útil que no comprueba tus enlaces.