Phishing de enlaces en el correo: por qué tu aplicación debería mostrar siempre la URL

La seguridad del correo electrónico ha avanzado muchísimo. SPF, DKIM y DMARC han reducido significativamente la suplantación de dominios cuando se implementan correctamente. Si un correo supera esas comprobaciones, lo más probable es que haya pasado por la infraestructura del dominio alegado, en lugar de provenir de un remitente suplantado. Eso supone una mejora real, pero sigue siendo una garantía limitada.

Pero hay una brecha. Una importante. Los estándares de autenticación verifican quién envió el correo, no a dónde lleva un enlace. Un atacante no necesita suplantar el dominio de tu banco si puede comprometer una cuenta legítima en una plataforma de confianza y enviarte un correo perfectamente autenticado que contiene un enlace malicioso. La autenticación pasa. La trampa está en el enlace.

En enero de 2026 vimos este mismo vector de ataque a gran escala a través de SendGrid, una de las mayores plataformas de envío de correo del mundo. La campaña fue eficaz, todas las comprobaciones de autenticación se superaron y, con frecuencia, los usuarios quedaban dependiendo de una de las pocas defensas visibles del lado del cliente: inspeccionar manualmente las URL de los enlaces. Este artículo explica por qué ocurrió y por qué las mitigaciones actuales se quedan cortas, y propone una solución radical:

Caso práctico: el ataque de phishing a SendGrid (enero de 2026)

A principios de enero de 2026, unos atacantes lanzaron una campaña de phishing dirigida que explotó la infraestructura de SendGrid de una forma especialmente ingeniosa. En lugar de intentar suplantar a SendGrid o a sus clientes, comprometieron cuentas reales de clientes de SendGrid mediante credential stuffing y reutilización de contraseñas. Una vez dentro, usaron la capacidad de envío legítima de SendGrid para distribuir correos de phishing.

Las cuentas comprometidas pertenecían a empresas reales: drummond.com, nellions.co.ke, theraoffice.com. Eran dominios consolidados con historial y reputación de envío. Cuando llegaron los correos de phishing, superaron todas las comprobaciones de autenticación. SPF alineado. Firmas DKIM validadas. Políticas DMARC superadas. Desde el punto de vista de la infraestructura, estos eran correos legítimos de SendGrid; simplemente daba la casualidad de que los enviaban usuarios no autorizados.

El vector de ingeniería social

Lo que hizo esta campaña especialmente eficaz fue la ingeniería social. En lugar de la habitual alerta de "tu cuenta ha sido suspendida", al parecer los correos se hacían pasar por SendGrid anunciando cambios de política controvertidos, planteados deliberadamente en torno a temas emocionalmente cargados y divisivos, diseñados para provocar una reacción fuerte e indignada.

El objetivo era que los destinatarios reaccionaran antes de pensar, pulsando "darse de baja" o "gestionar preferencias" sin detenerse a verificar la URL. Marca un cambio de táctica notable: un cebo diseñado para la indignación en lugar del miedo o la curiosidad, porque un lector que responde emocionalmente es menos propenso a escudriñar adónde va realmente un enlace.

El mecanismo de disfraz del enlace

Los correos de phishing incluían botones de acción etiquetados como opciones de gestión de preferencias o de recuperación de cuenta. El texto visible decía "Gestiona tus preferencias" o "Actualiza la configuración de la cuenta". Pero las URL reales apuntaban a páginas de captura de credenciales diseñadas para parecerse a la interfaz de inicio de sesión de SendGrid.

Este tipo de campaña puede basarse en una conocida técnica de adversario en el medio (adversary-in-the-middle): la página de inicio de sesión falsa valida en tiempo real las credenciales introducidas contra el servicio real. Si las credenciales funcionan, la víctima es redirigida al panel auténtico; si no, se le pide que vuelva a intentarlo. En cualquier caso, nunca ve el fallo revelador de un formulario de phishing muerto, que es lo que hace que el engaño resulte tan convincente.

Por qué fallaron las mitigaciones actuales

Este ataque eludió casi todas las medidas habituales de seguridad del correo:

