La versión breve
El mapa completo
TOM condensa cada veredicto de BillionVerify en una luz. Verde significa enviar. Amarillo significa decidir de forma deliberada. Rojo significa excluido por defecto — no lo puedes seleccionar para una campaña en frío. La tabla siguiente es la correspondencia completa.
| Luz de TOM | ev_score | Estado | Significado |
|---|---|---|---|
| 🟢 Verde | ≥ 0.9 | valid | El email existe y puede recibir mensajes |
| 🟡 Amarillo | ≥ 0.7 | catchall | El dominio acepta todos los emails — buzón no confirmado individualmente |
| 🟡 Amarillo | ≥ 0.6 | role | Dirección role-based (info@, support@, …) — entregable, menor interacción |
| 🔴 Rojo | ≥ 0.5 | unknown | No se pudo determinar la validez |
| 🔴 Rojo | ≥ 0.3 | disposable | Servicio de email temporal |
| 🔴 Rojo | ≈ 0.3 | risky | El buzón probablemente acepta correo, pero el dominio está blocklisted por spam, phishing, malware o actividad botnet |
| 🔴 Rojo | < 0.3 | invalid | El email no existe o no puede recibir mensajes |
Dos cosas que conviene notar de inmediato. Primero, el mapa está ordenado: TOM lee las bandas de puntuación de arriba abajo, así que cada dirección cae en exactamente una fila. Segundo, hay siete veredictos detrás de tres luces — el rojo cubre cuatro situaciones distintas (unknown, disposable, risky, invalid) que fallan por motivos completamente diferentes. El resto de esta guía desglosa cada una.
Antes del color: qué comprueba la verificación
La luz es el último paso de un pipeline de seis etapas. Conocer las etapas importa porque cada color es en realidad una afirmación sobre dónde pasó o falló la dirección:
- Comprobación de sintaxis. ¿La dirección está bien formada (una
@, parte local y dominio válidos)? Una dirección malformada nunca pasa esta etapa — se convierte eninvalidcon motivoinvalid_syntax. - Comprobación de dominio. ¿El dominio existe y resuelve en DNS? Un dominio muerto o no registrado se convierte en
invalid(no_mx_records, ospf_reject_allcuando el dominio rechaza explícitamente todo el correo entrante). - Comprobación de registros MX. ¿El dominio publica servidores de correo que pueden recibir email? Sin registros MX no hay buzón — de nuevo
invalid. - Detección de desechables. ¿El dominio está en la lista de más de 5.000 proveedores conocidos de email temporal (Mailinator, 10MinuteMail, Guerrilla Mail y similares, actualizada a diario)? Una coincidencia se convierte en
disposable, exista o no técnicamente el buzón. - Comprobación SMTP. El paso decisivo: BillionVerify se conecta al servidor de correo del destinatario y pregunta, vía
RCPT TO, si el buzón concreto existe. Un250 OKlo confirma (valid); un550 user unknownlo descarta (invalid,mailbox_not_found). Todo lo ambiguo — timeouts, greylisting, límites de frecuencia, sondas bloqueadas — se convierte enunknownocatchall. - Cálculo de puntuación. Todos los resultados de las etapas se combinan en una puntuación de confianza de 0.0 a 1.0. La confirmación SMTP es lo que más pesa (alrededor del 30%), seguida de los registros MX, la existencia del dominio, el estado disposable y las señales de reputación.
Sobre este pipeline hay dos detecciones ortogonales: patrones role-based (¿es un buzón compartido?) y cribado de reputación contra la Spamhaus Domain Blocklist (¿es este dominio una fuente confirmada de spam, phishing, malware o botnet?). Producen los veredictos role y risky respectivamente.
Verde: valid
🟢 Verde · ev_score ≥ 0.9 · estado valid
El buzón existe y puede recibir mensajes. SMTP devolvió 250 OK para esta dirección concreta (smtp_deliverable). Seguro para enviar.
El verde es el único veredicto que confirma el buzón individual, no solo el dominio. La sintaxis es válida, el dominio existe, hay registros MX publicados, la dirección no es desechable y el servidor receptor aceptó explícitamente el destinatario. La confianza es alta — en la escala de BillionVerify es la banda 0.9–1.0, «alta confianza valid».
Qué hacer: incluir en campañas en frío sin dudar. Las direcciones verdes son la columna vertebral de cada envío; el umbral de calidad por campaña de TOM existe precisamente para mantener alta su proporción.
Amarillo: catch-all
🟡 Amarillo · ev_score ≥ 0.7 · estado catchall
El dominio acepta todos los emails, así que este buzón concreto no se puede confirmar. La dirección de prueba fue aceptada junto con una dirección aleatoria de control — el servidor dice sí a todo. Conservar, pero vigilar los rebotes.
El catch-all es una propiedad del dominio, no de la dirección. Empresas pequeñas y configuraciones autoalojadas suelen configurar su servidor de correo — o una pasarela de seguridad como Mimecast o Proofpoint en modo accept-all, o un relay interno de Microsoft 365 — para aceptar cualquier destinatario en vez de rebotar los desconocidos. La conversación SMTP, por tanto, no prueba nada sobre si marco@ funciona realmente ahí.
Los códigos de motivo típicos detrás de un catch-all incluyen catch_all_domain (sonda aleatoria aceptada), catch_all_deliverable (dominio catch-all donde la dirección concreta también devolvió 250 OK), gateway_accept_all y m365_internal_relay. Los servicios de alias de reenvío (SimpleLogin, Firefox Relay, Duck.com) y algunos dominios regionales de consumo también caen aquí.
¿Por qué amarillo y no verde? Porque el riesgo de rebote es estructuralmente mayor: estás enviando a una dirección que el verificador no pudo confirmar individualmente. ¿Por qué amarillo y no rojo? Porque muchas direcciones catch-all son personas reales en empresas reales — descartarlas todas tiraría prospectos legítimos, sobre todo en el segmento SMB.
Amarillo: role-based
🟡 Amarillo · ev_score ≥ 0.6 · estado role
Un buzón compartido, no una persona. Direcciones como info@, support@, sales@, admin@ o noreply@ suelen ser entregables pero se comportan distinto: varias personas pueden leerlas, las tasas de queja son más altas y la interacción es menor.
Un matiz de la documentación: las direcciones role heredan el código de motivo de su comprobación SMTP subyacente — no hay códigos de motivo dedicados para este estado. Una dirección role que pasó SMTP muestra reason: smtp_deliverable, exactamente como una dirección verde. El flag role (is_role: true) es lo que la distingue.
No todas las direcciones role conllevan el mismo riesgo. Como regla general de la referencia de BillionVerify:
| Patrón | Tipo | Nivel de riesgo |
|---|---|---|
| sales@ | Ventas | Bajo |
| info@, support@ | General | Medio |
| admin@, webmaster@ | Técnico | Alto |
| noreply@, abuse@ | Automatizado / compliance | Muy alto |
¿Por qué amarillo? El buzón existe, así que el rojo sería erróneo — pero un cold email a info@ compite con todos los demás mensajes entrantes de esa empresa, y algunos proveedores restringen las direcciones role directamente. Bien para email transaccional; para cold outreach, usar de forma deliberada y esperar tasas de respuesta más bajas.
Rojo: unknown
🔴 Rojo · ev_score ≥ 0.5 · estado unknown
No se pudo determinar la validez. El servidor de correo agotó el tiempo de espera, aplicó greylisting a la sonda, la limitó por frecuencia, o pertenece a un proveedor que bloquea por completo la verificación SMTP automatizada. Excluido por defecto — TOM no te deja seleccionarlo para una campaña en frío.
Unknown es el veredicto más incomprendido, porque «unknown» suena neutro mientras TOM muestra rojo. El rojo es intencionado: una dirección cuya validez no se puede confirmar conlleva el mismo riesgo de envío que una mala hasta que se demuestre lo contrario. Por eso TOM te orienta a hacer cold outreach correctamente y bloquea las direcciones rojas en vez de dejarte apostar un rebote con ellas.
Las causas habituales se dividen en dos grupos:
- Temporales y reintentables — merece la pena verificar de nuevo:
smtp_timeout,smtp_rate_limited,smtp_greylisted(incluida la variante de Mimecast), búsquedas asíncronas de Proofpoint, rechazos temporales de Google y Microsoft 365, timeouts de DNS y errores internos transitorios. - Estructurales y no reintentables — reintentar no cambiará el resultado: proveedores que bloquean las sondas SMTP por política (Apple iCloud, correo consumer de Microsoft, Proton, Tuta, dominios japoneses de operadoras), servidores que pusieron la conexión de sonda en lista negra, configuraciones DMARC desalineadas, buzones llenos o deshabilitados, y cuentas configuradas para omitir la verificación SMTP.
Regla práctica: reverifica una vez tras una pausa — el greylisting y los límites de frecuencia suelen desaparecer, y la dirección puede pasar a verde o amarillo y volverse seleccionable. Mientras siga unknown, permanece excluida por defecto y no se puede añadir a una campaña en frío.
Rojo: disposable y risky
🔴 Rojo · ev_score ≈ 0.3 · estado disposable / risky
Dos veredictos distintos comparten la misma puntuación — y la misma luz. Disposable significa un servicio de email temporal sin valor de vida. Risky significa que el buzón probablemente funciona pero el dominio está blocklisted por abuso. Ambos están excluidos por defecto en TOM y no se pueden seleccionar para una campaña en frío.
Disposable (is_disposable: true, motivo disposable_domain) cubre Mailinator, 10MinuteMail, Guerrilla Mail, TempMail y miles de generadores más pequeños. Estas direcciones rara vez interactúan, suelen usarse para spam o fraude, y señalan un valor de vida casi nulo — especialmente dañino en flujos de registro.
Risky es el veredicto que falta en la mayoría de resúmenes, así que merece una explicación completa. Significa que el buzón muy probablemente acepta correo (is_deliverable: true), pero el dominio receptor está listado en la Spamhaus Domain Blocklist por spam, phishing, distribución de malware o comando y control de botnet. El array risk_reasons te dice cuál: spamhaus_dbl_spam, spamhaus_dbl_phish, spamhaus_dbl_malware o spamhaus_dbl_botnet_cc. Enviar ahí puede dañar tu propia reputación de envío, así que la acción recomendada es idéntica a disposable: eliminar de la lista. Reintentar nunca cambia un resultado risky.
Una tranquilidad de la documentación: los dominios que Spamhaus marca como sitios legítimos abusados — una web normal de empresa que fue comprometida — nunca producen un resultado risky. Una web hackeada no significa que los buzones de esa empresa sean malos.
En TOM
Ambos veredictos aparecen como rojo en la banda de puntuación 0.3, y TOM excluye ambos de la selección. Si necesitas distinguirlos — por ejemplo para diferenciar «nunca interactuó» de «peligroso de tocar» — mira el estado subyacente: disposable merece eliminación de cualquier lista; risky además te advierte de no reintentarlo nunca como si fuera un fallo temporal.
Rojo: invalid
🔴 Rojo · ev_score < 0.3 · estado invalid
La dirección no puede recibir mensajes. El buzón no existe, el dominio no existe, o el formato mismo está roto. Excluido por defecto — TOM no te deja seleccionarlo, porque cada envío a una dirección invalid sería un rebote seguro y dañaría tu reputación de remitente.
Invalid es el veredicto negativo más seguro (puntuación en torno a 0.1). Códigos de motivo típicos: invalid_syntax (dirección malformada), no_mx_records (dominio sin servidor de correo), spf_reject_all (el dominio rechaza explícitamente todo el correo entrante), mailbox_not_found (el servidor devolvió 550 / usuario desconocido) y host_not_found (el host MX mismo es inalcanzable).
Aquí no hay «quizás» ni lógica de reintento que ayude: una dirección invalid rebotará siempre. En cold outreach es puro coste — un rebote, un golpe a la reputación, y un prospect que nunca existió.
Puntuación vs estado: ¿cuál decide el color?
Ambos — y nunca discrepan. Cada estado lleva una puntuación fija, así que las dos lecturas son equivalentes:
| Banda de puntuación | Interpretación | Luz de TOM |
|---|---|---|
| 0.9 – 1.0 | Alta confianza valid | 🟢 Verde |
| 0.6 – 0.8 | Incierto — entregable pero no verificado o compartido | 🟡 Amarillo |
| 0.4 – 0.6 | No se pudo verificar | 🔴 Rojo |
| 0.0 – 0.4 | Probablemente invalid, disposable o abusivo | 🔴 Rojo |
Piensa en la puntuación como la forma legible por máquina del estado, y en el color como la forma legible por humanos de la puntuación. TOM evalúa las bandas de arriba abajo — gana el primer umbral que alcanza la puntuación — por eso una dirección solo puede tener una luz. El flag is_deliverable sigue la misma lógica: true para valid (y técnicamente para risky), false para invalid, null para unknown y catch-all donde la entregabilidad es genuinamente indeterminada.
Qué hacer con cada color en TOM
La verificación solo sirve si cambia lo que envías. En TOM lo hace por diseño: las direcciones rojas están excluidas por defecto y no se pueden seleccionar para una campaña en frío — orientarte a hacer cold outreach correctamente significa no dejarte enviar a direcciones que rebotarían con seguridad. Las verdes y amarillas sí se pueden seleccionar; el umbral de calidad por campaña decide entonces cuánto amarillo puede contener un envío.
| Veredicto | Luz | En una campaña en frío de TOM |
|---|---|---|
| valid | 🟢 | Seleccionable — enviar |
| catchall | 🟡 | Seleccionable — tu decisión; lote de prueba, vigilar rebotes |
| role | 🟡 | Seleccionable — tu decisión; esperar menor interacción |
| unknown | 🔴 | Excluido por defecto, no seleccionable — reverificar primero |
| disposable | 🔴 | Excluido por defecto, no seleccionable |
| risky | 🔴 | Excluido por defecto, no seleccionable |
| invalid | 🔴 | Excluido por defecto, no seleccionable |
En TOM esto se juega en tres lugares: la luz por dirección te dice lo que vale cada contacto, el umbral mínimo de calidad por campaña mantiene alta la proporción de verde entre las direcciones seleccionables, y el pre-flight check antes del lanzamiento detiene una campaña cuya calidad de lista quemaría el dominio. Las direcciones rojas nunca llegan a ese punto — se filtran antes de la selección. Los créditos de verificación no caducan nunca, así que reverificar una dirección unknown la semana que viene — o limpiar una lista que lleva 90 días parada — no cuesta extra, y una dirección que pase a verde o amarillo se vuelve seleccionable.
Direcciones valid de alta confianza. Esta es la composición de lista a la que debe aspirar cada campaña.
Las direcciones catch-all y role se pueden seleccionar y pueden quedarse para una prueba deliberada, pero nunca deben dominar un envío en frío.
Excluidos por defecto y no seleccionables. Reverifica una vez tras una pausa; si la dirección pasa a verde o amarillo, se vuelve seleccionable.
Excluidos por defecto y no seleccionables. Sin lote de prueba, sin segunda oportunidad — TOM los bloquea para que un rebote seguro nunca salga de tu dominio.
Cuando el resultado te sorprende: códigos de motivo
Cada veredicto trae un campo reason — un identificador string estable que explica por qué la dirección recibió su estado. Cuando una luz parece errónea, el motivo es donde hay que mirar. Los más útiles para reconocer:
- Parece rojo pero esperabas verde:
mailbox_not_found(errata en la dirección o empleado que se fue),no_mx_records(dominio sin correo),smtp_blockedosmtp_unverifiable(el proveedor rechaza las sondas — habitual con iCloud, correo consumer de Microsoft, Proton y Tuta). - Parece amarillo pero esperabas verde:
catch_all_domainogateway_accept_all(el dominio lo acepta todo), o unsmtp_deliverableheredado junto ais_role: true(un buzón compartido que funciona). - Atascado en unknown: comprueba si el motivo es reintentable (
smtp_timeout,smtp_rate_limited,smtp_greylisted,google_rate_limit,dns_timeout) o estructural (smtp_unverifiable,carrier_blocked,mailbox_full). Solo el primer grupo mejora al reintentar. - Puntuación 0.3 sin causa obvia: revisa
risk_reasons. Una entradaspamhaus_dbl_*significa que el dominio está blocklisted — la dirección no es «de baja calidad», es activamente peligrosa para tu reputación.
Dos flags complementarios ayudan con la segmentación más allá de la entregabilidad: is_free (Gmail, Yahoo, Outlook — útil para puntuación B2B vs B2C y detección de fraude) y smtp_check (si la sonda SMTP profunda llegó a ejecutarse, o si el veredicto se basa en heurísticas a nivel de dominio).
FAQ
¿Por qué una dirección catch-all es amarilla y no verde?
Un dominio catch-all acepta correo para cualquier dirección, así que la sonda SMTP no puede confirmar que el buzón concreto exista. La dirección puede ser entregable, pero el riesgo de rebote es mayor — el amarillo significa consérvala solo si aceptas ese riesgo y vigilas los rebotes.
¿Por qué una dirección role-based es amarilla y no verde?
Las direcciones role como info@ o support@ suelen ser entregables, pero pertenecen a un buzón compartido: varias personas pueden leer el mensaje, las tasas de queja son más altas y la interacción es menor. El amarillo señala que el buzón existe pero la dinámica de respuesta es distinta de la de un buzón personal.
¿Por qué unknown es rojo si la dirección podría ser válida?
Unknown significa que el verificador no pudo determinar la validez — timeout del servidor, greylisting, limitación de frecuencia o un proveedor que bloquea las sondas SMTP. Algunos resultados unknown son reintentables, pero enviar a ciegas arriesga rebotes, así que TOM los trata como rojos: excluidos por defecto y no seleccionables para campañas en frío. Reverifica más tarde — si la dirección pasa a verde o amarillo, se vuelve seleccionable.
¿Cuál es la diferencia entre disposable y risky si ambos puntúan 0.3?
Disposable significa que el dominio pertenece a un servicio de email temporal sin valor de interacción. Risky significa que el buzón probablemente acepta correo pero el dominio está listado por Spamhaus por spam, phishing, malware o actividad botnet. Ambos son rojos en TOM — excluidos por defecto y no seleccionables para cold outreach. Uno nunca respondería, el otro podría dañar tu reputación de remitente, así que TOM bloquea ambos en vez de dejarte elegir.
¿Debería enviar cold email a direcciones amarillas?
Solo de forma deliberada. Las direcciones catch-all y role-based son lo bastante entregables para email transaccional, pero para campañas en frío merecen cautela: envía primero un lote de prueba más pequeño, vigila rebotes y respuestas, y mantén un umbral de calidad por campaña para que los amarillos nunca dominen un envío.
¿Qué decide el color en TOM: la puntuación o el estado?
Ambos, y siempre coinciden: cada estado de BillionVerify lleva una puntuación fija (valid 0.9+, catch-all 0.7, role 0.6, unknown 0.5, disposable y risky 0.3, invalid 0.1). TOM mapea bandas de puntuación a luces, así que leer el color equivale a leer el estado subyacente.
Empieza la beta
Verifica primero, luego envía
Cada dirección en TOM lleva su luz verde, amarilla o roja antes de que salga un solo email — las direcciones rojas están excluidas por defecto y no se pueden seleccionar, los umbrales de calidad por campaña mantienen fuerte la lista seleccionable, y un pre-flight check detiene las listas débiles antes de que quemen tu dominio. Los créditos de verificación se compran por separado y no caducan. El copy con IA, el warmup y las respuestas están disponibles con cada buzón: 19 USD por buzón al mes, sin cuota mensual de plataforma. Los dominios y créditos de verificación se cobran aparte. La cancelación detiene las renovaciones futuras al final del ciclo de facturación; se mantienen los derechos legales del consumidor.
Empieza con un buzónEsta guía forma parte del blog de TOM. Los estados y puntuaciones de verificación siguen la documentación de verification-types de BillionVerify y la referencia de verification-reasons. Lecturas relacionadas: los 12 frameworks de cold email, 12 alternativas de software de cold email comparadas y el warmup como comportamiento de plataforma.