Verificación de emails en masa: cómo limpiar la lista antes de enviar

Lo esencial Un verificador de emails en masa pasa cada fila por una batería de comprobaciones (el formato, los registros de correo, una conversación SMTP real, las listas de direcciones genéricas y de dominios desechables) y te devuelve una palabra por fila. Esa palabra esconde algo bastante más enrevesado. Una sola pasada SMTP es una muestra, no un veredicto. El greylisting está hecho para contestar «vuelve más tarde» (RFC 6647), Gmail responde 421 4.7.28 cuando el volumen le parece raro y los servidores que lo aceptan todo dicen que sí a cualquier cosa. Enrow somete cada dirección a más de 10 verificaciones, con varias pasadas SMTP y varias comprobaciones de catch-all desde servidores en regiones distintas. Las filas que casi todas las herramientas tiran a la basura sin decírtelo son las catch-all. Se marcan como «risky», se descartan y adiós. Enrow las verifica y te las entrega como válidas. Amazon SES pone la cuenta en revisión con un 5 % de bounce y puede suspender los envíos con un 10 %. Una lista verificada no se acerca ni de lejos a ninguna de las dos cifras. Verificar cuesta 0,25 créditos en Enrow, de modo que los 50 créditos gratis de cada mes dan para 200 comprobaciones.

Verificar emails en masa consiste en pasar un fichero entero por un verificador antes de usarlo en una campaña. Subes un CSV, te lo devuelve con un estado en cada fila y borras las malas. Casi todo el mundo deja de leer ahí, y justo ahí se te va el dinero.

A esa palabra de estado se le pide muchísimo. Detrás de «valid» hay una conversación con un servidor de correo que puede haber dicho la verdad o no. Detrás de «risky» hay un dominio que dice que sí a todo, y eso no es lo mismo que una dirección mala. Y detrás de «unknown» hay, muchísimas veces, un servidor que se negó a hablar con la máquina que preguntaba.

Los estados te van a llegar en inglés en casi cualquier herramienta del mercado. Los dejo tal cual a lo largo del artículo, porque es lo que vas a leer en tu CSV.

Qué comprueba un verificador de emails en masa, capa por capa

La validación se hace en seis capas. Las dos primeras son baratas y rápidas; en las demás es donde se ve la diferencia entre un verificador y otro.

1. Sintaxis

¿La cadena es una dirección bien formada? El RFC 5321 §4.5.3.1 fija los límites: 64 octetos para la parte local, 255 para el dominio, 256 para la ruta completa. Esta capa pilla también los errores tontos que se cargan una campaña: el espacio de más al final, el .con en lugar de .com.

Sobre la entrega, en cambio, no dice nada. postmaster@, con cualquier dominio detrás, pasa todas las expresiones regulares que se hayan escrito jamás, y el RFC 5321 obliga a toda implementación de SMTP a aceptar ese buzón. Perfectamente válido, perfectamente inútil para prospectar.

2. Dominio y registros MX

El verificador consulta los registros MX del dominio, los que dicen qué servidor recibe su correo. Sin registros no hay correo. La pega es que el estándar hila más fino, y un verificador decente lo respeta. RFC 5321 §5.1: «si se devuelve una lista vacía de MX, la dirección se trata como si estuviera asociada a un registro MX implícito, con preferencia 0, que apunta a ese host». Un dominio sin MX pero con un registro A que funciona no está muerto sin más. Aun así, los servidores de envío actuales rechazan esos dominios, con lo cual la ausencia de MX vale como señal de aviso y no como veredicto de dirección inválida.

3. La conversación SMTP

Esta es la comprobación que cuenta. El verificador abre una conexión con el servidor de destino y da los primeros pasos de una entrega: se identifica, declara un remitente, nombra al destinatario con RCPT TO. Luego lee la respuesta y para. No llega a entregarse ningún mensaje.

SMTP tiene un comando pensado justo para esto, VRFY, y en la práctica no sirve. El RFC 5321 §3.5.2 permite que un servidor responda 252 (no puedo verificar, pero acepto e intentaré entregar) en lugar de confirmar nada, y el §7.3 deja que cada instalación desactive el comando sin más. La mayoría de los servidores públicos se acogieron a esa opción hace años, y por eso los verificadores sondean con RCPT TO y leen los códigos de respuesta.