• La autenticación se superó: SPF, DKIM y DMARC se validaron todos porque los correos procedían genuinamente de la infraestructura de SendGrid
• Reputación de dominio intacta: las cuentas remitentes comprometidas tenían historiales de envío consolidados
• Evasión del filtrado de contenido: el contenido de temática política parecía legítimo y no activaba los filtros de spam
• Explotación de la confianza: la marca de SendGrid combinada con una infraestructura autenticada generaba una falsa confianza
• Ofuscación del enlace: el texto visible mostraba propósitos inofensivos mientras las URL apuntaban a páginas de robo de credenciales

Para muchos usuarios, inspeccionar manualmente la URL real antes de pulsar era una de las pocas señales visibles del lado del cliente disponibles, aunque algunas organizaciones también tuvieran en juego reescritura de enlaces, escaneo en el momento del clic o protecciones del navegador. En el escritorio, esa inspección requiere pasar el cursor sobre el enlace y leer el destino en la barra de estado. En el móvil, requiere una pulsación larga y una inspección cuidadosa de la vista previa. Todo ello requiere conciencia del usuario, una acción deliberada y el conocimiento técnico para identificar un dominio sospechoso.

Para un análisis detallado de este ataque, consulta el caso práctico de Fred Benenson.

Vectores de ataque de phishing actuales

El ataque a SendGrid encaja en una tendencia más amplia. El phishing por correo ha evolucionado significativamente, y los atacantes están explotando las brechas tanto en la tecnología como en el comportamiento humano.

Suplantación del nombre visible

Los clientes de correo muestran los nombres de los remitentes de forma más prominente que las direcciones de correo. Un atacante puede establecer el nombre visible como "Soporte" o "Recursos Humanos" mientras que la dirección real del remitente es algo completamente distinto. Microsoft identificó un aumento significativo de estos ataques a lo largo de 2025, en particular a través de plataformas de Phishing como Servicio (PhaaS) como Tycoon2FA^[1]. En marzo de 2026, Microsoft, Europol y socios del sector desmantelaron 330 dominios activos asociados a Tycoon2FA, pero el volumen de campañas volvió a los niveles previos al desmantelamiento en cuestión de días, un recordatorio de que desbaratar la infraestructura de phishing como servicio solo compra un alivio temporal^[8].

Los usuarios se fijan en el nombre visible familiar y no escudriñan la dirección real del remitente. Los clientes de correo podrían reducir este problema mostrando las direcciones de forma más prominente o señalando las discrepancias entre los nombres visibles y los dominios de los remitentes, pero la mayoría no lo hace.

Suplantación de dominio interno

Un enrutamiento de correo mal configurado y unas protecciones inadecuadas contra la suplantación permiten a los atacantes enviar mensajes que parecen proceder de direcciones internas. Estos ataques suelen mostrar la misma dirección de remitente y de destinatario, o usan nombres visibles internos que los empleados reconocen y en los que confían.

La protección requiere políticas DMARC estrictas de rechazo, configuraciones de fallo absoluto (hard fail) de SPF y ajustes adecuados de los conectores de terceros, pero muchas organizaciones no los han implementado correctamente, en particular aquellas con registros MX que no apuntan directamente a su proveedor de correo.

Ataques homógrafos y homóglifos

Los atacantes registran dominios usando caracteres visualmente similares de conjuntos de caracteres distintos. La "а" cirílica (U+0430) tiene un aspecto idéntico a la "a" latina (U+0061) en la mayoría de las fuentes. Un dominio como "pаypal.com" (con una "a" cirílica) es indistinguible de "paypal.com" para la mayoría de los usuarios.

Los navegadores pueden mitigar esto: muchos muestran los dominios de riesgo en forma Punycode (p. ej., "xn--pypal-4ve.com"), pero el comportamiento es heurístico, depende de la política y varía entre navegadores, no es una protección universal. Los clientes de correo y el contenido web a menudo muestran directamente la forma del Nombre de Dominio Internacionalizado (IDN), lo que habilita el ataque. Los usuarios ven lo que parece un dominio legítimo y no tienen motivos para sospechar lo contrario.

El phishing de credenciales se disparó un 703 % en la segunda mitad de 2024^[2], y el coste medio de una brecha alcanzó los 4,44 millones de dólares^[3]. Más recientemente, Microsoft detectó 8.300 millones de amenazas de phishing por correo solo en el primer trimestre de 2026, el 78 % de ellas basadas en enlaces^[6], lo que confirma que los enlaces maliciosos siguen siendo el mecanismo de entrega dominante. La sofisticación y la escala de estos ataques siguen creciendo.

Abuso de servicios legítimos

