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 pila de comprobaciones (el formato, los registros de correo, una conversación SMTP real, las listas de direcciones de función y de dominios desechables) y te da una palabra por fila. Esa palabra esconde una realidad mucho más enrevesada. Una sola pasada SMTP es una muestra, no un veredicto. El greylisting contesta «vuelve más tarde» por diseño (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 una 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, recibes cada fila con su estado y borras las malas. Casi todo el mundo deja de leer ahí, y justo ahí es donde se pierde dinero.

Esa palabra de estado resume muchísimas cosas. 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, que 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; es en las demás donde los verificadores empiezan a diferenciarse.

1. Sintaxis

¿La cadena tiene un formato de dirección válido? 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 también detecta los errores tontos que se cargan una campaña: el espacio de más al final o el .con en lugar de .com.

De la entrega no dice nada. postmaster@ pasa cualquier expresión regular que se haya escrito jamás, con cualquier dominio, 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 por definición. Aun así, los remitentes modernos rechazan esos dominios, así que la ausencia de MX sirve como señal de alerta, no como prueba de que la dirección es inválida.

3. La conversación SMTP

Esta es la comprobación que cuenta. El verificador abre una conexión con el servidor de recepción y recorre el principio de una entrega: se identifica, declara un remitente e indica el destinatario con RCPT TO. Luego lee la respuesta y se detiene. No llega a entregarse ningún mensaje.

SMTP tiene un comando hecho 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 permite al administrador desactivar el comando sin más. La mayoría de los servidores públicos se acogieron a esa opción hace años, así que los verificadores sondean con RCPT TO y leen los códigos de respuesta.

Importan dos familias de códigos (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 inequívoca de buzón muerto, «The email account that you tried to reach does not exist», la cuenta no existe. Su 452 4.2.2 significa buzón lleno: una persona real 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 de función

sales@, support@, info@, abuse@, webmaster@. Reales, entregables y estandarizadas 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 cuestiones distintas. Una dirección de función es válida de pleno derecho, y también el camino más corto a una queja por spam cuando la secuencia está pensada para una persona concreta.

5. Dominios desechables

Son servicios de buzón temporal, los que usa la gente para conseguir una prueba gratis. Aquí la detección se basa en una lista de bloqueo, no en un protocolo, y la referencia pública de facto es el repo disposable-email-domains. Sus mantenedores lo dicen sin rodeos: «no podemos garantizar que todos estos sigan considerándose desechables». Esta comprobación 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 ofrece al servidor una dirección que no puede existir de ninguna manera. Si también la acepta, el dominio lo acepta todo y su respuesta sobre tu dirección real no vale nada. Esta capa decide cuánto sobrevive de tu lista.

Por qué dos verificadores no dicen lo mismo de 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 está mintiendo. Una sola pasada SMTP es una medición a través de un canal con ruido, y ese ruido tiene nombre.

El greylisting es la mayor fuente de ruido, y el RFC 6647 lo describe sin adornos. Al primer contacto de un remitente desconocido, el servidor responde con un 421, cierra la conexión, apunta la terna de IP, remitente y primer destinatario, y acepta el mensaje en un reintento 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. Google publica él mismo esa respuesta: 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 choca contra ese muro, y todas las direcciones que quedan detrás salen sin resolver. También importa 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 una sonda que sale de una IP sin esa configuración queda rechazada mucho antes de llegar 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. Donde esa función no entra en juego, la respuesta del tenant aporta muchísima menos información y el verificador se queda sin una base sólida sobre la que razonar. Ese mecanismo está, en la práctica, en el origen del problema de las catch-all en los dominios B2B europeos.

Por eso Enrow no lanza una sola pasada. Cada dirección pasa por 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 cómo difieren esas respuestas entre sí, incluida la forma en que el dominio trata una dirección de control que no ha visto nunca.

Una sonda obtiene un aplazamiento y poco más. Varias, desde regiones distintas y con una dirección de control, obtienen un veredicto.

El problema de las catch-all, y lo que te cuesta en oportunidades

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

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

Y entonces el dueño de la lista hace una de dos cosas, a cuál peor. Borra el segmento y tira a la basura cientos de responsables de decisión reales. O envía igualmente a ese segmento y se come los bounces. En mis propios ficheros, el montón de «risky» es con frecuencia el segundo segmento más grande después de los válidos limpios, 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, aunque no con una sola sonda. Conversaciones SMTP repetidas desde orígenes distintos, a horas distintas y contrastadas con direcciones de control inventadas a propósito dan una señal que una comprobación única no da. Enrow las resuelve por esa vía y te las entrega como válidas en lugar de marcarlas como dudosas; como nada se cobra hasta que el resultado es válido, una fila que no se puede resolver no te cuesta nada. Hay dominios que no ceden nunca, y lo correcto es dejar esas filas fuera. Quedan muchas menos sin resolver que con una herramienta de una sola pasada, pero no cero. La mecánica completa la explicamos en nuestro artículo sobre 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 una comprobación SMTP real y no una simple comparación de formatos. Lo que buscas es algo que sepa distinguir «el servidor ha dicho que no» de «el servidor no ha querido decirlo». Una herramienta que solo responde válido o inválido, sin tercera categoría ni tratamiento de las catch-all, suele ser una comprobación de sintaxis y MX disfrazada de verificador. Hacerlo a mano es peor: abrir un telnet al puerto 25 desde la IP de la oficina acaba en greylisting o en un bloqueo al cabo de unas pocas decenas de intentos, y los scripts de GitHub que automatizan ese diálogo heredan todos los problemas descritos arriba.

Verificación en masa, paso a paso

Para limpiar listas a escala, 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, incluida la misma persona registrada con dos alias. Pagas por dirección comprobada, así que este paso es puro ahorro.
2. Saca las direcciones de función a su propia pestaña antes de subir nada. El RFC 2142 te da la lista de patrones. Salen como válidas en la verificación y te destrozan una secuencia personalizada.
3. Sube el CSV. El Email Verifier de Enrow se traga un fichero de miles de filas y asigna un estado a cada una; el mismo motor verifica direcciones de una en una a través de la API o del servidor MCP oficial (github.com/EnrowAPI/enrow-mcp) cuando el flujo de trabajo funciona dentro de 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 analiza los bounces por dominio receptor, no por campaña. Cinco bounces repartidos en un envío son ruido; cinco en el dominio de una misma empresa significan que las filas de esa empresa están mal.
6. Vuelve a verificar antes del siguiente envío: no reutilices tres meses después el mismo fichero ya verificado.

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 cuenta 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 de fuente primaria que merece la pena memorizar. Amazon SES lo dice así: «si tu tasa de bounce es del 5 % o superior, ponemos automáticamente tu cuenta bajo revisión. Si tu tasa de bounce es del 10 % o superior, podemos suspender la capacidad de tu cuenta para enviar más correo». SES cuenta solo los hard bounces.

Trata ese 5 % como el precipicio, no como el objetivo. El techo de trabajo habitual, sea cual sea el remitente, está en el 2 %, y el cold email debería quedarse por debajo del 1 %, que es justo lo que consigue una lista verificada. En mis listas, las direcciones encontradas y verificadas con Enrow rebotan por debajo del 1 %: es la media observada en envíos reales, no una garantía, y nadie te va a reembolsar nada si no se cumple.

Hay un número que se cita mal continuamente. El 0,3 % de Google es una tasa de quejas por spam, no de bounce: los remitentes que envían 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 % ya se resiente la entrega en la bandeja de entrada. Google no publica ningún umbral de bounce. Lo analizamos a fondo en nuestro 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 te da 50 créditos renovables cada mes, sin tarjeta: 200 verificaciones mensuales, para siempre.

Hagamos la comparación como es debido. 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 € cada una: casi 4 veces más caro por dirección comprobada. En facturación anual, con el 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 hecho ninguna conversión.

ZeroBounce regala 100 créditos al mes y gasta un crédito por validación; su suscripción ONE, a 99 $ al mes, da para 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 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 comprobar la llegada a la bandeja de entrada y vigilar listas negras que Enrow no vende, así que no es una factura de verificación pura.

La pega, en el caso de Enrow, es que los créditos son compartidos. Una tanda de 40.000 verificaciones en Pro agota el presupuesto del mes entero y no deja para buscar ni un contacto nuevo. Reparte los créditos antes de subir el fichero, o la limpieza se comerá el presupuesto 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. Con una lista montada hace uno o dos años, 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 empresa, los dominios los absorbe la empresa compradora, los alias se dan de baja. Ningún proveedor recupera esas filas, y una herramienta que te da un porcentaje de válidas sospechosamente alto en 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 teniendo el cargo que pone en tu CRM. Eso ya es trabajo de búsqueda, y lo tratamos en nuestro artículo sobre cómo encontrar el email de alguien.

Enrow tiene dos límites, ambos deliberados. No hay una base de datos que puedas consultar, porque Enrow 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 ningún rival iguala: desde un perfil de LinkedIn, la extensión de Chrome vuelca la ficha de contacto verificada completa, 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 una simple comparación de formatos: sintaxis, registros MX, una sonda RCPT TO y las listas de direcciones de función y de dominios desechables. Un rechazo permanente 5yz significa que el buzón está muerto. Un 4yz transitorio significa que el servidor te ha aplazado y que hay que repetir la comprobación por otra vía. Si el dominio lo acepta todo, ninguna sonda aislada puede dar 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 de función 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 los válidos limpios, guarda las catch-all para una herramienta que las resuelva, borra definitivamente las direcciones 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 al primer contacto de un remitente desconocido, Gmail frena el sondeo de alto volumen 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 traza la línea 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 para cualquier dirección que le ofrezcas, 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 al llegar al 5 % y puede suspender los envíos en el 10 %, contando solo los hard bounces. Trabaja con un techo del 2 % y apunta a quedarte por debajo del 1 % en cold email, que es lo que consigue 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 única, y que haga comprobaciones SMTP reales en lugar de validación de 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.