Hay dos familias de códigos que importan (RFC 5321 §4.2.1). Una respuesta 5yz es permanente: no reintentes. Una 4yz es transitoria: reintenta más tarde. El 550 5.1.1 de Gmail es la respuesta clara de un buzón muerto, «The email account that you tried to reach does not exist», es decir, la cuenta no existe. Su 452 4.2.2 significa buzón lleno: alguien de carne y hueso con la bandeja hecha un desastre, no una dirección inválida.

Un verificador que lee un 4yz como inválido se equivoca. Si lo lee como válido, también. Casi todo el oficio está en gestionar esa ambigüedad.

4. Direcciones genéricas

sales@, support@, info@, abuse@, webmaster@. Existen, reciben correo y están normalizadas desde 1997 por el RFC 2142, Mailbox Names for Common Services, Roles and Functions. Van a un buzón compartido que leen varias personas. O nadie.

Los verificadores las marcan aparte porque entregabilidad y utilidad son dos preguntas distintas. Una dirección genérica es válida de pleno derecho, y también el camino más corto hacia una queja por spam si la secuencia está escrita para una persona con nombre y apellidos.

5. Dominios desechables

Servicios de buzón temporal, los que usa la gente para apuntarse a una prueba gratis. Aquí la detección se hace con una lista de bloqueo, no con un protocolo, y la referencia pública de facto es el repositorio disposable-email-domains. Sus mantenedores lo dicen sin rodeos: «no podemos garantizar que todos estos sigan considerándose desechables». Importa muchísimo en los formularios de registro y bastante menos en el cold email B2B.

6. Detección de catch-all

El verificador le presenta al servidor una dirección que no puede existir de ninguna manera. Si también la da por buena, el dominio lo acepta todo y su respuesta sobre tu dirección real no valía nada. De esta capa depende cuánto se salva de tu lista.

Por qué dos verificadores discrepan sobre la misma dirección

La misma dirección sale «unknown» tras una sonda y «valid» tras más de 10 verificaciones.

Pasa una dirección por dos herramientas y a veces te salen dos respuestas distintas. Ninguno de los dos proveedores miente. Una sola pasada SMTP es una medida tomada por un canal con ruido, y ese ruido tiene nombre propio.

El greylisting es el que más ruido mete, y el RFC 6647 lo describe sin adornos. Cuando un remitente desconocido llama a la puerta por primera vez, el servidor devuelve un 421, cierra la conexión, apunta la terna IP, remitente y primer destinatario, y acepta el mensaje en un intento posterior. El propio RFC reconoce el coste: «el perjuicio más evidente de implantar greylisting es imponer un retraso al correo legítimo». Un verificador que sondea una sola vez ve el aplazamiento y tiene que adivinar.

El volumen dispara otra alarma distinta. La respuesta la publica el propio Google: 421 4.7.28, «Gmail has detected an unusual rate of email. To protect our users from spam, email has been temporarily rate limited», es decir, ha visto un ritmo de correo inusual y lo ha limitado temporalmente. Una herramienta que comprueba miles de direcciones alojadas en Gmail desde un puñado de IP se estampa contra ese muro, y todo lo que venga después se queda sin resolver. También cuenta quién pregunta. Las directrices para remitentes de Google exigen un registro DNS inverso válido en la IP de envío y una resolución directa que coincida, y a una sonda que sale de una IP sin ese registro la echan mucho antes de que llegue a preguntar por el buzón.

El tercer foco de ruido son los dominios que lo aceptan todo. Microsoft 365 rechaza a los destinatarios desconocidos en el RCPT TO con un 550 5.4.1 cuando el tenant tiene activado el Directory-Based Edge Blocking. Cuando esa función no está activa, la respuesta del tenant da muchísima menos información y el verificador se queda sin nada sólido en lo que apoyarse. Ahí está, en la práctica, el origen del problema de las catch-all en los dominios B2B europeos.

