La detección de errores en emails evita inscripciones perdidas detectando equivocaciones como gmail.con. Aprende patrones de UX prácticos, heurísticas y pasos de validación que los usuarios aceptan.
Concéntrate en los errores de dominio de alta confianza que estén a una o dos letras de un proveedor común, como gmail.con → gmail.com o hotnail.com → hotmail.com. También normaliza y corrige fallos de formato como espacios al final, un punto final, o una coma en lugar de un punto antes de intentar hacer coincidencias.
Porque la parte local (antes de @) suele ser única y difícil de adivinar de forma segura, mientras que la parte de dominio es repetitiva y predecible. Sugerir correcciones en el dominio es más preciso y menos probable que convierta una dirección correcta en una incorrecta.
Preséntalas como una sugerencia que el usuario puede aceptar o ignorar. La corrección silenciosa puede enviar futuros restablecimientos de contraseña o facturas a la bandeja equivocada y generar confusión cuando el usuario cree haberse registrado con una dirección distinta de la que guardaste.
En blur suele ser la opción más calmada porque aparece cuando el usuario ha terminado con el campo. Si quieres que se sienta más rápido, usa una pausa corta al escribir, pero ajústala para que no dispare en cada pulsación. En submit es lo menos intrusivo, pero también cuando el usuario se siente “terminado”, por lo que las correcciones pueden resultar más molestas.
Sé breve y neutral, como “Did you mean gmail.com?” e incluye una acción de un toque para aplicar la corrección. Hazla descartable; si el usuario la descarta, no la vuelvas a mostrar a menos que cambie el correo.
Usa una lista pequeña y curada de dominios que estés dispuesto a sugerir, normaliza la entrada (recorta espacios, convierte a minúsculas solo la parte del dominio), luego calcula una puntuación de coincidencia cercana como la distancia de edición. Sugiere solo cuando haya un claro mejor resultado dentro de un umbral estricto y trata la sugerencia como una opción, no como una reescritura.
No. La lógica de sugerencia es fácil de evitar con scripts o llamadas directas a la API, y las comprobaciones en la UI no verifican si un dominio tiene registros MX o si la dirección es desechable. Ejecuta la misma lógica básica en el servidor y complétala con comprobaciones de validación reales para que el backend haga cumplir las reglas.
Evita sugerir cuando no tienes mucha confianza, cuando varios dominios están igual de cerca, o cuando el dominio parece intencionalmente personalizado (correos corporativos o escolares, TLDs poco comunes). También evita cambiar la parte local; eso es suponer y puede convertir una dirección correcta en incorrecta.
Trátalos como válidos. [email protected] es normal y se usa para filtrar. No los elimines ni avises salvo que tu sistema realmente no pueda manejarlos; si no puedes, explica la limitación claramente en vez de marcarlo como un error.
Verimail puede validar el correo enviado durante el registro con comprobaciones de sintaxis según RFC, verificación de dominio y MX, y detección de proveedores desechables. Una configuración común es usar sugerencias de typo para prevenir errores evidentes antes del envío y luego usar Verimail en el backend para decidir si aceptar, rechazar o marcar la dirección según las señales de validación.
Un carácter incorrecto en una dirección de correo puede detener una inscripción en seco. Si alguien escribe gmail.con en lugar de gmail.com, tu correo de confirmación nunca llega. El usuario, por lo general, no tiene idea de por qué. Actualiza la página, lo intenta de nuevo o se va. El mismo error más adelante rompe restablecimientos de contraseña, avisos de facturación y cualquier mensaje que pruebe que una cuenta es real.
Los errores en el correo importan porque la mayoría de la gente no piensa en su dirección como “datos”. Piensan: “Lo escribí, así que debe estar bien.” Cuando no aparece nada en su bandeja de entrada, culpan a tu producto, no a su teclado.
El impacto se acumula rápido: más inscripciones abandonadas porque los usuarios no pueden verificar, más tickets de soporte que suenan a “no recibí el correo”, clientes potenciales perdidos y atribución más confusa porque los contactos nunca llegan a ser localizables, y riesgo de entregabilidad cuando tu sistema sigue reintentando direcciones malas.
Los errores también son predecibles. Un pequeño conjunto de dominios causa una gran proporción de equivocaciones: gmail.con, hotnail.com y yaho.com aparecen una y otra vez. Detectarlos temprano es uno de los pocos ajustes de UX que puede mejorar de forma medible la finalización sin cambiar lo que ofreces.
Ayuda ser claro sobre lo que la detección de errores en emails puede y no puede hacer. Puede detectar errores probables (a menudo comparando el dominio con proveedores comunes) y sugerir una corrección antes del envío. No puede garantizar que el buzón exista, que la persona lo posea o que la dirección sea segura para aceptar.
Un enfoque práctico es: sugerir cuando tengas confianza, validar cuando necesites certeza. Por ejemplo, Verimail puede validar direcciones en el registro usando comprobaciones como reglas de sintaxis, verificación de dominio y MX, y detección de correos desechables, mientras que las sugerencias de typos evitan que errores simples lleguen a enviarse.
La mayoría de la gente no escribe mal su correo a propósito. Escriben rápido, en un teclado pequeño o mientras cambian de app. Una buena detección de typos se centra en errores que ocurren con frecuencia y para los cuales es seguro sugerir correcciones.
Las correcciones de mayor valor suelen estar en la parte de dominio (todo lo que va después de la @). La gente generalmente conoce su nombre de usuario, pero teclean mal proveedores populares. Los patrones comunes incluyen letras faltantes (gmal.com), letras intercambiadas (gmial.com) y letras duplicadas (gmaill.com). Son fáciles de detectar porque están a una o dos ediciones de distancia de un dominio conocido.
Los errores de TLD son otro gran grupo porque a primera vista parecen válidos. El clásico es gmail.con en lugar de gmail.com, pero también verás .cmo, .coom o un TLD de país por accidente. Si el dominio coincide fuertemente y solo el final está mal, una sugerencia suele ser bienvenida.
No todos los “typos” son ortográficos. Los problemas de formato también causan fallos silenciosos, sobre todo cuando los usuarios copian y pegan. Vigila espacios iniciales o finales, un punto final ([email protected].), puntos dobles ([email protected]), comas en vez de puntos (name@gmail,com) y signos @ faltantes o extra.
El móvil añade sus propios problemas: teclas adyacentes (n y m), autocorrección que cambia un dominio, o el teclado que inserta un espacio después de un punto. Un ejemplo realista: alguien escribe [email protected] en su teléfono. Una sugerencia simple como “¿Quiso decir [email protected]?” evita un ticket de soporte y una inscripción perdida sin que el formulario parezca estricto.
La detección de typos funciona mejor como un ayudante, no como una barrera. Trátalo como el corrector ortográfico: rápido, discreto y fácil de ignorar cuando el usuario tiene razón.
Las comprobaciones del lado cliente deberían ocurrir cerca del momento de la escritura para que la gente pueda corregir antes de avanzar. Mantenlas ligeras: compara la parte del dominio con una lista corta de proveedores comunes y sugiere solo cuando la coincidencia sea muy fuerte (como gmail.con -> gmail.com). No bloquees el envío solo porque crees haber encontrado un typo. Algunos dominios raros son perfectamente válidos.
Las comprobaciones del lado servidor son la red de seguridad. Los usuarios pueden omitir el navegador, los scripts pueden publicar directamente e incluso una UI excelente no detiene todas las direcciones malas. Ejecuta la misma lógica de typos en el backend y luego sigue con una validación real (sintaxis, dominio, MX, detección de desechables). Una API de validación de correo como Verimail puede encargarse de las comprobaciones más profundas para que no tengas que construirlas y mantenerlas tú.
Cuándo mostrar sugerencias depende del estilo de tu formulario:
Las personas que pegan un email y presionan Enter rápido son el caso difícil. Evita ralentizarlos. Muestra la sugerencia de inmediato, pero deja que Enter envíe con normalidad. Si necesitas una segunda oportunidad, muestra un pequeño aviso inline después del envío y antes de completar la creación de la cuenta, con dos acciones claras: “Usar email escrito” y “Usar email sugerido”.
Una regla simple: sugerir temprano, verificar siempre y nunca atrapar a los usuarios en un bucle donde no puedan continuar.
Una buena comprobación de typos hace una cosa bien: atrapa errores obvios como gmail.con y sugiere la corrección correcta, sin cuestionar en exceso a usuarios que escribieron algo inusual a propósito.
Comienza construyendo un conjunto pequeño y curado de dominios que estés dispuesto a sugerir. Incluye los grandes proveedores públicos (gmail.com, outlook.com, yahoo.com) y, si encaja con tu audiencia, los dominios de clientes que veas más a menudo (por ejemplo, si muchas inscripciones provienen de unas pocas empresas). Mantén la lista corta y revisada, porque cada dominio añadido aumenta la probabilidad de una sugerencia errónea.
A continuación, normaliza lo que el usuario escribió antes de comparar nada. Recorta espacios, divide en @, pon en minúsculas solo la parte del dominio y trata con cuidado los caracteres Unicode extraños (los usuarios pueden pegar letras que se parecen).
Aquí hay un flujo simple que funciona bien en la práctica:
@; si no hay @, no hagas nada.Un pequeño ejemplo en pseudocódigo:
if not hasAt(email): return
local, domain = split(email)
d = normalize(domain)
if d in knownDomains: return
best = closestByEditDistance(d, knownDomains)
if best.distance <= 2 and best.isUniqueWinner:
suggest(local + "@" + best.domain)
Sé conservador con los umbrales. Es mejor no detectar un typo raro a molestar a muchas personas con avisos constantes. Solo sugiere cuando la confianza sea alta, como hotnail.com → hotmail.com, no cuando varios dominios estén igualmente cerca.
Por último, mantén al usuario en control. Ofrece una elección clara como “Usar gmail.com” y “Mantener gmail.con”, y no bloquees el envío solo porque mostraste una sugerencia. Tu capa de validación (por ejemplo, una API de validación de correo como Verimail) puede ejecutarse por separado para atrapar dominios inválidos y direcciones desechables.
Una buena sugerencia de corrección se siente como un empujón útil, no como una recriminación. El objetivo es simple: ayudar a alguien a arreglar gmail.con o hotnail.com con un solo toque, sin interrumpir su flujo.
El patrón más limpio es una pista inline justo debajo del campo de correo. Mantenla corta y específica: “Did you mean gmail.com?” Añade una acción obvia como “Usar gmail.com” para que el usuario no tenga que reescribir nada. Esto funciona mejor tan pronto la dirección parece completa (tras escribir el dominio o al perder el foco), no tras cada pulsación.
Cuando hay más riesgo, añade un ligero paso de confirmación justo antes de enviar. Por ejemplo, cuando el usuario hace clic en “Crear cuenta”, muestra un pequeño mensaje inline cerca del campo de correo que presente ambas opciones: mantener lo escrito o cambiar al dominio sugerido. Esto reduce falsos positivos y evita la sensación de que el formulario “está tomando el control”.
Algunos detalles hacen que estos patrones resulten respetuosos:
Ejemplo: alguien escribe [email protected] en una inscripción de prueba. Una pista inline ofrece “Usar hotmail.com.” Sarah toca una vez, el campo se actualiza y continúa al campo de contraseña sin perder su lugar. Más tarde, aún puedes ejecutar una comprobación del lado servidor (por ejemplo con una API de validación de correo) para atrapar problemas más profundos, pero la ganancia de UX ocurre aquí.
La detección de typos en correo trata sobre cómo te diriges al usuario. El objetivo es ayudar, no culpar. Un tono neutral mantiene a la gente en movimiento: “Did you mean gmail.com?” funciona mejor que “Ese correo es incorrecto.” Si necesitas un tono más cuidado, prueba “Revisa el dominio: ¿quiso decir gmail.com?”
Muestra la diferencia exacta y enfócate solo en la parte que cambió. La mayoría de los errores está en el dominio, así que resalta solo ese segmento (por ejemplo, muestra name@ sin cambios y enfatiza visualmente gmail.con -> gmail.com). Esto reduce la confusión y hace que la corrección parezca segura.
Mantén los estados de sugerencia y error claramente diferenciados. Una sugerencia es una pista, no un fallo, por lo que debería verse más discreta que un error grave. Por ejemplo: una fila gris bajo el campo para sugerencias, y solo usa rojo cuando realmente bloqueas el envío (como falta de @, caracteres inválidos o un dominio imposible).
La accesibilidad requiere el mismo cuidado que lo visual. Los lectores de pantalla deberían anunciar tanto la sugerencia como la acción disponible. Un patrón simple es:
gmail.com?”gmail.com en su lugar”gmail.com”También asegúrate de que la sugerencia sea accesible por teclado (alcanzable con Tab, activable con Enter/Espacio) y que el foco no salte inesperadamente.
La localización es fácil de hacer mal. Traduce el texto circundante, pero no traduzcas el dominio en sí. gmail.com sigue siendo gmail.com en todos los idiomas. Si usas una API de validación como Verimail, mantén los mensajes del producto consistentes entre locales mientras dejas el dominio sugerido sin tocar.
Los typos son comunes, pero las sugerencias demasiado confiadas pueden ser peores que no hacer nada. Si tu formulario “corrige” una dirección real, arriesgas perder a un usuario que hizo todo bien.
Comienza siendo conservador con dominios que no conoces. Mucha gente usa correos de universidades, dominios de empresa o terminaciones más nuevas como .dev o .app. Si alguien introduce [email protected], eso no es “incorrecto” solo porque no lo hayas visto antes. Trata los dominios desconocidos como “no verificados aún”, no como “typo”.
Evita tocar la parte local (todo lo que está antes de @). Cambiar jane.smith a jane-smith o quitar puntos es adivinar. Solo sugiere ediciones de la parte local si tienes una regla clara y aprobada por el usuario en tu producto (por ejemplo, sabes que tu propio dominio ignora puntos). De lo contrario, mantén las sugerencias enfocadas solo en el dominio.
El plus-addressing es otro punto donde los equipos rompen direcciones válidas por accidente. Direcciones como [email protected] son válidas y se usan ampliamente para filtrado. Si tu sistema las soporta, no las adviertas, elimines o bloquees. Si no las soportas, explícalo claramente, porque los usuarios pueden depender de las etiquetas para reglas de bandeja.
Una regla práctica: sugiere, no fuerces. Buenos momentos para no sugerir incluyen:
Finalmente, siempre deja que la gente continúe con lo que escribió. Una opción clara como “Usar tal como está” evita frustraciones, especialmente cuando tu validador (por ejemplo, un servicio como Verimail) no puede confirmar la entregabilidad al instante pero el usuario sabe que la dirección es correcta.
La forma más fácil de hacer que la detección de typos parezca “inteligente” también es la más fácil para equivocarse: sugerir correcciones con demasiada frecuencia. Si tu umbral de coincidencia es demasiado flojo, molestarás a personas con direcciones correctas (especialmente dominios de trabajo). Mantén las sugerencias centradas en casos de alta confianza como dominios populares (gmail.com, outlook.com, yahoo.com) y ediciones muy pequeñas.
La autocorrección silenciosa es otra trampa clásica. Cambiar gmail.con a gmail.com sin avisar al usuario puede parecer útil, pero puede causar daños reales: los restablecimientos de contraseña van al buzón equivocado o un usuario piensa que se registró con una dirección distinta de la que almacenaste. Siempre pide confirmación cuando propongas una corrección.
Además, no confíes solo en las comprobaciones frontend. Una UI limpia aún puede aceptar basura si bots o clientes con script publican directamente a tu endpoint. Trata la sugerencia del navegador como una comodidad y aplica validación en el servidor también. Un flujo práctico es: sugerir en la UI y luego volver a comprobar en el servidor con sintaxis y comprobaciones de dominio/MX (y rechazar direcciones obviamente inválidas).
Para mantener esto bajo control, registra qué ocurre después de mostrar una sugerencia. Si no registras los resultados, no sabrás si tus reglas ayudan o dañan.
Por último, no confundas el manejo de typos con la detección de correos desechables. Una dirección desechable puede estar perfectamente escrita, y un typo puede ocurrir en un dominio no desechable. Trátalos como señales separadas con UI distinta.
Por ejemplo, hotnail.com probablemente es un typo que merece un suave “Did you mean hotmail.com?”. Pero mailinator.com no es un typo. Si lo bloqueas, dilo claramente. Si usas una API como Verimail, mantén estas decisiones separadas: sugerencias de typo para UX y detección de desechables para proteger la calidad de las inscripciones.
Antes de lanzar la detección de typos, haz una pasada rápida con dispositivos reales y hábitos reales de escritura. La mayoría de fallos vienen por pequeños detalles: cuándo aparece la sugerencia, qué ocurre al presionar Enter y si el servidor está de acuerdo con el navegador.
Usa esta lista para atrapar los problemas que suelen aparecer tras el lanzamiento:
gmail.con -> gmail.com) y evita adivinar en dominios de empresa poco comunes.Después de eso, añade analíticas para poder probar que la función ayuda en vez de adivinar. Captura, como mínimo: cuándo se muestra una sugerencia, cuándo se acepta, cuándo se descarta y qué correo se guarda al final (almacena de forma segura y considera registrar solo el dominio o un valor hasheado si no necesitas la dirección completa).
Una comprobación final de sentido común: escribe intencionalmente mal un dominio común, acepta la corrección y completa la inscripción. Luego hazlo de nuevo pero ignora la corrección. En ambos casos, el formulario debe sentirse calmado y predecible, y el correo guardado debe coincidir con la elección del usuario.
Un usuario empieza una prueba gratuita y escribe su correo rápido: [email protected]. A simple vista parece bien, pero es casi seguro que fallará después. El usuario envía, espera el correo de bienvenida y luego abre un ticket de soporte: “No lo recibí.”
Con detección de typos, el formulario detecta el error mientras el usuario aún está enfocado en el campo. Justo debajo del input aparece una nota inline (no un popup): “Did you mean [email protected]?” Junto a ella hay una sola acción como “Usar hotmail.com.”
El usuario toca una vez, el correo se actualiza en el campo y el cursor avanza como si nada hubiera pasado. Sin diálogo modal, sin salto de página, sin interrupción. Si la sugerencia está equivocada, el usuario puede ignorarla y continuar.
Una versión simple de la interacción se ve así:
Incluso con una sugerencia perfecta, el backend aún debe validar la dirección final antes de crear la cuenta. Por ejemplo, después de que el usuario acepte hotmail.com, tu servidor puede ejecutar comprobaciones completas (sintaxis, dominio, registros MX, detección de desechables y listas negras) usando una API de validación de correo como Verimail.
El resultado es práctico: menos correos de bienvenida rebotados, menos tickets de “No lo recibí” y menos usuarios de prueba perdidos por un pequeño typo.
Una vez que añades detección de typos, trátala como cualquier otro cambio de producto: mídela y ajústala según el comportamiento real. El objetivo es menos inscripciones fallidas y menos direcciones malas, sin bloquear a usuarios reales.
Empieza rastreando un conjunto pequeño de resultados que se conecten directamente con el dolor del usuario y el coste del negocio:
Luego itera tus reglas. Si los usuarios raramente aceptan una sugerencia, puede que sea demasiado agresiva (por ejemplo, sugerir gmail.com para muchos dominios poco comunes). Si la aceptan con frecuencia, amplía tu lista de dominios y ajusta umbrales (distancia de edición, letras intercambiadas, punto faltante) para coincidir con lo que ves en producción. Mantén una lista corta de permitidos, pero aprende también del tráfico propio.
Los typos son solo una capa. Para reducir fraude y proteger la entregabilidad, añade comprobaciones más profundas que confirmen que una dirección probablemente sea alcanzable: comprobaciones de sintaxis conforme a RFC, existencia de dominio y búsqueda de registros MX, y coincidencia con listas negras de proveedores desechables y trampas conocidas. En muchos productos también ayuda devolver banderas de riesgo en lugar de bloques duros cuando la confianza es baja.
Si quieres una opción de llamada única para estas comprobaciones durante el registro, Verimail (verimail.co) ejecuta sintaxis, dominio, MX y coincidencia con desechables/listas negras en milisegundos y devuelve un resultado claro con el que tu formulario puede actuar.