Además de SendGrid, los atacantes han abusado del servicio Application Integration de Google Cloud, la infraestructura de correo legítima de Microsoft y numerosas otras plataformas de confianza. Cuando la infraestructura de envío es genuinamente de confianza y está autenticada, los filtros de seguridad de correo tradicionales no tienen nada que señalar. La superficie de ataque se ha desplazado de la suplantación al compromiso.

Un ejemplo claro surgió a principios de 2026 con el abuso de Amazon Simple Email Service (SES). Los atacantes recolectan claves de acceso de AWS filtradas de repositorios públicos, archivos de entorno e imágenes de contenedores, y luego usan las cuentas SES comprometidas para enviar mensajes de phishing y de compromiso del correo corporativo (BEC). Como el correo se origina genuinamente en la infraestructura de Amazon, supera SPF, DKIM y DMARC, e incluso lleva .amazonses.com en las cabeceras Message-ID. Los mensajes, que a menudo suplantan servicios como DocuSign, enlazan a páginas de inicio de sesión de captura de credenciales alojadas en amazonaws.com^[7]. Es el mismo patrón que el caso de SendGrid: comprometer infraestructura de confianza y luego dejar que la autenticación trabaje a favor del atacante.

Enfoques de mitigación existentes

Los proveedores de correo y los fabricantes de seguridad han desarrollado diversas estrategias de mitigación, cada una con sus propias fortalezas y limitaciones.

Reescritura de enlaces y escaneo en el momento del clic

Servicios como Microsoft Defender Safe Links, Check Point Harmony Email, Sophos Email Security y Symantec Email Security reescriben las URL de los correos para redirigirlas a través de un servicio de escaneo. Cuando un usuario pulsa el enlace, el servicio realiza comprobaciones en tiempo real contra bases de datos de inteligencia de amenazas y análisis de malware.

Fortalezas: eficaz contra URL y dominios maliciosos conocidos. Proporciona protección en el momento del clic, atrapando amenazas que surgen después de que el correo fuera entregado.

Limitaciones: puede no funcionar con mensajes firmados con S/MIME o cifrados, ya que la reescritura puede romper la firma. Las organizaciones pueden incluir en listas de permitidos las URL de seguimiento para evitar la reescritura, lo que puede abrir brechas de seguridad. Las URL reescritas pueden caducar^[4], rompiendo los enlaces de correos antiguos. Y depende de inteligencia de amenazas centralizada, que puede pasar por alto ataques de día cero o dirigidos.

Inspección de URL con vista previa al pasar el cursor

Los clientes de correo de escritorio muestran la URL real en una barra de estado o información sobre herramientas cuando los usuarios pasan el cursor sobre un enlace. Los clientes móviles ofrecen una funcionalidad similar mediante gestos de pulsación larga.

Fortalezas: permite a los usuarios con conocimientos técnicos verificar los destinos antes de pulsar. No requiere cambios de infraestructura.

Limitaciones: requiere conciencia del usuario y una acción deliberada. La interacción en móvil es menos intuitiva que el cursor del escritorio. El "Nuevo Outlook" de Microsoft fue criticado en 2024 por una funcionalidad inadecuada de vista previa de URL^[5], lo que demuestra que incluso las protecciones consolidadas pueden desaparecer por decisiones de producto. Los usuarios deben saber qué constituye una URL sospechosa, entender las estructuras de dominio y reconocer los ataques homógrafos.

Como comentó un usuario durante la controversia del Nuevo Outlook: "Ver la URL verdadera es la forma número 1 que tiene la gente de evitar ser estafada por correo". Sin embargo, esta protección es totalmente voluntaria y depende del comportamiento del usuario.

Indicadores visuales de confianza

Algunos clientes de correo implementan señales visuales para distinguir los enlaces de confianza de los no confiables. Por ejemplo, los dominios de confianza podrían aparecer con un fondo blanco y un icono de enlace, mientras que los dominios no confiables obtienen un fondo naranja y un icono de advertencia.

Fortalezas: protección pasiva que no requiere ninguna acción del usuario. Las advertencias visualmente distintas pueden disuadir de los clics.

Limitaciones: se basa en listas de confianza predefinidas. No aborda las cuentas comprometidas en plataformas de confianza (como en el caso de SendGrid). Los indicadores de confianza pueden crear una falsa confianza; los usuarios podrían confiar en cualquier enlace sin advertencia, incluso si se trata de un ataque dirigido contra la infraestructura específica de una organización.

