Detección de errores en direcciones de correo: corrige gmail.con antes de que los usuarios envíen

Por qué los errores en el correo rompen silenciosamente las inscripciones

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.

Los errores de correo más comunes que vale la pena capturar

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.

Dónde encaja la detección de typos en el flujo de registro

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:

• Al perder el foco (on blur): calmado y predecible para la mayoría de formularios.
• Tras una breve pausa al escribir (debounce de 300-500 ms): se siente instantáneo, pero puede ser ruidoso si está mal ajustado.
• Al enviar (on submit): la menor interrupción, pero los usuarios lo arreglan después, cuando ya se sienten “hechos”.

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.

Paso a paso: un algoritmo simple de sugerencia de typos

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:

• Extrae el dominio después de @; si no hay @, no hagas nada.
• Si el dominio ya es una coincidencia exacta en tu lista curada, no hagas nada.
• Calcula una puntuación de coincidencia cercana frente a cada dominio curado (distancia de edición es la elección común).
• Sugiere solo si hay un claro vencedor y la distancia es pequeña (por ejemplo, 1 o 2 ediciones).
• Muestra la sugerencia como una opción, no como una reescritura automática.

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.

Patrones de UX que corrigen errores sin molestar a la gente

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:

• Haz la sugerencia descartable (“Descartar”) y recuerda esa elección para la sesión para que no vuelva a aparecer.
• Evita modales para typos menores. Un modal es pesado y puede sentirse como un error, incluso cuando no estás seguro.
• Después de que el usuario acepta la corrección, mantén el foco predecible: el cursor debe permanecer en el campo de correo (o moverse al siguiente campo solo si ese es tu comportamiento normal).
• Si eligen mantener su entrada, no sigas sugiriendo a menos que el correo cambie.

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í.

Copia y accesibilidad que importan

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:

• Anunciar: “Sugerencia: ¿quiso decir gmail.com?”
• Proveer una etiqueta de acción: “Usar gmail.com en su lugar”
• Confirmar tras la activación: “Correo actualizado a 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.

Cuándo no sugerir una corrección

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:

• No tienes alta confianza (por ejemplo, falta solo un carácter pero hay muchas posibilidades)
• El dominio parece intencionalmente personalizado (empresa, escuela, interno)
• El usuario ha editado el correo dos veces y mantuvo el mismo valor
• Tu sugerencia requeriría cambiar la parte local

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.

Errores comunes y trampas a evitar

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.

• Registra: sugerencia mostrada, sugerencia aceptada, sugerencia ignorada, usuario editó manualmente
• Rastrea: dominios implicados, tasa de error por dominio y tasa de rebote posterior por cohorte
• Revisa: “falsas alarmas” frecuentes y añádelas a una lista de permitidos

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.

Lista rápida antes de lanzar

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:

• Solo muestra una sugerencia cuando estés muy seguro. Cíñete a correcciones de dominio de alta confianza (por ejemplo, gmail.con -> gmail.com) y evita adivinar en dominios de empresa poco comunes.
• Hacer que aceptar y descartar sea seguro. Si el usuario ignora la sugerencia, mantén exactamente lo que escribió. Si la acepta, cambia solo la parte del dominio y nunca borres el campo.
• Prueba los caminos rápidos en móvil y escritorio: pegar, autocompletar y pulsar Enter para enviar. La sugerencia no debe bloquear el envío ni desaparecer antes de que el usuario pueda actuar.
• Revisa accesibilidad. La sugerencia debe ser anunciada por lectores de pantalla y las acciones deben ser alcanzables por teclado con etiquetas claras.
• Haz que el comportamiento del cliente coincida con el del servidor. Si el navegador sugiere una corrección, tu backend aún debe validar el correo final enviado y manejar casos límite de la misma manera (sintaxis, existencia de dominio, MX). Si usas una API de validación como Verimail, confirma que las reglas y resultados del servidor coincidan con lo que vio el usuario.

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.

Ejemplo: corregir un typo en la inscripción de una prueba en la vida real

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í:

• Mostrar la sugerencia solo después de que el usuario termine de escribir (on blur) o haga una breve pausa
• Hacer la corrección con un solo toque y reversible (deshacer o “x” para descartar)
• Mantener el mensaje calmado: “Did you mean…” en lugar de “Correo inválido”

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.

Siguientes pasos: medir resultados y endurecer la validación

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:

• Tasa de finalización de inscripción (¿más gente completó el formulario?)
• Tasa de rebote del correo de bienvenida (¿menos correos fallaron?)
• Tasa de correos confirmados (¿más personas verificaron con éxito?)
• Contactos de soporte por login o correos faltantes (¿disminuyó la confusión?)
• Tasa de aceptación de la corrección (¿con qué frecuencia aceptan tu sugerencia?)

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.