Errores de escritura en correos al registrarse: gmial.com y más

Para detectar errores de escritura en correos al registrarse, compara el dominio que escribió el usuario con una lista corta de proveedores populares usando una distancia de edición que cuente las letras intercambiadas como una sola edición, y muestra "Did you mean jane@gmail.com?" (¿Quisiste decir jane@gmail.com?) al salir del campo. Nunca corrijas automáticamente. Los dominios con errores de escritura a menudo aceptan correo, así que la verificación sola no los detecta.

Ese último punto es la razón de este artículo. La mayoría de los consejos tratan un dominio mal escrito como un rebote futuro. Lo revisamos, y para una buena parte de los errores comunes no lo es.

Qué pasa realmente con el correo enviado a un dominio con error

De 37 dominios con errores comunes que revisamos, 20 pueden recibir correo: 13 publican registros MX y 7 tienen un registro A al que el correo puede recurrir como respaldo. El correo a esos dominios no rebota de forma confiable. Llega a quien sea dueño del dominio.

Elegimos los errores que aparecen en las librerías de sugerencias de errores y en nuestra propia experiencia (letras transpuestas, una letra omitida, una letra duplicada, .co y .con en lugar de .com) para Gmail, Yahoo, Hotmail, Outlook, iCloud y AOL. Luego ejecutamos dig para los registros MX y A de cada uno desde una conexión residencial en EE. UU. el 1 de octubre de 2026. Los resultados en bruto, incluido cada host MX, están en nuestro archivo de investigación.

Lo que devolvió el DNS	Cantidad	Qué pasa con un mensaje	Ejemplos
Registros MX que apuntan a un servidor de correo	13	Se entrega a ese servidor, si lo acepta	gmai.com, gamil.com, hotmial.com, outlok.com, iclod.com, aoll.com
Sin MX, pero con registro A	7	Los remitentes recurren al registro A ("MX implícito")	gmial.com, gmali.com, yaho.com, hotmal.com, ail.com
MX nulo (0 .)	7	Rechazado; el dueño declaró que no recibe correo	gmail.co, gmail.cm, yahooo.com, yahoo.co, aol.co
El dominio no existe	6	Rebota de inmediato	gmail.con, yahoo.con, hotmail.con, outlook.con
Sin MX y sin registro A	3	No hay ruta; rebota	gmal.com, gmaill.com, hotmail.co
Falla de DNS (SERVFAIL)	1	Falla temporal, se reintenta y al final rebota	icloud.co

Vale la pena conocer tres detalles de los datos en bruto.

Algunos proveedores registraron sus propios errores y desactivaron el correo. gmail.co, cuyo registro WHOIS indica a Google LLC como titular, publica un registro MX nulo según lo define el RFC 7505. Lo mismo hacen yahooo.com, yhoo.com, yahho.com y yahoo.co. Estos son el caso bueno: el mensaje se rechaza y un verificador marcará la dirección como inválida.

Tres dominios con errores comparten un mismo servidor de correo. gmai.com, hotmial.com y outlok.com indican mail.h-email.net como su MX. No afirmamos nada sobre quién lo opera ni por qué; el punto es que el correo dirigido a tres errores distintos de tres proveedores distintos tiene a dónde ir.

.con es el error seguro. No es un dominio de nivel superior, así que toda dirección .con falla en el DNS y rebota de inmediato. Los errores peligrosos son los que están en medio del nombre, porque esos son dominios .com que se pueden registrar.

Por qué la verificación no resuelve esto

La verificación detecta los 17 dominios con errores que no pueden recibir correo, pero puede dar por buenos los otros 20, porque desde afuera se ven como el dominio de cualquier empresa pequeña.

Un dominio con error que tiene un MX funcionando pasa una comprobación de DNS. Si su servidor acepta todas las direcciones, un catch-all, una comprobación SMTP no puede distinguir jane@ de cualquier otro nombre. Un verificador cuidadoso lo reporta como riesgoso en lugar de válido, pero "riesgoso" en un formulario de registro no le dice al usuario qué hizo mal.

También probamos una sonda SMTP, preguntándole a cada servidor con ruta de correo si aceptaría una dirección aleatoria e inventada en su dominio. La mayoría de los 19 servidores que probamos se negaron a hablar con una IP residencial, agotaron el tiempo de espera o se desconectaron, así que la mayoría de los resultados no fueron concluyentes. Eso es normal al sondear desde una conexión doméstica y es la razón por la que no sacamos conclusiones de ellos. Dos vale la pena reportarlos: hotmil.com (atendido por mail.yaxmail.net) y aoll.com (cuyo MX es de Google) respondieron 250 para una dirección que no puede existir. El correo a cualquier nombre en esos dominios se acepta.