La propuesta: mostrar siempre la URL

¿Y si los clientes de correo simplemente mostraran la URL real junto a cada enlace, independientemente del texto visible? Sin necesidad de pasar el cursor. Sin necesidad de inspección manual. Solo URL de destino siempre visibles.

Cómo funcionaría

Los motores de renderizado de correo modificarían el aspecto de los enlaces:

<!-- El correo contiene un enlace corriente -->
<a href="https://malicious-site.com/phishing">Pulsa aquí para verificar tu cuenta</a>

<!-- Los clientes actuales renderizan solo el texto del enlace: -->
[Pulsa aquí para verificar tu cuenta]

<!-- Propuesta: el cliente inyecta el destino antes del texto -->
<a href="https://malicious-site.com/phishing">
  <span class="email-url-display">→ https://malicious-site.com/phishing</span>
  Pulsa aquí para verificar tu cuenta
</a>

<!-- ...de modo que el usuario ahora ve: -->
→ https://malicious-site.com/phishing
[Pulsa aquí para verificar tu cuenta]

El dominio (o la URL completa, según la política) se mostraría directamente encima del texto del enlace. No hace falta ninguna acción especial del usuario ni conocimientos técnicos. Solo visibilidad inmediata e inevitable de adónde va realmente el enlace.

Maqueta visual: actual frente a propuesta

Fortalezas de este enfoque

• Reduce enormemente la discrepancia de texto visible: el engaño específico que posibilitó la campaña de SendGrid deja en gran medida de funcionar una vez que los usuarios pueden ver siempre el destino real
• No requiere acción del usuario: a diferencia de la vista previa al pasar el cursor, esta es una protección pasiva que no depende de la conciencia ni del comportamiento del usuario
• Funciona en móvil: no se necesitan gestos de pulsación larga ni interacciones complejas
• Aborda los ataques homógrafos: los dominios sospechosos se vuelven visibles y pueden ser inspeccionados
• Implementable en el momento de presentación: las extensiones de navegador y los complementos de clientes de correo pueden posprocesar el contenido renderizado; los clientes nativos afrontan más trabajo (saneamiento, UX móvil, contenido firmado, accesibilidad)
• Agnóstico al transporte: se aplica cuando se renderiza el mensaje, sin cambiar el transporte del mensaje, aunque los flujos de correo firmado o de alta integridad aún necesitan un diseño de UX cuidadoso

Debilidades y compromisos

• Degradación significativa de la UX: los correos se vuelven más recargados y difíciles de leer, en particular los correos de marketing con muchos enlaces
• Rompe las campañas de marketing legítimas: las URL de seguimiento (p. ej., el seguimiento de clics de boletines) parecen sospechosas incluso cuando son inofensivas
• Aumenta el ruido visual: las URL largas consumen espacio en pantalla y reducen la legibilidad
• Puede reducir las tasas de clics: las llamadas a la acción legítimas podrían ver reducida la participación a medida que los usuarios se ven abrumados por la información de las URL
• No aborda el compromiso de cuentas: si un atacante controla un dominio legítimo, la URL parecerá fiable incluso cuando se muestre
• Sigue siendo necesaria la formación del usuario: los usuarios deben entender qué constituye un dominio sospechoso

Enfoques de implementación

Los clientes de correo podrían implementar esto de varias maneras:

• Mostrar la URL completa: mostrar la URL completa para cada enlace
• Mostrar solo el dominio: mostrar únicamente el dominio, reduciendo el desorden mientras se preserva el beneficio de seguridad
• Resaltado de enlaces externos: mostrar las URL solo para los enlaces que apuntan fuera del dominio del remitente
• Ajuste de preferencia del usuario: permitir a los usuarios activarlo o desactivarlo (aunque esto reduce la eficacia para los usuarios menos técnicos)

Lo que no resuelve

Mostrar siempre la URL derrota la discrepancia de texto visible, pero no es un remedio universal. Dos técnicas que crecieron con fuerza a lo largo de 2026 la sortean por completo:

• Phishing de código de dispositivo OAuth: en una campaña descubierta a finales de abril de 2026, los operadores de Tycoon2FA abandonaron por completo las páginas de inicio de sesión falsas. Se pide a la víctima que introduzca un código corto en la página genuina microsoft.com/devicelogin; Microsoft gestiona entonces la autenticación, incluida la MFA, y sin saberlo emite tokens OAuth a un dispositivo controlado por el atacante^[9]. Mostrar la URL revela un dominio legítimo de Microsoft, así que no hay nada sospechoso que señalar.
• Phishing con código QR ("quishing"): el destino está incrustado en una imagen en lugar de en una etiqueta de enlace, de modo que no hay texto de enlace ni URL que el cliente pueda mostrar en absoluto. Microsoft registró un aumento del 146 % en el phishing con código QR durante el primer trimestre de 2026, de 7,6 millones a 18,7 millones de mensajes^[6].

Ambas son variantes del phishing de adversario en el medio, en el que el atacante retransmite una sesión de autenticación en vivo y captura tokens en lugar de contraseñas. Las URL siempre visibles elevan el listón frente a los ataques más comunes, pero refuerzan, en vez de sustituir, la necesidad de defensas en capas.

Estrategias alternativas

Mostrar siempre las URL es un enfoque, pero no la única posibilidad. Aquí tienes varias alternativas, cada una con diferentes compromisos entre seguridad y usabilidad.

Enlaces solo al mismo dominio (remitentes verificados)

Los clientes de correo podrían imponer una política según la cual los remitentes autenticados solo puedan incluir enlaces a su propio dominio. Si un correo de bank.com está autenticado con DMARC, puede incluir enlaces a bank.com pero no a dominios de terceros.

Ventajas: evita los enlaces directos a dominios externos obviamente sospechosos. Mantiene una UX limpia para las comunicaciones internas. Aprovecha la infraestructura de autenticación existente. Puede atrapar intentos de phishing poco sofisticados.

Inconvenientes: no evita los ataques que usan URL de seguimiento de plataformas de correo (como el seguimiento de clics de SendGrid), que redirigen a través de dominios de confianza. Rompe casos de uso legítimos como los boletines que enlazan a recursos, las comunicaciones de socios, la agregación de contenido y los documentos compartidos. No evita los ataques de toma de control de subdominios. Puede fomentar el uso de acortadores de URL, frustrando el propósito. Requiere una imposición estricta de DMARC.

Viabilidad: media. La implementación técnica es sencilla, pero la imposición de la política crea problemas de usabilidad significativos.

Mostrar la URL completa con confirmación al pulsar

Mostrar la URL y exigir una confirmación explícita antes de navegar. Cuando un usuario pulsa un enlace, mostrar un diálogo: "Estás a punto de visitar https://example.com. ¿Continuar?".

Ventajas: preserva la funcionalidad del enlace con consentimiento explícito del usuario. Educativa: entrena a los usuarios para verificar las URL. Puede configurarse con listas de permitidos para dominios de confianza.

Inconvenientes: fatiga de clic: los usuarios confirmarán automáticamente sin leer, igual que hacen con otros diálogos de seguridad. Duplica el coste de interacción para cada enlace del correo. Usabilidad móvil pésima. No evita los ataques sofisticados, porque los usuarios no leen con atención los diálogos de confirmación.

Viabilidad: alta técnicamente, pero con una aceptación de usuario muy baja. La fatiga de confirmación la hace en gran medida ineficaz.

Política de visualización de URL graduada

Implementar modos de visualización configurables que permitan a los usuarios elegir su nivel de seguridad:

Modo estricto Usuarios centrados en la seguridad	Modo equilibrado Recomendado por defecto	Modo permisivo Usuarios centrados en la UX
→ https://example.com/verify?token=abc123 [Verificar cuenta]	→ example.com (mismo dominio) [Verificar cuenta] → external-site.com (distinto) [Pulsa aquí]	(URL oculta, mostrada al pasar el cursor) [Verificar cuenta]
URL completa siempre visible	Mostrar el dominio solo para enlaces externos	Comportamiento actual, inspección manual

Ventajas: equilibra seguridad y usabilidad. Los usuarios pueden elegir su preferencia. Las organizaciones pueden imponer políticas para distintos grupos de usuarios. El modo equilibrado ofrece una protección significativa sin un desorden abrumador.

Inconvenientes: requiere conciencia del usuario para configurarlo adecuadamente. Los usuarios menos técnicos pueden elegir el modo permisivo y seguir siendo vulnerables. Complejidad en la implementación y en la formación del usuario.

Viabilidad: media. La implementación es sencilla, pero la conciencia y la formación del usuario para la configuración son un reto.

