Verificar 100 emails es trivial. Verificar 50.000 sin que Gmail te devuelva un 5xx permanente cambia el problema por completo. Este post explica cómo lo hacemos internamente y qué patrones te evitan un bloqueo de IP que puede costarte semanas de deliverability.
Por qué no podés simplemente iterar
El instinto de un dev cuando le pasan un CSV con 50k emails es abrir un for loop y llamar al verificador uno por uno. Con Gmail eso te bloquea la IP en cuestión de minutos: sus servidores empiezan a devolver 421 4.7.0 [IP] please slow down y después550 5.7.1 too many connections. La reputación de la IP baja, y hasta las verificaciones bien intencionadas terminan siendo interpretadas como spam.
Lo que hace un verificador serio
- Agrupa por dominio. No hace 200 handshakes SMTP a Gmail seguidos. Los espacia con cooldown de 8-12 segundos por email en el mismo dominio.
- Paraleliza entre dominios. Mientras Gmail espera su cooldown, arranca Outlook, Yahoo, Hotmail, etc. Todos en paralelo.
- Rate limit global por IP. Aunque un dominio no aparezca en la lista, si tu IP saliente hace más de N handshakes/segundo, algunos ISPs también bloquean.
- Reintentos exponenciales en 4xx temporales. Un 421 no es un “este mailbox no existe”; es un “estoy ocupado”. Reintentar 60 segundos después suele funcionar.
- Puerto 25 outbound propio. Los proveedores serverless (Vercel, Netlify, Cloudflare Workers) tienen el 25 bloqueado. Sin él, no hay verificación SMTP real: cualquier resultado es adivinanza sobre MX + heurísticas.
Timing esperable
Un CSV bien distribuido de 50.000 emails con ~2.000 dominios distintos puede procesarse en 2-8 horas. Un CSV con 45k Gmail concentrados puede tardar 3+ días. El cuello de botella siempre es el dominio más pesado, no la cantidad total.
Bulk async, no bulk sincrónico
La API tiene que ser POST /bulk → devuelve job_id, y el cliente polleа o recibe webhook cuando termina. Un endpoint que espera 3 horas para devolver un CSV es imposible de operar: proxies, browsers y load balancers cortan a los 30-100 segundos.
Además, el débito de créditos debe ser atómico: se descuenta al encolar, y los créditos no procesados se reembolsan al terminar o cancelar. Esto es crítico: si el usuario cancela a mitad de un job de 50k, no puede quedar con 50k créditos descontados y solo 20k emails verificados.
Yahoo, AOL y el problema del “250 OK a todo”
Yahoo y AOL responden 250 OK a cualquier RCPT TO como política anti-harvesting. Esto significa que ningún verificador puede darte un deliverable honesto para esos dominios — cualquiera que lo haga te está mintiendo. La respuesta correcta es marcar esos emails como unknown o risky y dejar que el cliente decida.
Qué hace ByeBouncer con 50k
Para limpiar una lista de 50.000, dividila en trabajos de hasta 5.000 emails. Ese es el techo actual por trabajo durante el piloto. Procesamos con concurrencia por dominio, respetamos rate limits agresivos por proveedor, reembolsamos automáticamente los créditos no procesados si cancelás, y guardamos cada CSV resultado 7 días para que puedas descargarlo vía signed URL.
La UI muestra progreso cada 5 emails procesados, así que aunque un trabajo tarde horas, tenés visibilidad real del avance.