La forma barata de verificar correos antes de enviar es una cascada por costo: sintaxis y registros MX primero, porque no cuestan nada, y un solo ping SMTP pagado para lo que sobrevivió. Lo que el verificador devuelve como catch-all no se reverifica con otro proveedor: se envía en un lote chico y se mide aparte.
Una cascada de verificación es una secuencia de chequeos ordenada de menor a mayor costo, donde cada paso solo recibe los contactos que el anterior no pudo descartar. Es la lógica de un waterfall de enriquecimiento aplicada a otra pregunta: no "¿cuál es el correo?", sino "¿esta dirección existe hoy?".
¿Por qué verificar toda la lista con el mismo método desperdicia presupuesto?
Porque la verificación no es un paso sino cuatro, con costos distintos, y la mayoría de los equipos manda todo a la API pagada. Una dirección sin arroba, o con un dominio que no tiene servidor de correo, falla gratis con una expresión regular y una consulta DNS. Pagar un crédito para descubrir eso es el desperdicio más común.
Lo que un verificador pagado hace y un filtro gratuito no puede es el ping SMTP: conectarse al servidor de correo del dominio y preguntarle si acepta esa dirección, sin enviar mensaje. Es lo único que cuesta un crédito, así que conviene gastarlo solo en lo que ya pasó los dos filtros baratos.
¿Para qué? Para mantener el rebote bajo. En nuestras campañas propias fue de 1.79% sobre 4,804 correos (campaña de industria, 1,657 empresas) y de 1.40% sobre 9,211 correos (campaña de software, 3,162 empresas), operación propia de mayo a agosto de 2026. Usamos 2% como señal roja: si una cohorte lo cruza, se detiene el envío. Son cifras de nuestra operación, no un benchmark del mercado.
En el método IMPRO (Investiga, Mensajes que llegan, Personalizados, Respuestas, Oportunidades), esta pieza es la M: no toca el copy, toca la condición previa para que el mensaje llegue. Si la lista viene de un ICP mal definido, verificar no la salva; empieza por por qué la lista importa más que el mensaje. Y si estás por comprar la base, lee antes cuándo comprar leads funciona y cuándo es tirar dinero.
¿En qué orden se arma la cascada de verificación, paso por paso?
Son cuatro pasos en orden de costo creciente: sintaxis, dominio con registros MX, ping SMTP y veredicto. Los dos primeros no cuestan nada y los corres tú. El tercero cuesta un crédito por contacto y lo corre un verificador. El cuarto es la regla que decide qué hacer con cada resultado, y es donde las listas pierden dinero o dominio.
| Paso | Qué revisa | Costo | Qué descarta o decide |
|---|---|---|---|
| 1. Sintaxis | Que el texto tenga forma de correo (usuario, arroba, dominio con punto) | $0 | Direcciones mal capturadas, espacios, comas |
| 2. Dominio y MX | Que el dominio tenga registros MX (consulta DNS) | $0 | Dominios inexistentes o sin servidor de correo |
| 3. Ping SMTP | Que el servidor acepte la dirección con RCPT TO |
1 crédito | Buzones que el servidor rechaza |
| 4. Veredicto | Válido, inválido o catch-all/unknown | $0 (es una regla) | Secuencia normal, descarte o lote chico |
El paso 3 funciona así. El verificador abre una conexión SMTP con el servidor del dominio, declara un remitente y emite RCPT TO:<dirección>. Según el RFC 5321, si el servidor acepta al destinatario responde 250, y si sabe que la dirección no es entregable responde 550 (IETF, RFC 5321 § 4.1.1.3, consultado el 2026-10-01). El verificador corta la conexión antes de enviar contenido. Mide el estado del servidor en ese momento, no el día en que tú envíes.
Un punto de criterio en el paso 2: el mismo RFC dice que, sin registro MX, el servidor que envía puede usar el registro A del dominio como MX implícito (RFC 5321 § 5.1, consultado el 2026-10-01). Nuestra regla de trabajo, que no es estándar, es descartar los dominios sin MX y revisar a mano solo las cuentas de alta prioridad.
Este script ilustra el orden, con un correo por línea en contactos.txt. Los dos primeros bloques son los pasos 1 y 2; el último, el paso 3. No es la API literal de ningún vendor: el endpoint y los parámetros cambian según el proveedor.
while read -r correo; do
# Paso 1: sintaxis (costo cero)
echo "$correo" | grep -Eq '^[^@[:space:]]+@[^@[:space:]]+\.[^@[:space:]]+$' \
|| { echo "$correo,descartado,sintaxis" >> resultado.csv; continue; }
# Paso 2: registros MX del dominio (costo cero)
dominio="${correo#*@}"
[ -n "$(dig +short MX "$dominio")" ] \
|| { echo "$correo,descartado,sin_mx" >> resultado.csv; continue; }
# Solo lo que pasó los dos filtros llega al paso pagado
echo "$correo" >> para_verificar.txt
done < contactos.txt
while read -r correo; do
curl -s "https://api.verificador.example/v1/verify?email=${correo}" \
-H "Authorization: Bearer ${API_KEY}" >> respuestas.jsonl
done < para_verificar.txt
La expresión regular es simple a propósito: lo que detecta un correo inexistente es el paso 3, no una sintaxis más elaborada. Para elegir el proveedor del paso 3, con precio y política de "unknown" de cada uno, ve verificadores de correo comparados.
¿Qué haces con un correo catch-all o unknown sin pagar otra vez por él?
Con un catch-all no pagas otra verificación: lo envías en un lote de menor volumen y mides su rebote por separado. Un segundo verificador no resuelve la ambigüedad porque el límite es del protocolo, no del vendor. Un dominio catch-all responde 250 a cualquier dirección, exista o no, así que ese 250 no dice nada del buzón concreto.
Un dominio catch-all es un servidor de correo configurado para aceptar todo lo que llega a su dominio, sin rechazar direcciones inexistentes en el RCPT TO. El verificador solo puede estimar una probabilidad. Un unknown es el resultado cuando el servidor no da una respuesta que permita decidir; si la causa fue transitoria (servidor caído o saturado), reintentar una vez con el mismo verificador es razonable, y Bouncer no cobra los unknown (Bouncer, página de precios, consultada el 2026-10-01). Si persiste, se trata como catch-all.
El lote chico funciona así:
- Cohorte propia. Etiqueta los catch-all y unknown en el CRM como grupo aparte.
- Menor volumen que los válidos. Para dimensionarlo por buzón, ve cuántos correos al día por buzón sin quemar el dominio.
- Corte propio. Detén el lote al cruzar 2% de rebote. Con 500 contactos en el lote, 2% son 10 rebotes.
En catch-all la verdad sale del historial de envíos reales, no de otro chequeo. Si ya enviaste a otros contactos del mismo dominio y no rebotaron, ese dato vale más que un segundo verificador.
Descartarlos de entrada parece la opción segura, pero en México y LatAm sale caro: el catch-all es común en PyMEs que corren Google Workspace o Microsoft 365, y excluirlos suele tirar entre 30% y 50% de la base. Por eso la postura que sostenemos es balanceada: entran al envío, en su propio lote y con su propio corte, en vez de quedarse fuera por default.
Los propios vendors tratan el catch-all como caso aparte: DeBounce cobra 10 créditos por validar una dirección en dominio catch-all en vez de 1, mientras que MillionVerifier reembolsa el crédito de lo que no puede verificar con certeza (páginas oficiales, consultadas el 2026-09-20, según nuestra comparativa de verificadores). Son políticas de cada vendor, sin auditoría externa.
¿Cuánto cuesta verificar la misma lista dos veces en 2026?
Verificar 5,000 contactos nuevos una sola vez con MillionVerifier cuesta $8.90 USD; pasarlos además por una segunda verificación completa con Bouncer "por si acaso" suma $40.00 USD, para un total de $48.90 USD. El error cuesta $40.00 USD, unos $723 MXN, y no agrega información sobre los catch-all.
Supuestos del ejemplo: 5,000 contactos nuevos en el mes, precios publicados por cada vendor (consultados el 2026-10-01) y reverificación del 100% del lote.
| Escenario | Cuenta | USD | MXN (FIX 18.0692) |
|---|---|---|---|
| Verificación única (MillionVerifier) | 5,000 × $0.00178 | $8.90 | $161 |
| Segunda pasada completa (Bouncer) | 5,000 × $0.008 | $40.00 | $723 |
| Total con doble verificación | $8.90 + $40.00 | $48.90 | $884 |
Las fuentes: $89 USD por 50,000 créditos en MillionVerifier, que da $0.00178 por crédito, y $8 USD por 1,000 créditos en Bouncer, que da $0.008 (ambas consultadas el 2026-10-01). El tipo de cambio es el FIX de Banxico del 30 de septiembre de 2026, 18.0692 MXN por dólar, el último establecido a la fecha de consulta (Banco de México, consultado el 2026-10-01). Los MXN van redondeados al peso y sin impuestos ni comisiones bancarias por cobros en dólares.
Si solo reverificaras la fracción incierta, la pérdida sería menor. Supón, como hipótesis y no como dato, que 500 de los 5,000 son catch-all: 500 × $0.008 = $4.00 USD, unos $72 MXN. Poco dinero, pero la regla no cambia: pagar por la misma respuesta ambigua es comprar certeza que no existe.
El dinero sale barato; el costo real de la doble pasada es la falsa tranquilidad. Quien reverifica "para estar seguro" envía con más confianza de la que justifica el dato. Y los precios por crédito son los que cada vendor publica hoy, sin tabla de tramos auditada por terceros: compara el tramo que vas a comprar este mes, no el más barato del catálogo. Para poner este gasto junto al de una reunión completa, ve cómo calcular el costo por reunión calificada.
¿Cuándo se corta el gasto y se descarta el contacto en vez de seguir insistiendo?
Se corta cuando ya pagaste un ping y el resultado sigue ambiguo: ahí la decisión depende del valor de la cuenta, no de comprar más verificación. El corte no es un monto en dólares. Después de un catch-all o unknown pagado no existe un segundo chequeo que cambie el veredicto técnico.
La regla completa, para cada contacto, en este orden:
- Falla sintaxis o no tiene MX: descártalo sin gastar un crédito.
- El ping confirma: pasa a la secuencia normal.
- Sale catch-all o unknown: al lote chico, medido aparte.
- Sigue ambiguo y el lote chico cruzó 2%: decide por prioridad de cuenta.
Prioridad de cuenta es preguntarte si ese contacto pertenece a tu ICP de alta prioridad o a la cola larga. Si es cola larga, se descarta: no justifica quemar la reputación del buzón. Si es una cuenta que quieres sí o sí, la señal útil es el historial de envíos reales al dominio; y si no existe, prueba otro canal antes de arriesgar el buzón.
Un contacto "con correo" en tu CRM puede ser una suposición: los proveedores de datos adivinan buena parte de los correos por patrón en vez de comprarlos de una fuente verificada. Por eso la verificación propia no se delega.
¿Armo la cascada aparte o la activo dentro del waterfall que ya tengo en Clay o Apollo?
Si ya corres un waterfall de enriquecimiento en Clay o en Apollo, la verificación se activa como un nodo más de ese flujo y no se construye aparte. Una cascada paralela duplica créditos y deja dos fuentes de verdad sobre el mismo correo. La independiente solo se justifica si tus listas llegan de fuentes que no pasan por ese waterfall.
La condición práctica es dónde entra el correo a tu sistema. Si todo entra por Clay o Apollo, sintaxis, MX y ping se encadenan ahí, con el veredicto escrito en una propiedad del contacto. Si entra por un CSV comprado, una exportación de LinkedIn o un formulario, el script de arriba o un verificador por lote cubren ese hueco antes de que el contacto toque el CRM.
La parte de herramientas está en cómo usar Clay y Apollo sin duplicar enriquecimiento.
¿Cuándo no armar una cascada de verificación?
No la armes cuando el volumen mensual de contactos nuevos es bajo, de unos cientos como mucho: montar y mantener tres pasos cuesta más en configuración que lo que ahorra, y un solo verificador por lote basta. Es una banda cualitativa, no un umbral medido por nosotros.
Tampoco si la lógica ya existe en otro flujo, como el waterfall de arriba: duplicarla es deuda. Y no la uses para tapar un problema de lista: si el rebote sigue alto después de verificar, el problema suele estar en el ICP o en el origen de los datos, no en el verificador.
Verificar confirma que una cuenta existe, no que tu mensaje llegue a la bandeja principal; eso depende de la autenticación y la reputación del dominio. Una lista perfecta enviada desde un dominio sin calentar topa el volumen igual, como explica calentar un dominio sin quemarlo.
El lunes:
- Corre los dos filtros gratuitos (sintaxis y MX) sobre tu próximo lote antes de tocar cualquier API de pago.
- Escribe, por adelantado, qué pasa con los catch-all: a qué lote van, de qué tamaño y a qué rebote se detienen.
- Compra un solo tramo de créditos con el vendor que elegiste y registra la fecha de verificación de cada fila.
Si prefieres que alguien más audite y opere esta capa, Improvitz, consultoría de prospección B2B con IA en México, hace un diagnóstico de la lista y la infraestructura de envío.
