Código anti-phishing: una señal útil que no comprueba tus enlaces

Si usas crypto.com, Binance o un servicio parecido, es probable que te hayan animado a configurar un "código anti-phishing". Es un buen hábito, y este artículo no es un argumento en su contra. Es un argumento sobre lo que el código hace y lo que no hace, porque la distancia entre ambas cosas es justo donde la gente sigue cayendo.

Qué es un código anti-phishing

Un código anti-phishing es una palabra o frase que eliges y guardas asociada a tu cuenta. El servicio la incluye después en cada correo genuino que te envía, de modo que tienes algo concreto que buscar. crypto.com te permite configurar uno para su App y su Exchange (que comparten un único código sincronizado) y otro independiente para su plataforma de NFT. Binance incluye tu código en sus correos oficiales y, según dice, en sus mensajes SMS. El patrón es el mismo en todas partes: autoservicio, uno por cuenta, mostrado dentro del correo.

Kraken sigue una vía distinta y más sólida: puede firmar con PGP los correos que te envía (sus mensajes automáticos pueden llevar una firma PGP). Eso es criptografía real, no una frase de reconocimiento, y es el punto de comparación útil para todo lo que sigue.

En qué funciona bien

Frente al clásico correo de suplantación de marca ("tu cuenta está bloqueada, confirma ahora"), el código es una comprobación rápida, de un vistazo. Un mensaje genuino lleva la frase que tú y el servicio acordasteis esperar; uno falsificado normalmente no. Un código ausente o incorrecto es una señal de alarma inmediata, antes de haber leído una sola palabra del cuerpo. Para un control que configuras una vez y no vuelves a tocar, eso es un valor real, y merece la pena activarlo.

El punto ciego: no dice nada sobre los enlaces

Esto es lo que el código no puede decirte: adónde apunta un enlace. No dice absolutamente nada sobre las URL del mensaje.

Conviene ser preciso sobre el límite. El código responde a la pregunta "¿esto viene de la marca?". Entonces, ¿podría llegarte un correo que lleve el código esperado y aun así enlace a un host parecido? No porque un atacante reescriba en tránsito un correo genuino; no es así como funciona nada de esto. Pero una infraestructura de envío autenticada y de confianza puede entregar enlaces maliciosos, y de hecho lo hace. El compromiso de SendGrid de enero de 2026 (que traté en el artículo de opinión enlazado más abajo) mostró a atacantes distribuyendo phishing basado en enlaces a través de una plataforma de confianza cuyo correo pasaba la autenticación. Ese incidente no demuestra que nadie falsificara un correo de exchange con el código correcto. Pero sí concreta la hipótesis acotada: un sistema de envío de correo de un servicio comprometido, o un atacante que simplemente ha copiado tu código de un correo genuino anterior, podría en principio ponerte delante un mensaje que lleve el código correcto y el enlace equivocado.

Dejando esa hipótesis a un lado, la cuestión cotidiana sigue en pie. La mayoría del phishing no necesita tu código para nada. Necesita que no hayas configurado uno, o que no lo compruebes en ese momento, y necesita un enlace que parezca el de tu exchange pero no lo sea.

Una señal, no un secreto

A menudo se llama al código anti-phishing un "secreto compartido", y de manera informal así es como se vende la función: un secreto entre tú y el servicio. Técnicamente no se sostiene. Un valor que se imprime, en texto claro, dentro de cada correo genuino deja de ser un secreto en cuanto se ha visto cualquiera de esos correos. Se describe mejor como un token de reconocimiento estático, al portador: cualquiera que lea un solo mensaje genuino (un recibo reenviado, una captura de pantalla, un buzón vulnerado, un proveedor de marketing comprometido) tiene ya tu código.

Eso es lo que define sus límites:

• Puede ser objeto de phishing él mismo. Una página falsa de "confirma tu código anti-phishing" recolecta precisamente el token que haría que el correo de phishing futuro te pareciera legítimo.
• Depende de que lo compruebes, cada vez. Ese es justo el hábito que la urgencia está diseñada para romper.
• Solo ayuda si lo configuras primero, y la mayoría de la gente nunca lo hace.
• Se multiplica entre proveedores. Cada proveedor mantiene su propio código, y algunos guardan más de uno: crypto.com usa un único código para su App y su Exchange, pero otro independiente para NFT. Para que la señal siga siendo significativa conviene una frase distinta para cada código independiente, porque reutilizar una significa que un solo correo filtrado los debilita todos. Eso te deja un conjunto creciente de frases estáticas que recordar en cada proveedor, lo que puede fomentar la reutilización o hacer que los códigos sean más fáciles de olvidar, y una señal que no mantienes deja de serlo sin que te des cuenta.
• Está limitado por canal: el correo, más el SMS en Binance, pero nada para llamadas de teléfono, apps de chat o notificaciones push.
• No aporta ninguna garantía criptográfica. A diferencia de DKIM (una firma criptográfica por mensaje sobre un dominio de envío), DMARC (una política que comprueba que SPF y DKIM estén alineados con el dominio From visible) o BIMI (un indicador de logotipo de marca condicionado a DMARC), el código no demuestra nada matemáticamente. Y ninguno de esos tres responde tampoco por el cuerpo de un mensaje ni por adónde llevan sus enlaces.

Dos preguntas, dos capas

Leer el correo de forma segura se reduce en realidad a dos preguntas distintas:

1. ¿Este mensaje parece genuino? El código anti-phishing responde a esto de forma débil. DKIM y DMARC añaden evidencia real de autenticación de dominio (un dominio de envío firmado y un dominio From comprobado para la alineación), pero solo cuando tu sistema de correo verifica de verdad y muestra el resultado, e incluso entonces dan fe del dominio, no del contenido ni de la intención del mensaje.
2. ¿Cuál es la URL inmediata de este enlace? Nada de lo anterior responde a esto.

Esa segunda pregunta es donde se hace clic en los enlaces y se pierden las credenciales, y es la que un código anti-phishing nunca se diseñó para responder. Los dos controles son complementarios, no sustitutos: el código te da una pista sobre el remitente, y una herramienta que revela enlaces te muestra la URL inmediata. Mejor aún, una herramienta que revela enlaces sigue funcionando justo cuando el código te falla: en un mensaje que lleva el código correcto pero apunta a un sitio equivocado.

Ve el enlace antes de hacer clic

Reveal URLs es la respuesta práctica a esa segunda pregunta. Es gratuito y de código abierto (AGPL). Para cada enlace, muestra la URL inmediata real (la URL de verdad) impresa en línea encima del enlace, y la pone en rojo en cuanto el host de esa URL no coincide con un host nombrado en el texto visible del enlace. Sin pasar el ratón por encima y sin pulsación larga: la discrepancia está ahí de forma predeterminada. Muestra la URL inmediata y no sigue las redirecciones hasta una página de aterrizaje, y no verifica remitentes ni autenticación; ese es el trabajo de la otra capa.

Ya está disponible para Chrome, Edge, Firefox, Thunderbird y Outlook, con la versión móvil de Outlook y el complemento de Gmail aún por llegar y Safari próximamente.

Merece la pena configurar un código anti-phishing: es gratuito, y que falte es una advertencia útil. Solo no le pidas que haga un trabajo que no puede. Te dice que un correo parece genuino; nunca te muestra adónde apunta un enlace. Para ver la URL inmediata de cada enlace, consulta Reveal URLs: detecta enlaces de phishing antes de hacer clic, y para el argumento más amplio de que los clientes de correo deberían mostrar siempre la URL, consulta Phishing de enlaces: por qué tu app de correo debería mostrar siempre la URL.