Puntuación de riesgo de enlaces basada en aprendizaje automático

Entrenar modelos de aprendizaje automático para evaluar el riesgo de los enlaces en función de la reputación del dominio, el historial del remitente, los patrones de discrepancia entre texto y URL, el análisis léxico de los dominios y el comportamiento histórico de clics. Mostrar puntuaciones de riesgo o advertencias solo para los enlaces sospechosos.

Ventajas: detección automatizada sin romper los casos de uso legítimos. Se adapta a los patrones de ataque cambiantes. Escala bien en organizaciones grandes. Puede combinar múltiples señales (reputación del remitente, antigüedad del dominio, similitud de texto, etc.).

Inconvenientes: los falsos positivos son un problema significativo: los enlaces legítimos marcados como sospechosos provocan fatiga en el usuario y erosionan la confianza en el sistema. Los usuarios aprenden a ignorar las advertencias, reduciendo la eficacia con el tiempo. Los falsos negativos crean riesgo. Requiere una cantidad significativa de datos de entrenamiento y un ajuste continuo. Los atacantes pueden potencialmente aprender a evadir los modelos de ML. Implementación compleja que requiere infraestructura de ML.

Viabilidad: media. Los grandes proveedores de correo tienen los datos y los recursos, pero la fatiga por falsos positivos limita significativamente la eficacia en el mundo real.

UX de vista previa móvil mejorada

Mejorar la funcionalidad de vista previa de enlaces en móvil. En lugar de requerir una pulsación larga, mostrar una pequeña insignia de dominio junto a cada enlace. Tocar el enlace navega; tocar la insignia muestra los detalles completos de la URL.

Ventajas: mejora la seguridad móvil sin impacto en el escritorio. Proporciona visibilidad inmediata del dominio. Preserva la UX actual mientras mejora la seguridad.

Inconvenientes: sigue requiriendo conciencia y acción del usuario. Añade complejidad visual al renderizado de enlaces. Puede ser confusa para los usuarios menos técnicos. No aborda las vulnerabilidades del escritorio.

Viabilidad: alta. Implementación del lado del cliente relativamente sencilla con un beneficio significativo para la seguridad móvil.

Firma criptográfica de enlaces (DKIM para URL)

¿Y si los enlaces de los correos pudieran firmarse criptográficamente, de forma similar a como DKIM firma las cabeceras y el cuerpo del correo? Un remitente podría firmar cada URL de su correo, y el cliente de correo del destinatario verificaría estas firmas antes de permitir la navegación.

Cómo funcionaría: un nuevo tipo de registro DNS (p. ej., un registro TXT EMLNK o _linkkey) publicaría la clave pública para la verificación de enlaces de correo, de forma similar a como DKIM usa los registros _domainkey. Fundamentalmente, esto estaría separado de DKIM: las claves de firma DKIM residen en el servidor de correo y no deberían ser accesibles para las aplicaciones de correo. Las claves de firma de enlaces serían gestionadas por los sistemas de composición de correo de la organización o por el proveedor de servicios de correo.

Al redactar un correo, la aplicación remitente firmaría cada URL usando la clave privada de firma de enlaces del dominio. Estas firmas podrían incrustarse como una parte MIME separada (p. ej., application/link-signatures) o como atributos data-signature en las etiquetas de enlace. El cliente de correo receptor obtendría la clave pública de DNS (p. ej., _linkkey.example.com) y verificaría cada firma antes de permitir la navegación.

Si la firma de un enlace no se verifica, porque la URL fue modificada, inyectada, o el remitente no la incluyó realmente, el cliente de correo podría advertir al usuario, desactivar el enlace o mostrarlo de forma diferente.

Ventajas: demuestra criptográficamente la autenticidad del enlace. Evita los ataques de inyección y modificación de enlaces. Se apoya en la infraestructura DKIM existente y en la distribución de claves. Funciona con correos cifrados. No requiere cambios en la visualización de URL. Podría implementarse como una extensión de los estándares de correo existentes.

Inconvenientes: requiere nuevos estándares de correo y una adopción generalizada. No evita los ataques desde cuentas comprometidas (que pueden firmar enlaces maliciosos con claves válidas). Complejidad de implementación para clientes y servidores de correo. Requiere nueva infraestructura DNS y nuevos tipos de registros. Retos de compatibilidad hacia atrás con los correos existentes. Puede romper el reenvío de correo legítimo y los escenarios de listas de distribución donde el contenido se modifica.