Por eso Enrow no se conforma con una sola pasada. Cada dirección se somete a más de 10 verificaciones, con varias pasadas SMTP y varias comprobaciones de catch-all desde servidores en regiones distintas, y el veredicto sale de las diferencias entre esas respuestas, incluida la forma en que el dominio trata una dirección de control que no ha visto nunca.

Con una sola sonda te llevas un aplazamiento y poco más. Con varias, desde regiones distintas y contra una dirección de control, sacas un veredicto.

El problema de las catch-all y las oportunidades que te hace perder

Un dominio que lo acepta todo se queda con el correo enviado a cualquier dirección. jane.doe@, jne.doe@, loquesea@. Todo se acepta, y luego se tira internamente o se devuelve horas después, con la conexión ya cerrada.

La mayoría de los verificadores llega ahí y se para. Marcan la fila como «catch-all» o «risky» y la decisión te la dejan a ti. ZeroBounce deriva las catch-all sin resolver a un producto de puntuación distinto, y reconoce en su propia página que «no puedes confirmar si la dirección pertenece a una persona real» (fuente).

Entonces el dueño de la lista hace una de dos cosas, a cuál peor. Borra el segmento y pierde por el camino cientos de decisores reales. O le envía tal cual y se come los bounces. En mis propios ficheros, el montón de «risky» es con frecuencia el segundo segmento más grande, solo por detrás de los válidos, y en algunas listas ha llegado a un tercio de las filas. Demasiadas para borrarlas a ojo.

Las catch-all se pueden resolver desde fuera, solo que no con una única sonda. Conversaciones SMTP repetidas desde orígenes distintos, a horas distintas, medidas contra direcciones de control falsas a propósito, dan una señal que una comprobación única no da. Enrow las resuelve por esa vía y te las devuelve como válidas, no como avisos. Hay dominios que no ceden nunca, y lo honesto es dejar esas filas fuera. Quedan muchas menos sin resolver que con una herramienta de una sola pasada. Pero no cero. El mecanismo completo está en qué es un email catch-all.

Cómo saber si un email es válido: verificar una dirección suelta

Para verificar una sola dirección, pégala en una herramienta que haga comprobaciones SMTP reales y no se limite a comparar formatos. Lo que buscas es algo que sepa distinguir «el servidor ha dicho que no» de «el servidor no ha querido decirlo». Una que te devuelva válido o inválido sin tercera categoría y sin tratamiento de las catch-all suele ser una comprobación de sintaxis y MX disfrazada de verificador. Hacerlo a mano es peor: hacer telnet al puerto 25 desde la IP de la oficina te lleva al greylisting o a un bloqueo en unas pocas decenas de intentos, y los scripts de GitHub que automatizan ese diálogo heredan todos los problemas que acabamos de ver.

Verificación en masa, paso a paso

Para limpiar listas grandes, el orden importa más que la herramienta.

1. Normaliza y deduplica primero. Quita los espacios sobrantes, pon los dominios en minúscula, elimina los duplicados y a la misma persona repetida con dos alias. Pagas por dirección comprobada, así que este paso te ahorra dinero sin ningún esfuerzo.
2. Saca las direcciones genéricas a su propia pestaña antes de subir nada. El RFC 2142 te da la lista de patrones. Salen como válidas y te arruinan una secuencia personalizada.
3. Sube el CSV. El Email Verifier de Enrow se traga un fichero de miles de filas y devuelve un estado en cada una; el mismo motor responde dirección a dirección a través de la API, o desde el servidor MCP oficial (github.com/EnrowAPI/enrow-mcp) cuando el proceso se lleva desde un asistente de IA.
4. Parte el fichero por estado en lugar de filtrarlo. Una fila borrada ya no se puede revisar.
5. Envía al segmento limpio y luego mira los bounces por dominio de destino, no por campaña. Cinco bounces repartidos por todo un envío son ruido; cinco en el dominio de una misma empresa quieren decir que los datos de esa empresa están mal.
6. Vuelve a verificar antes del siguiente envío. Nada de reutilizar el mismo fichero tres meses después.

