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 devuelve una palabra por fila. Esa palabra esconde algo mucho más sucio. 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. Marcadas «risky», descartadas, adiós. Enrow las verifica y te las entrega como válidas. Amazon SES pone una cuenta bajo 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 que ninguna campaña lo toque. Subes un CSV, te vuelve con un estado en cada fila, borras las malas. Casi todo el mundo deja de leer ahí, y ahí es exactamente donde se escapa el dinero.

Esa palabra de estado carga con un trabajo enorme. 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 funciona en seis capas. Las dos primeras son baratas y rápidas; en el resto es donde los verificadores empiezan a separarse.

1. Sintaxis

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

De la entrega no dice nada. postmaster@ pasa cualquier expresión regular que se haya escrito jamás, sobre 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 automáticamente. Aun así, los remitentes modernos rechazan esos dominios de todas formas, 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

Aquí está la comprobación que cuenta. El verificador abre una conexión contra el servidor que recibe y recorre el principio 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 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 a quien lo instala desactivar el comando directamente. La mayoría de los servidores públicos se acogieron a esa opción hace años, con lo cual los verificadores sondean con RCPT TO y leen 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 honesta 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 viva 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 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 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 estaba escrita para una persona con nombre y apellidos.

5. Dominios desechables

Servicios de buzón temporal, los que usa la gente para pillar una prueba gratis. Aquí la detección es una lista de bloqueo, no 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». 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 esa también se acepta, el dominio acepta cualquier cosa y su respuesta sobre tu dirección real no valía 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 vuelve como «unknown» tras una sonda y como «valid» tras más de 10 verificaciones.

Pasa una dirección por dos herramientas y a veces te salen dos respuestas. Ninguno de los dos proveedores está mintiendo. Una sola pasada SMTP es una medición a través de un canal con ruido, y el ruido tiene nombres.

El greylisting es el más ruidoso de todos, y el RFC 6647 lo describe sin adornos. Al primer contacto de un remitente desconocido, el servidor devuelve un 421, cierra la conexión, apunta la terna de IP, remitente y primer destinatario, y acepta en un reintento posterior. El propio RFC nombra el precio: «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 adivina.

El volumen dispara otra alarma distinta. Google publica la respuesta él mismo: 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 pequeño de IP se estampa contra ese muro, y todo lo que queda detrás vuelve sin resolver. Cuenta también 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 eso la echan mucho antes de llegar a la pregunta del 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 lleva muchísima menos información y el verificador se queda sin nada sólido sobre lo que razonar. Ese mecanismo es la raíz práctica 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 se separan esas respuestas entre sí, incluida la forma en que el dominio trata una dirección de control que no ha visto nunca.

Una sonda se lleva un aplazamiento y poco más. Varias, desde regiones distintas y contra una dirección de control, se llevan un veredicto.

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

Un dominio que lo acepta todo se queda con el correo dirigido a cualquier cosa. jane.doe@, jne.doe@, loquesea@. Todo aceptado, y luego tirado por dentro o devuelto horas después, con la conexión ya cerrada.

La mayoría de los verificadores llega ahí y para. Estampan «catch-all» o «risky» en la fila y te devuelven la decisión a ti. ZeroBounce empuja las catch-all sin resolver hacia 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).

Entonces el dueño de la lista hace una de dos cosas dañinas. Borra el segmento y tira a la basura responsables de decisión vivos por centenares. O le envía en crudo 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, solo que no con una 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 en lugar de como avisos; 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 honesto es dejar esas filas fuera. Muchas menos sin resolver que las que deja una herramienta de una sola pasada. Cero, no. La mecánica entera, en qué es un email catch-all.

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

Para verificar una dirección por su cuenta, pégala en una herramienta que haga trabajo SMTP real y no comparación de formatos. Lo que buscas es algo que sepa separar «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: abrir un telnet contra el puerto 25 desde la IP de la oficina te mete en greylisting o te bloquea en unas pocas decenas de intentos, y los scripts de GitHub que automatizan ese diálogo heredan todos los problemas de 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, mata los duplicados y a la misma persona bajo dos alias. Pagas por dirección comprobada, así que este paso es dinero regalado.
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. Verifican como válidas y te destrozan 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 de una en una a través de la API, o desde el servidor MCP oficial (github.com/EnrowAPI/enrow-mcp) cuando el flujo vive 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 mira los bounces por dominio receptor, no por campaña. Cinco bounces repartidos por 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 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 cuenta el marketing directo como uno de ellos. Los considerandos orientan la interpretación; vinculantes no son.

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: «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 con el que se trabaja, mires al remitente que mires, está en el 2 %, y el cold email debería quedarse por debajo del 1 %, que es justo lo que produce una lista verificada. En mis listas, las direcciones encontradas y verificadas con Enrow hacen bounce por debajo del 1 %: media constatada en envíos reales, no una garantía, y no hay nadie que te la vaya a devolver en dinero.

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 empujan más de 5.000 mensajes al día hacia Gmail tienen que mantener la tasa de spam de Postmaster Tools por debajo del 0,3 %, y por encima del 0,1 % ya se paga en colocación. Google no publica ningún umbral de bounce. Lo desmenuzamos en la tasa de bounce.

Cuánto cuesta verificar una lista entera

Verificar en Enrow cuesta 0,25 créditos por dirección, de la misma bolsa de créditos con la que buscas:

El plan gratuito son 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, contra los 75 € de Enrow por 40.000, a 0,001875 €: cerca de 4 veces por dirección comprobada. Anual, mismo volumen: 0,0052 € (por confirmar) frente a 0,0017 €, unas 3,1 veces. Esas cifras son de Hunter, que publica en euros; no hay ninguna conversión por mi parte.

ZeroBounce recarga 100 créditos gratis al mes y gasta un crédito por validación, de modo que su suscripción ONE, a 99 $ al mes, compra 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 contra mensual, misma base. Eso sí, ese plan de ZeroBounce trae de serie herramientas de colocación en bandeja y de listas negras que Enrow no vende, así que no es una factura de verificación pura.

La pega honesta del lado de Enrow: 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. Reparte antes de subir el fichero, o la limpieza se te come la búsqueda.

Lo que la verificación no puede hacer

No resucita un buzón muerto.

Es el límite que nadie que venda verificación dice 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 empresa, los dominios se los come quien compra la compañía, los alias se retiran. Ningún proveedor recupera esas filas, y una herramienta que te devuelve un porcentaje de válidos sospechosamente alto sobre una lista vieja está describiendo lo blanda que es ella, 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: cómo encontrar el email de alguien.

Dos fronteras de Enrow, las dos puestas a propósito. No hay una base de datos que puedas consultar, porque 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 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 la comprobación hay que repetirla por otra ruta. Si el dominio lo acepta todo, ninguna sonda suelta puede responder 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 los inválidos duros para siempre 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 pone la raya entre válido y dudoso en un sitio distinto. El arreglo es la repetición: 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 el segmento es el error 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 bajo 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 apunta por debajo del 1 % en cold email, que es lo que produce 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 muestra de una sola vez, 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, sobre 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.