La consecuencia práctica: un error de escritura que llega a uno de estos dominios nunca vuelve a ti como rebote. Simplemente nunca vuelves a saber de ese usuario, y otra persona podría recibir su restablecimiento de contraseña o su confirmación de pedido. Eso es tanto un problema de privacidad como de entregabilidad.

Cómo sugerir correcciones

Compara el dominio escrito con una lista de proveedores populares, sugiere solo cuando haya exactamente un candidato muy cercano y deja en paz los dominios reales.

El detalle que la mayoría de las implementaciones hace mal es la medida de distancia. La distancia de Levenshtein simple cuenta de gmial a gmail como dos ediciones (dos sustituciones), lo que obliga a usar un umbral más laxo y genera más falsos positivos. La variante de alineación óptima de cadenas (optimal string alignment) de Damerau-Levenshtein cuenta la transposición de dos letras vecinas como una sola edición, que es como la gente realmente se equivoca al escribir.

Esta función no tiene dependencias. La ejecutamos contra los 37 dominios con errores de arriba y 11 dominios reales que están cerca de los objetivos.

const TARGETS = [
  "gmail.com", "googlemail.com", "yahoo.com", "hotmail.com", "outlook.com",
  "live.com", "icloud.com", "me.com", "aol.com", "proton.me", "protonmail.com",
  "gmx.com", "hotmail.co.uk", "yahoo.co.uk", "btinternet.com",
];
const LEAVE_ALONE = new Set([
  ...TARGETS, "mail.com", "ymail.com", "aim.com", "mac.com", "msn.com",
  "live.co.uk", "gmx.de", "gmx.net", "web.de", "pm.me", "hey.com",
]);

function editDistance(a, b) {
  const d = Array.from({ length: a.length + 1 }, (_, i) => [i, ...Array(b.length).fill(0)]);
  for (let j = 1; j <= b.length; j++) d[0][j] = j;
  for (let i = 1; i <= a.length; i++) {
    for (let j = 1; j <= b.length; j++) {
      const cost = a[i - 1] === b[j - 1] ? 0 : 1;
      d[i][j] = Math.min(d[i - 1][j] + 1, d[i][j - 1] + 1, d[i - 1][j - 1] + cost);
      if (i > 1 && j > 1 && a[i - 1] === b[j - 2] && a[i - 2] === b[j - 1]) {
        d[i][j] = Math.min(d[i][j], d[i - 2][j - 2] + 1);
      }
    }
  }
  return d[a.length][b.length];
}

export function suggestDomain(email) {
  const at = email.lastIndexOf("@");
  if (at < 1) return null;
  const domain = email.slice(at + 1).trim().toLowerCase();
  if (LEAVE_ALONE.has(domain)) return null;

  const scored = TARGETS
    .map((candidate) => ({ candidate, distance: editDistance(domain, candidate) }))
    .filter(({ candidate, distance }) => distance <= (Math.min(domain.length, candidate.length) <= 7 ? 1 : 2))
    .sort((x, y) => x.distance - y.distance);

  if (scored.length === 0) return null;
  if (scored.length > 1 && scored[0].distance === scored[1].distance) return null;
  return `${email.slice(0, at)}@${scored[0].candidate}`;
}

Resultados de nuestra prueba:

Conjunto de entrada	Resultado
Los 37 dominios con errores de la tabla de arriba	37 sugerencias correctas (por ejemplo yaho.com a yahoo.com, ail.com a aol.com, icloud.co a icloud.com)
acme.com, stripe.com, gmx.com, gmx.de, me.com, mail.com, ymail.com, aim.com, mac.com, live.co.uk, hotmail.co.uk	Ninguna sugerencia, lo cual es correcto

La primera versión que escribimos no tenía LEAVE_ALONE ni el umbral más estricto para dominios cortos. Sugería me.com para acme.com, gmail.com para mail.com y ymail.com, aol.com para aim.com y me.com para mac.com. Todos esos son dominios reales con usuarios reales. Los dominios cortos necesitan un umbral más estricto, y los proveedores reales que están cerca de tus objetivos tienen que listarse explícitamente. Si tu audiencia es regional, agrega sus proveedores a ambas listas: web.de y gmx.de para Alemania, btinternet.com y las variantes .co.uk para el Reino Unido, y así sucesivamente.

Dos reglas hacen que sea seguro publicarlo:

1. Abstente en los empates. Si dos objetivos están igual de cerca, no muestres nada en lugar de adivinar.
2. Sugiere, nunca corrijas. La función devuelve un texto para que lo muestres, no un reemplazo.

Lo que encontramos al probar Mailcheck

Mailcheck (unas 7,900 estrellas en GitHub cuando lo revisamos) es una librería de código abierto con mucha trayectoria para esto, pero la versión en npm y el código en GitHub se comportan distinto, y cada uno hizo una sugerencia equivocada que el otro no hizo.