Con listas europeas, el tratamiento se apoya normalmente en el artículo 6.1 f) del RGPD, el interés legítimo, y el considerando 47 incluye el marketing directo entre los intereses legítimos. Los considerandos orientan la interpretación, pero no son vinculantes.

Qué significa cada estado y qué hacer con la fila

Qué tasa de bounce es segura antes de darle a enviar

Una lista verificada queda por debajo del 1 %, muy lejos del precipicio que marca SES.

Hay una cifra, sacada directamente de la fuente, que merece la pena recordar. Amazon SES: «si tu tasa de bounce es del 5 % o superior, ponemos automáticamente tu cuenta en revisión. Si tu tasa de bounce es del 10 % o superior, podemos suspender la posibilidad de que tu cuenta siga enviando correo». SES cuenta solo los hard bounces.

Ese 5 % es el borde del precipicio, no un objetivo. El techo de trabajo habitual, sea cual sea el remitente, está en el 2 %, y en cold email lo suyo es quedarse por debajo del 1 %, que es justo lo que da una lista verificada. En mis listas, las direcciones encontradas y verificadas con Enrow tienen una tasa de bounce inferior al 1 %: es una media constatada en envíos reales, no una garantía, y nadie te va a devolver dinero por ella.

Hay un número que se cita mal una y otra vez. El 0,3 % de Google es una tasa de quejas por spam, no de bounce: los remitentes que mandan más de 5.000 mensajes al día a Gmail tienen que mantener la tasa de spam de Postmaster Tools por debajo del 0,3 %, y por encima del 0,1 % la llegada a la bandeja de entrada ya se resiente. Google no publica ningún umbral de bounce. Lo desmenuzamos en el artículo sobre la tasa de bounce.

Cuánto cuesta verificar una lista entera

Verificar en Enrow cuesta 0,25 créditos por dirección, que salen de la misma bolsa de créditos que usas para buscar:

El plan gratuito da 50 créditos cada mes, sin tarjeta, y se renuevan: 200 verificaciones al mes, para siempre.

Compara como toca. Hunter cobra 0,5 créditos por email verificado, frente a los 0,25 de Enrow. En el nivel mensual de 10.000 créditos eso son 149 € por 20.000 verificaciones, 0,00745 € cada una, frente a los 75 € de Enrow por 40.000, a 0,001875 €: cerca de 4 veces más por dirección comprobada. En anual y al mismo volumen: 0,0052 € frente a 0,0017 €, unas 3,1 veces más. Esas cifras son de Hunter, que publica en euros; no he convertido nada.

ZeroBounce regala 100 créditos al mes y descuenta un crédito por validación, de modo que su suscripción ONE, a 99 $ al mes, cubre 10.000 comprobaciones a 0,0099 $ cada una. Publica en dólares y prefiero dejarle su divisa antes que inventarme un tipo de cambio; tampoco hace falta ninguno para ver la diferencia. Esas mismas diez mil comprobaciones en Enrow son 2.500 créditos, y caben dentro del nivel Start 4k de 42 €, que en realidad da para 16.000, a 0,0026 € la verificación. Mensual frente a mensual, con la misma base. Eso sí, ese plan de ZeroBounce trae de serie herramientas para medir la llegada a la bandeja de entrada y vigilar las listas negras, que Enrow no vende, así que no todo lo que pagas es verificación.

La pega de Enrow, para ser justos: los créditos son compartidos. Una tanda de 40.000 verificaciones en Pro es el presupuesto del mes entero, y de ahí no sale ni un contacto nuevo. Decide el reparto antes de subir el fichero, o la limpieza se comerá los créditos de búsqueda.

Lo que la verificación no puede hacer

No resucita un buzón muerto.

Es el límite que ningún vendedor de verificación reconoce en voz alta. Sobre una lista montada hace un año o dos, el trabajo de un verificador es contarte cuánto se ha perdido por el camino, y en un fichero viejo la parte perdida va a ser grande. La gente cambia de trabajo, los dominios acaban absorbidos por el de la empresa compradora, los alias se dan de baja. Ningún proveedor recupera esas filas, y una herramienta que te devuelve un porcentaje de válidos sospechosamente alto sobre una lista vieja está retratando su propia manga ancha, no tus datos.