Viabilidad: de baja a media a corto plazo debido a los requisitos de estandarización, pero potencialmente de alto valor a largo plazo. Requeriría el desarrollo de un RFC del IETF y la adopción por parte de los principales proveedores de correo.

Comparación de las estrategias de mitigación

Estrategia	Eficacia	Impacto en UX	Viabilidad	Acción del usuario
Mostrar siempre la URL	●●● Alta	●●● Significativo	●● Fácil de construir, difícil de adoptar	Ninguna
Solo mismo dominio	●● Media	●●● Rompe flujos de trabajo	●● Media	Ninguna
Confirmación al pulsar	● Baja	●●● Muy alto	●●● Alta	Cada clic
Política graduada	●●● Alta	●● Configurable	●● Media	Configuración
Puntuación de riesgo ML	●● Media	● Mínimo	●● Compleja	Ninguna
Firma criptográfica de enlaces	●●● Alta	● Ninguno	● Baja (estándar nuevo)	Ninguna
UX móvil mejorada	●● Media	● Bajo	●●● Alta	Opcional
Actual (pasar el cursor)	● Baja	● Ninguno	●●● Existe	Manual

Barreras de adopción y retos del sector

Aunque mostrar-siempre-la-URL u otras estrategias similares resulten técnicamente eficaces, su adopción generalizada afronta obstáculos significativos.

Resistencia del departamento de marketing

Los equipos de marketing dependen en gran medida de la estética y el seguimiento de los enlaces. Un botón de "Pulsa aquí para reclamar tu oferta" es más atractivo que "→ tracking.mailchimp.com/c/eJw... [Pulsa aquí para reclamar tu oferta]". Las métricas de marketing por correo, como las tasas de apertura, de clics y de conversión, podrían disminuir si las URL están siempre visibles, generando resistencia interna a la implementación.

Las organizaciones deben equilibrar la seguridad frente al impacto en los ingresos. Para muchas empresas, una reducción del 10 % en las tasas de conversión del correo tiene consecuencias directas en el resultado final. Los equipos de seguridad necesitarán demostrar un ROI claro o beneficios de cumplimiento normativo para superar esta resistencia.

Preocupaciones de experiencia de usuario

El correo es un medio de comunicación, no solo un perímetro de seguridad. Los usuarios valoran la legibilidad, la claridad y la estética. Las URL siempre visibles degradan la experiencia de lectura, en particular en boletines, resúmenes y correos con mucho contenido. Si los usuarios encuentran los correos más difíciles de leer, pueden desentenderse por completo, reduciendo el valor del correo como canal de comunicación.

Los equipos de diseño se resistirán a los cambios que hacen los correos objetivamente más feos y menos usables. Las mejoras de seguridad que perjudican significativamente la UX afrontan batallas cuesta arriba en la aceptación de los usuarios.

Requisitos de coordinación del sector

La seguridad del correo depende de estándares adoptados en todo el sector. SPF, DKIM y DMARC tuvieron éxito porque los principales proveedores (Gmail, Outlook, Yahoo) los implementaron e impusieron todos. Sería necesario un esfuerzo coordinado similar para las políticas de visualización de URL.

Si solo un proveedor de correo implementa mostrar-siempre-la-URL, los usuarios podrían simplemente cambiarse a proveedores con mejor UX. Los organismos de estandarización (IETF, grupos de trabajo de clientes de correo) tendrían que desarrollar especificaciones, y los principales proveedores tendrían que adoptarlas aproximadamente en el mismo plazo.

El problema de la compatibilidad hacia atrás

Miles de millones de correos existentes contienen enlaces formateados para los motores de renderizado actuales. Cambiar cómo se muestran los enlaces afecta retroactivamente a los correos archivados, los mensajes reenviados y las conversaciones encadenadas. Esto crea confusión cuando los correos antiguos se renderizan de repente de forma distinta, o cuando usuarios con distintos clientes de correo ven distintas presentaciones de enlaces en el mismo hilo.

Conclusión y llamada a la acción

Los estándares de autenticación del correo han abordado con éxito la suplantación de dominios, pero el phishing basado en enlaces sigue siendo una vulnerabilidad crítica. El ataque a SendGrid demuestra que las cuentas comprometidas en plataformas de confianza pueden eludir todas las comprobaciones de autenticación, dejando a los usuarios con la inspección manual de URL como única defensa.