Cuando lo revisamos el 1 de octubre de 2026, el repositorio se había actualizado en septiembre de 2026 y su package.json decía 1.1.2, pero la versión más reciente en el registro de npm era la 1.1.1, publicada en julio de 2015. Ejecutamos ambas con las mismas entradas.

Entrada	npm 1.1.1	GitHub master
jane@gmial.com, jane@hotmial.com, jane@gmail.con	Sugerencia correcta	Sugerencia correcta
jane@gmail.co	Sugiere gmail.com	Ninguna sugerencia
jane@acme.com	Sugiere me.com	Ninguna sugerencia
jane@yaho.com	Sugiere yahoo.com	Sugiere aol.com
jane@outloo.com	Sugiere outlook.com	Sugiere icloud.com

El README en master deja claro que .co se deja en paz a propósito ("sample@gmail.co receives no suggestion because .co is real", es decir, no recibe sugerencia porque .co es real) y describe la librería como "a typo suggester, not an email validator or a deliverability check" (un sugeridor de errores de escritura, no un validador de correo ni una comprobación de entregabilidad). Estamos de acuerdo con ambas posturas. Pero, dados nuestros resultados de DNS, gmail.co es un caso en el que sugerir es lo correcto: .co es un TLD real, pero ese dominio en particular no acepta correo.

Nada de esto hace de Mailcheck una mala elección. Sí significa que debes instalar una versión específica, probarla con tus dominios principales y sus errores comunes, y revisar qué sugiere para dominios reales cercanos a tus objetivos.

La interfaz

Muestra la sugerencia cuando el campo pierde el foco, como un botón que la aplica, dentro de una región dinámica (live region) para que los lectores de pantalla la anuncien.

<input id="email" type="email" autocomplete="email">
<p id="email-hint" role="status" hidden></p>

import { suggestDomain } from "./suggest.mjs";

export function attachTypoHint(input, hint) {
  input.addEventListener("blur", () => {
    const suggestion = suggestDomain(input.value.trim());
    hint.hidden = !suggestion;
    if (!suggestion) return;
    hint.replaceChildren("Did you mean ");
    const button = hint.ownerDocument.createElement("button");
    button.type = "button";
    button.textContent = suggestion;
    button.addEventListener("click", () => {
      input.value = suggestion;
      hint.hidden = true;
      input.focus();
    });
    hint.append(button, "?");
  });
}

Lo probamos en jsdom: al salir del campo con jane@hotmial.com se mostró "Did you mean jane@hotmail.com?", al hacer clic en el botón se reemplazó el valor y se ocultó la sugerencia, y jane@acme.com no mostró nada.

Algunas decisiones que importan:

• Al salir del campo, no con cada tecla. Sugerir gmail.com mientras alguien va a la mitad de escribir gmail.com es ruido.
• textContent, no innerHTML. La sugerencia incluye lo que el usuario escribió antes de la @, así que construye los nodos del DOM en lugar de concatenar HTML.
• Nunca bloquees el envío. Si ignoran la sugerencia, envía lo que escribieron.
• type="email" y autocomplete="email" permiten que los navegadores ofrezcan la dirección guardada del usuario y muestren un teclado de correo en los teléfonos, lo que evita muchos errores antes de que ocurran.

Dónde encaja esto con las demás comprobaciones

Una sugerencia de error corrige una equivocación que el usuario todavía puede arreglar; todo lo que viene después del envío solo puede rechazar o marcar.

El orden que funciona en un formulario de registro:

1. Sintaxis, en el navegador y otra vez en el servidor. Consulta por qué falla el regex para correos.
2. Sugerencia de errores al salir del campo, como arriba.
3. DNS en el servidor, que rechaza los dominios .con, con MX nulo y los dominios con errores muertos. El código para eso está en validar correos en JavaScript y Node.js.
4. Un correo de confirmación, que es la única comprobación que demuestra que la persona escribió su propia dirección. Las ventajas y desventajas están en doble opt-in vs. verificación de correo.

Si estás limpiando una lista existente en lugar de un formulario, la misma función de distancia de edición funciona sin conexión: ejecútala sobre la columna de dominios y revisa cada sugerencia a mano antes de cambiar nada.

La conclusión práctica

• Los errores en medio del nombre de un proveedor (gmial, hotmial, outlok) a menudo caen en dominios que pueden recibir correo. No rebotan, así que no los vas a encontrar en tus registros de rebotes.
• Usa una distancia de edición que trate un intercambio de letras vecinas como una sola edición, abstente en los empates y mantén una lista explícita de dominios reales que nunca se deben corregir.
• Sugiere; no corrijas automáticamente.
• Prueba cualquier librería que uses con dominios reales cercanos a tus objetivos. Encontramos sugerencias equivocadas tanto en la versión de npm como en la versión de GitHub de Mailcheck.
• Para ver qué devuelve un dominio en particular, pásalo por la herramienta gratuita de consulta MX.