La verificación demuestra una sola cosa: que hoy ese buzón acepta correo. Ni que lo lea una persona ni que esa persona siga en el cargo que figura en tu CRM. Eso ya es trabajo de búsqueda: cómo encontrar el email de alguien.

Enrow tiene dos límites, y los dos son deliberados. No hay una base de datos que puedas consultar: funciona en tiempo real, y por eso el dato no llega caducado; montar la lista es cosa de LinkedIn o Sales Navigator. Y no envía nada: las campañas son terreno de Emelia, La Growth Machine o lemlist. Lo que sí hace y no iguala ningún rival: desde un perfil de LinkedIn, la Chrome extension mete la ficha de contacto verificada entera, con todos sus campos, en HubSpot, Salesforce o Pipedrive con un solo clic.

FAQ

¿Cómo puedo saber si una dirección de email es válida?

Usa un verificador que haga una comprobación SMTP real y no se limite a comparar formatos: sintaxis, registros MX, una sonda RCPT TO y las listas de direcciones genéricas y de dominios desechables. Un rechazo permanente 5yz significa que el buzón está muerto. Un 4yz transitorio significa que el servidor ha aplazado la respuesta y que hay que repetir la comprobación por otra vía. Si el dominio lo acepta todo, ninguna sonda aislada puede darte la respuesta y necesitas una herramienta que resuelva las catch-all.

¿Cómo verifico emails en masa?

Normaliza y deduplica el fichero, mueve las direcciones genéricas tipo sales@ a su propio segmento, sube después el CSV y parte los resultados por estado en lugar de filtrar filas y perderlas. Envía a las direcciones válidas, guarda las catch-all para una herramienta que las resuelva, borra definitivamente las inválidas y vuelve a verificar antes de la siguiente campaña.

¿Por qué dos verificadores dan respuestas distintas para la misma dirección?

Porque una pasada SMTP es una muestra. El greylisting (RFC 6647) contesta 421 en el primer contacto de un remitente desconocido, Gmail frena los sondeos masivos con un 421 4.7.28, la reputación de la IP que pregunta cambia la respuesta y los servidores que lo aceptan todo dicen que sí pase lo que pase. Además, cada proveedor pone la frontera entre válido y dudoso en un sitio distinto. La solución es repetir: Enrow somete cada dirección a más de 10 verificaciones, con varias pasadas SMTP y varias comprobaciones de catch-all desde servidores en regiones distintas.

¿Qué significa «catch-all» en mis resultados y debo borrar esas filas?

El dominio acepta correo dirigido a cualquier dirección, incluida una que se ha inventado el verificador, así que su respuesta sobre la tuya no aporta información. Borrar ese segmento es el error que sale caro: en mis listas suele ser el segundo montón más grande y ha llegado a un tercio de las filas. Verifícalo con comprobaciones repetidas desde varias regiones; las que se resuelven vuelven a la lista y el resto se queda fuera.

¿Qué tasa de bounce es segura antes de darle a enviar?

Amazon SES pone la cuenta en revisión en el 5 % y puede suspender los envíos en el 10 %, contando solo los hard bounces. Trabaja con un techo del 2 % y procura quedarte por debajo del 1 % en cold email, que es lo que da una lista verificada. No lo confundas con el 0,3 % de Google, que es una tasa de quejas por spam y una métrica completamente distinta.

¿Cuál es el mejor verificador de emails gratis?

Busca un plan gratuito que se renueve en vez de una prueba de un solo uso, y que haga comprobaciones SMTP reales en lugar de limitarse a validar la sintaxis. Enrow da 50 créditos gratis cada mes, sin tarjeta: 200 comprobaciones al mes a 0,25 créditos cada una, con el mismo motor que usan los clientes de pago y con las catch-all incluidas.

La palabra del estado no es la respuesta. La respuesta es el método que hay detrás. Limpia tu próxima lista con Enrow: más de 10 verificaciones por dirección, catch-all resueltas en vez de marcadas y olvidadas, y 50 créditos gratis cada mes.