Mostrar siempre el destino del enlace reduciría enormemente la discrepancia de texto visible como técnica de engaño, aunque no el phishing a través de dominios de confianza, códigos QR o flujos de código de dispositivo OAuth. Puede aplicarse en el momento de presentación, pero conlleva costes reales de UX y afronta barreras de adopción sustanciales.

Quizá la respuesta no sea una única solución. La defensa en profundidad también se aplica aquí: las políticas de visualización graduadas dan a los usuarios la posibilidad de elegir, la puntuación de riesgo basada en ML proporciona detección automatizada, la UX móvil mejorada mejora la capacidad de inspección, y los estándares de todo el sector podrían establecer protecciones de referencia.

Lo que está claro es que no hacer nada no es viable. El phishing crece en sofisticación y escala: el phishing de credenciales se disparó un 703 % a finales de 2024^[2], los costes de las brechas se acercan a los 4,5 millones de dólares^[3], y Microsoft registró 8.300 millones de amenazas de phishing por correo en un solo trimestre de 2026^[6]. El sector debe actuar.

Para los desarrolladores de clientes de correo: considerad implementar políticas de visualización de URL graduadas y una UX de inspección móvil mejorada. Aportan beneficios de seguridad con un impacto configurable en la UX.

Para los equipos de seguridad: evaluad la puntuación de riesgo de enlaces basada en ML e imponed políticas estrictas de reescritura de enlaces. Aplicad defensas en capas y no os apoyéis únicamente en el comportamiento del usuario.

Para los organismos de estandarización: iniciad debates sobre estándares de visualización de URL y protocolos de seguridad de enlaces. La seguridad del correo necesita una evolución continua.

Para los usuarios: activad las funciones de vista previa de enlaces, inspeccionad las URL antes de pulsar, y abogad por una mejor UX de seguridad en vuestros clientes de correo.

La brecha entre la autenticación y la seguridad de los enlaces no se cerrará sola. Es hora de que el sector tenga esta conversación.

Referencias

1. Phishing actors exploit complex routing and misconfigurations to spoof domains. Microsoft Security Blog (enero de 2026). Microsoft Defender for Office 365 bloqueó más de 13 millones de correos maliciosos vinculados a Tycoon2FA en octubre de 2025.
2. SlashNext 2024 Phishing Intelligence Report (PRNewswire). Los ataques de phishing de credenciales aumentaron un 703 % en el segundo semestre de 2024.
3. IBM Cost of a Data Breach Report 2025. Coste medio global de una brecha: 4,44 millones de dólares.
4. Complete Safe Links overview for Microsoft Defender for Office 365. Microsoft Learn. Documentación sobre la funcionalidad de escaneo y reescritura de URL de Safe Links, incluidas las limitaciones relativas a la caducidad de las URL y los enlaces de un solo uso.
5. New Outlook not showing link URLs. Microsoft Tech Community. Debates de usuarios sobre la ausencia de la vista previa de URL al pasar el cursor en el Nuevo Outlook, que suscita preocupaciones de seguridad sobre la verificación de enlaces antes de pulsar.
6. Email threat landscape: Q1 2026 trends and insights. Microsoft Security Blog (abril de 2026). 8.300 millones de amenazas de phishing por correo detectadas en el primer trimestre de 2026, el 78 % de ellas basadas en enlaces; el phishing con código QR creció un 146 % durante el trimestre.
7. Phishing campaigns and BEC attacks through Amazon SES. Securelist (Kaspersky), 2026. Los atacantes abusan de claves de acceso de AWS filtradas para enviar mensajes de phishing y BEC plenamente autenticados a través de Amazon SES, con páginas de captura de credenciales alojadas en amazonaws.com.
8. Tycoon2FA phishing-as-a-service platform persists following takedown. CrowdStrike (marzo de 2026). Microsoft, Europol y socios desmantelaron 330 dominios activos de Tycoon2FA el 4 de marzo de 2026, pero el volumen de campañas volvió a los niveles previos al desmantelamiento en cuestión de días.
9. Tycoon 2FA operators use OAuth device code phishing to bypass MFA. GBHackers (abril de 2026). Campaña de finales de abril de 2026 que abusa de microsoft.com/devicelogin para capturar tokens OAuth sin presentar una página de inicio de sesión falsa.