¿Por qué fallan los inicios de sesión con enlace mágico?

El fallo que parece un error del usuario

El síntoma siempre es el mismo y siempre desconcierta. Alguien pide un enlace de acceso, el enlace llega, hace clic y tu aplicación le dice que no es válido o que ya se ha usado. Nada en tus registros parece roto: el correo se aceptó, el token se creó y el token se verificó. Se verificó — pero no lo hizo la persona a la que se lo enviaste. Entre tu envío y su clic hay una cola de máquinas leyendo ese mensaje: el producto de seguridad de correo del destinatario reescribiendo y siguiendo enlaces para comprobarlos, el cliente de correo precargando para que la vista previa aparezca al instante, pasarelas corporativas detonando URLs en un entorno aislado y, a veces, un filtro haciendo lo mismo a la entrada.

Nos pasó en nuestro propio registro en producción en agosto de 2026, y vale la pena repetir la forma que tuvo porque no parecía nada. Un registro pidió tres enlaces en una sola sesión. Los tres se verificaron en el servidor entre 16 y 23 segundos después del envío — demasiado rápido para ser alguien leyendo su bandeja — y todos los clics humanos posteriores se rechazaron como enlace ya usado. Esa persona solo consiguió entrar empezando de nuevo con un acceso social. Dos hábitos corrientes lo empeoran y producen la misma línea de registro: se pide el enlace en el móvil y se abre en el portátil, y se reenvía el correo de acceso a un compañero o a la propia segunda dirección. Si tu diseño da por hecho que la primera petición del token viene del navegador de la persona, los tres casos se leen como un ataque cuando en realidad son lo normal.

Averigua cuál es el tuyo

Antes de cambiar nada, averigua qué gastó el token de verdad. La marca de tiempo lo delata: un escáner o una precarga aterriza a los pocos segundos del envío, mientras que una persona tarda de decenas de segundos a minutos. Registra la hora, el agente de usuario y la IP de cada verificación junto a la hora del envío, y después léelos juntos.

La solución, en el orden que importa

El orden es decisivo, porque dos de estos pasos son seguros por separado y peligrosos en la secuencia equivocada.

1. Comprueba la caducidad antes de consumir Un token caducado no debe poder abrir una sesión jamás, cambies lo que cambies. Poner la comprobación de caducidad primero es lo que hace seguro el paso siguiente: sin ella, tolerar una apertura repetida alargaría la vida del enlace en lugar de limitarse a sobrevivir a una visita de más.
2. Deja que un enlace no caducado se abra más de una vez Acepta un token que ya se haya verificado pero siga dentro de su vida útil, y devuelve una marca que lo indique en lugar de un error. Un enlace debe morir cuando caduca, no cuando lo toca la primera máquina.
3. Conserva la primera marca de verificación Cuando aceptes una apertura repetida, no sobrescribas la hora de consumo original. Es el único registro de qué visita ganó realmente, y es lo primero que querrás mirar la próxima vez que alguien reporte esto.
4. Acorta la ventana en lugar de estrechar las aperturas Un enlace de vida corta que tolera varias visitas es más seguro en la práctica que uno de vida larga que muere al primer contacto. La vida corta es la que hace el trabajo de seguridad; el uso único solo fue siempre un sustituto de eso.
5. Deja siempre una segunda puerta Ofrece otra forma de entrar — una contraseña, una passkey o un acceso social — y muéstrala en la propia pantalla de error, no a tres clics de distancia. El registro que perdimos por esto se recuperó gracias al acceso social; sin esa puerta se habría perdido en el umbral.
6. Di algo útil cuando falle "Enlace no válido" le dice a alguien que ha hecho algo mal. "Este enlace ha caducado — aquí tienes uno nuevo", con un reenvío de un toque en la misma pantalla, mantiene a la persona dentro del flujo en vez de mandarla a tu bandeja de soporte.

La parte que nunca aparece como un error

El fallo de acceso se ve. El daño a la medición no se ve, y dura más que el error. Si tu evento de conversión de registro se dispara con la primera petición que llega a tu endpoint de verificación, entonces cada vez que un escáner llegue antes la conversión viajará en una redirección que ningún navegador ejecuta. Es exactamente lo que nos pasó: la marca de registro recién creado viajó con la petición del escáner, así que la conversión de registro en la plataforma de anuncios de esa persona nunca quedó grabada. Quien puje con esos datos está pujando sobre un número al que le faltan, en silencio, algunas de sus conversiones más caras de conseguir.

El hábito que lo detecta es aburrido pero fiable: cuenta la sesión completada, no el clic en el enlace, y trata el hueco entre "enlace pedido" y "sesión creada" como un paso propio del embudo. Si una parte real de las peticiones no llega nunca a ser sesión, ningún trabajo sobre la landing lo arreglará: es un fallo de mecanismo, no de persuasión. Mira cómo convertir visitantes de tu web en registros para el paso anterior y la tasa de activación para el siguiente. Si el correo no llega siquiera, la escalera de autenticación de dominio de cómo escribir correos en frío que no acaben en spam sirve igual para el correo transaccional. Y si aún estás decidiendo desde dónde enviarlo, Notifuse es una opción autoalojada.