El stack de outbound tiene seis capas —dominios y autenticación, buzones, herramienta de envío, datos, verificación y CRM— y se arman en ese orden porque cada una le pone un techo a la que sigue.
El stack mínimo para empezar outbound es una pieza de cada capa, resuelta en esa secuencia. No importa qué tan buena sea tu herramienta de envío si tus dominios no están calentados, ni qué tan bueno sea tu dato si nunca lo verificas antes de mandarlo.
Ahí está el problema de cómo se decide normalmente: la capa que casi todo el mundo compra primero es la herramienta de envío, que es la tercera de la cadena y la que menos cambia el resultado.
| Capa | Qué decide | Qué pasa si la saltas |
|---|---|---|
| Dominios y autenticación | Cuántos dominios secundarios necesitas y si tu dominio de marca queda protegido | Una campaña agresiva se lleva con ella el correo corporativo de la empresa |
| Buzones | De dónde salen y quién controla la reputación cuando uno se quema | Tu volumen real se queda por debajo de la meta y no sabes por qué |
| Herramienta de envío | Cómo rotas buzones, controlas el ritmo y detectas una respuesta | Saturas un buzón, o le mandas el correo 3 a quien ya contestó el 1 |
| Datos (enriquecimiento) | De dónde sale cada contacto antes de entrar a una secuencia | Pagas créditos por contactos que nunca vas a trabajar |
| Verificación | Si el correo existe hoy, no solo si el formato es válido | Los rebotes de la primera semana se comen el calentamiento de tres |
| CRM | Si lo que envías se mide en pipeline y no solo en correos enviados | Tienes actividad y ninguna forma de saber si funciona |
La cadena no se rompe de forma simétrica. Un dominio sin calentar tira la mejor secuencia que se te ocurra escribir; la mejor herramienta del mercado no calienta un dominio por ti.
La inversión de orden tiene una explicación sencilla, y no es que la gente sea ingenua. Alguien busca "mejor herramienta para cold email", compara dos o tres opciones por precio y capacidad, y firma doce meses antes de haber resuelto si sus dominios sostienen el volumen que planea mandar por ahí. Cuando el resultado no llega, la conclusión suele ser "la herramienta no sirve". Casi nunca era la herramienta.
Esto es la mitad de plomería del outbound. La otra mitad —qué le dices al prospecto y con qué ritmo le insistes— da por hecho que el correo llega a la bandeja principal. Aquí está lo que tiene que existir para que eso sea cierto, y con qué escala el costo de cada parte.
Dominios: cuántos necesitas y por qué uno no alcanza
La distinción que ordena todo lo demás es entre dos tipos de dominio:
- El dominio de marca es el que ya usas para correo corporativo: el que recibe facturas, el que usan tus ejecutivos para hablar con clientes actuales. De ahí no sale outbound frío.
- Los dominios secundarios absorben el riesgo de reputación de la prospección fría. Se compran para eso, se calientan para eso, y si uno cae en spam se reemplaza sin que nadie fuera del equipo de ventas se entere.
Aislar el riesgo así no es un truco para evadir nada: es una decisión de arquitectura, y la razón de fondo es que la reputación viaja con el dominio. Un dominio secundario quemado cuesta presupuesto y tiempo de calentamiento. Un dominio de marca quemado significa que el correo de facturación de tu empresa empieza a caer en spam para tus clientes actuales, y eso no se arregla comprando otro dominio.
¿Cuántos secundarios necesitas? No hay un número fijo: es tu volumen objetivo dividido entre lo que cada dominio calentado va a sostener, y ese divisor lo pone tu propio apetito de riesgo.
Si tu meta es enviar 3,000 correos al mes desde dominios secundarios y decides que cada dominio calentado sostiene 300 al mes:
3,000 ÷ 300 = 10 dominios secundarios.
Si el techo que aceptas por dominio es 500, la misma meta pide seis. El divisor es la decisión real; la división es aritmética.
Un dominio no es un buzón, y ahí es donde muchos presupuestos se descuadran: sobre cada dominio secundario montas varios buzones, y como la reputación es del dominio, el techo de volumen también es del conjunto. Sumar buzones sobre un solo dominio no multiplica tu capacidad de envío. Reparte el mismo techo entre más remitentes.
La autenticación resuelve tres preguntas distintas:
- SPF — quién tiene permiso de enviar correo en nombre de tu dominio.
- DKIM — si el mensaje llegó sin alterarse en el camino.
- DMARC — qué hacer cuando alguien falla las dos anteriores: rechazar, poner en cuarentena, o dejar pasar y solo reportar.
Sin las tres, ningún dominio tiene una base sobre la cual calentarse. Y cuando una de las tres se rompe en un dominio que ya venía funcionando, el síntoma llega antes que la causa: la tasa de apertura se cae de golpe y hay un orden barato para averiguar si fue esto, el volumen o la lista.
Este es también el punto donde más gente descubre la capa por el lado malo: cuando el aislamiento no existe, la consecuencia de una campaña agresiva no se queda en el dominio que la mandó. Se arrastra al correo corporativo completo, y quien se enoja no es el prospecto que no contestó, es Finanzas.
Buzones: de dónde salen y quién controla la reputación
Un buzón puede salir de tres lugares, y lo que cambia entre ellos es quién responde cuando uno se quema:
| Origen | Quién controla la reputación | Reemplazar uno quemado |
|---|---|---|
| Propio, sobre tus dominios secundarios | Tú, en todo | Lo que tardes en comprar y calentar otro |
| Revendido por un proveedor especializado | El proveedor, con su propio proceso de calentamiento | Rápido: es justamente lo que le compras |
| Híbrido: dominios tuyos, infraestructura del proveedor | Compartido | Rápido para el buzón; el dominio sigue siendo tu problema |
Detrás de cada buzón hay un proveedor de correo, y la elección entre Google Workspace y Microsoft 365 se toma con tres datos enfrente, los tres verificados en la página vigente del proveedor y ninguno de memoria:
- El límite de envío por buzón y, en el caso de Microsoft, también por organización.
- Cómo se comparte la reputación entre el proveedor y sus clientes.
- El costo por buzón al número de buzones que vas a operar, no al primero.
Microsoft documenta sus límites de envío saliente en Exchange Online (consultado el 2026-08-26) y advierte que no está diseñado para escenarios de correo masivo. Úsalo para confirmar los límites vigentes del proveedor antes de convertir una capacidad técnica en tu plan de volumen.
Los tres datos, resueltos a fondo y con la fila que casi todo el mundo lee mal: Google Workspace o Microsoft 365 para enviar outbound compara los límites publicados de los dos, y la diferencia real por buzón no es la que aparenta.
Ese último punto es el que más se subestima al presupuestar, porque el costo de esta capa escala con el número de buzones, no con el volumen de correos. Un equipo calcula cuánto le cuesta enviar 5,000 correos al mes y olvida que lo que paga cada mes es por buzón activo, se use al tope de su capacidad o a un quinto.
Hay una segunda cuenta que no es de dinero. Si tu meta pide 10 buzones y hoy tienes dos, comprar los ocho que faltan no los pone a enviar: cada uno entra a su propio calendario de calentamiento. Ese calendario, y no la fecha de compra, es lo que decide cuándo tu volumen real alcanza tu meta.
Y ese calendario no lo pone una tabla de correos por día copiada de un tercero: subes volumen solo cuando la semana que acabó no dejó ninguna señal roja, que es la regla de decisión que evita quemar un dominio nuevo justo en la semana dos.
La herramienta de envío: la decisión que menos debería tardarte
Con las tres capas anteriores resueltas, esta es la más fácil de las seis. Con las tres capas anteriores sin resolver, ninguna herramienta te salva. Por eso merece la menor parte del tiempo que normalmente se le da.
Lo que tiene que resolver es una lista de requisitos, no una lista de marcas:
- Rotación de buzones, para repartir el volumen en vez de saturar uno.
- Control de ritmo por buzón, para que cada uno respete su propio techo de calentamiento.
- Seguimiento de aperturas y respuestas, para saber qué pasó después de enviar.
- Pausa automática de la secuencia cuando alguien contesta, para no mandarle el correo 3 a quien ya te respondió el 1.
Donde sí vale la pena detenerse es en algo que casi nadie compara: el modelo de cobro cambia el cálculo más que el precio de lista. Una herramienta que cobra por buzón conectado y otra que cobra por contacto activo en secuencia producen presupuestos distintos con el mismo volumen de envío, y cuál sale más caro depende de cuántos buzones uses y cuántos contactos tengas corriendo a la vez. Comparar el número que aparece en la home es comparar el escenario de otro.
Antes de firmar doce meses hay una prueba de dos días que vale más que la comparativa entera: conecta dos buzones reales, manda un lote pequeño, contesta desde uno de los destinos y comprueba que la secuencia de ese contacto se detuvo sola. Si eso falla con dos buzones, va a fallar con diez, y la diferencia es que con diez ya no lo vas a notar.
Y sí hay un caso en que la herramienta es el problema de verdad, aunque sea el menos común: cuando ya no aguanta el número de buzones que tu meta pide. Un stack de tres buzones cabe en cualquier cosa, incluso en el CRM que ya pagas. Uno de treinta necesita rotación real y control de ritmo por buzón, y ahí las herramientas empiezan a diferenciarse de verdad. La señal para migrar no es que apareció una opción más barata: es que tu volumen objetivo dejó de caber en la que tienes.
Cuando esa señal aparece, lo que está en riesgo no es el calentamiento —la reputación vive en el proveedor de correo, no en la plataforma de envío—, sino el registro SPF del dominio y el rastreo de quién ya te contestó. Migrar de herramienta de outbound sin perder la operación da el orden de corte, dominio por dominio, y el umbral de rebote con el que se apaga la anterior.
Datos: cómo entra un contacto antes de que valga algo
Dos preguntas se confunden todo el tiempo: de dónde sale el contacto y si el dato es correcto. La segunda es verificación y es la siguiente sección. Aquí entra la primera.
Las herramientas de enriquecimiento se dividen en dos categorías, que es distinto de un ranking:
- Las que orquestan varias fuentes con lógica condicional —Clay es el ejemplo—: tú decides qué proveedor consultar primero, qué hacer si no encuentra el correo, y a qué fuente caer después.
- Las que combinan una base de datos propia con el envío en la misma plataforma —Apollo es el ejemplo—: el dato y el canal de salida viven juntos, con menos configuración y también menos control sobre el orden de consulta.
Elegir entre las dos no es cuestión de preferencia, y el umbral se puede poner en números: cuándo alcanza el waterfall de Apollo y cuándo necesitas Clay depende de cuántos de tus campos de calificación caen fuera de correo y teléfono.
El sistema descrito en cómo triplicamos el pipeline con Clay y HubSpot usa exactamente esta capa: enriquecimiento antes de que el contacto entre al CRM.
El error que más créditos quema aquí es enriquecer antes de filtrar. Supongamos que tu ICP (perfil de cliente ideal) filtra un universo de 5,000 empresas por firmografía básica —industria, tamaño, geografía— y que tu criterio real de calificación —señales de contratación reciente, stack compatible, momento correcto— deja 1,000 con el problema que resuelves.
Enriquecer las 5,000 gasta créditos de 4,000 contactos que nunca vas a trabajar, para llegar al mismo resultado útil que enriquecer 1,000.
Filtrar primero se siente más lento porque exige tener escrito el criterio de entrada antes de tocar la herramienta. Enriquecer primero y calificar después no ahorra ese trabajo: lo paga en créditos.
Verificación: el paso que decide si tu dominio sobrevive la primera semana
Un rebote no es un correo que no llegó. Es una señal que el servidor del destinatario emite sobre ti, y es la parte de tu envío que el proveedor de correo ve con más certeza: antes de que nadie abra nada y antes de que a nadie le interese tu mensaje. Por eso verificar antes de mandar no es un paso opcional de calidad. Es infraestructura, con el mismo peso que la autenticación del dominio.
La guía oficial de Google para remitentes (Google, consultada el 2026-08-25) documenta que la autenticación y las prácticas de envío influyen en que un mensaje se limite, se bloquee o se marque como spam. Sirve como referencia operativa de esta capa, no como sustituto de medir tu propia lista.
Y hay una trampa que cuesta un dominio entero: un correo puede pasar la verificación de sintaxis —tiene arroba, tiene dominio, el formato es válido— y también la de que el dominio existe, y aun así rebotar. "El formato es válido" y "la cuenta existe hoy" son dos preguntas distintas. Una cuenta que existió el mes pasado y se dio de baja esta semana sigue teniendo formato válido. De ahí que ningún verificador, por sí solo, llegue a la certeza total, y de ahí que la práctica común sea una cascada: varios verificadores en orden, con corte por costo cuando el primero no puede confirmar.
La decisión de costo de esta capa no es cuánto cuesta verificar: es cuándo. Verificar por lote —solo lo que va a entrar a secuencia esa semana— cuesta lo mismo por contacto que verificar toda la base de una vez. La diferencia son dos cosas: los créditos que gastas en contactos que quizá nunca envíes, y que un contacto verificado hace tres meses no está verificado hoy. La gente cambia de trabajo entre tu compra de créditos y tu envío.
CRM: la capa que decide si algo de esto se puede medir
Un stack de outbound sin CRM integrado produce actividad —correos enviados— y ninguna visibilidad de resultado —reuniones agendadas, pipeline generado. Las cinco capas anteriores pueden estar perfectas y el equipo seguir sin saber si el sistema funciona, porque nadie conectó el dato de la secuencia con el dato del deal.
Hay dos direcciones que sincronizar, y confundirlas es el error más común de esta capa:
- De la secuencia hacia el CRM. Los eventos —abrió, respondió, rebotó— tienen que escribirse en el registro del contacto, no quedarse en el dashboard de la herramienta de envío.
- Del CRM hacia la herramienta de envío. El estado del contacto —ya es cliente, ya lo está trabajando un rep— tiene que impedir que ese contacto entre a una secuencia de outbound frío.
Un evento de la primera dirección se ve así:
{
"evento": "correo_respondido",
"contacto_id": "c_48213",
"buzon_origen_id": "buzon_02",
"secuencia_id": "seq_outbound_q3",
"timestamp": "2026-08-20T14:32:00Z"
}
Ese evento tiene que disparar tres cosas: escribir la actividad, escribir el timestamp, y —lo que casi nadie automatiza, y por eso el equipo lo acaba haciendo a mano— pausar la secuencia de ese contacto en la herramienta de envío.
En la dirección contraria, antes de meter un contacto a una secuencia nueva, la herramienta tendría que poder preguntarle al CRM en qué etapa está. Si la respuesta es "ya es cliente" o "ya lo está trabajando un rep", ese contacto no entra a outbound frío, sin importar que la lista lo haya calificado.
Lo que rompe el reporte no es la calidad del dato de origen, que puede estar impecable en los dos lados por separado. Es que la herramienta de envío diga que un contacto respondió y el CRM no tenga registro de esa respuesta. Dos sistemas con una versión distinta de lo mismo no te dan un número menos preciso: te dan dos números y ninguna forma de elegir entre ellos.
El caso de Clay y HubSpot que publicamos es esta capa funcionando integrada: Clay encuentra y personaliza, HubSpot cierra el loop sin que nadie actualice un deal a mano.
Cuánto cuesta esto junto, y qué decidir según tu caso
Los precios de cada proveedor cambian varias veces al año, así que lo que sirve de una guía no es la cifra de hoy: es saber con qué escala cada línea del presupuesto.
| Capa | Tipo de costo | Con qué escala |
|---|---|---|
| Dominios y hosting | Bajo, recurrente anual | Número de dominios secundarios |
| Buzones | Recurrente mensual | Número de buzones activos |
| Herramienta de envío | Recurrente mensual | Buzones conectados o contactos activos, según el proveedor |
| Datos (enriquecimiento) | Créditos | Volumen enriquecido |
| Verificación | Créditos | Volumen verificado |
| CRM | Según el plan | El plan que elijas, no tu volumen de outbound |
Dos de esas líneas se pagan aunque no mandes un solo correo ese mes —buzones y CRM— y dos solo se pagan si trabajas la lista —datos y verificación. Es la diferencia entre poder pausar un mes flojo y no poder.
Si prefieres que alguien lo construya y lo opere en vez de armarlo tú, la cuenta cambia de "cuánto cuesta el stack" a "cuánto cuesta cada cita con un decisor": las herramientas siguen escalando como dice la tabla, y lo que se paga encima es el trabajo de operarlas y de trabajar las respuestas. Improvitz, consultoría de prospección B2B con IA en México, cotiza eso sobre el mercado y el volumen de cada empresa, no con una tarifa publicada; el diagnóstico inicial es donde se hace esa cuenta con tus números.
Qué decidir según dónde estés:
- Si nunca has mandado outbound en serio: un dominio secundario, pocos buzones y la herramienta más simple que cumpla los cuatro requisitos de arriba. La capa que menos importa es también la más fácil de cambiar después, así que no tiene sentido optimizarla primero.
- Si ya tienes volumen y no sabes si funciona: lo que falta no son más dominios, es el CRM integrado. Sin esa visibilidad no hay forma de saber cuál de las otras cinco capas está fallando de verdad.
- Si heredaste un stack que alguien armó por partes: cuenta desde cuántos dominios y cuántos buzones sale tu volumen actual, y divide. Si el número no cuadra con tu meta del trimestre, ya sabes qué capa te falta, y no es la herramienta.
Esa última cuenta es media hora de trabajo con datos que ya tienes, y es el mejor uso de tu tiempo esta semana. Si te sale rara y prefieres que alguien la revise con tu operación enfrente, el diagnóstico inicial —sin costo, 10 días hábiles— mira exactamente eso: qué capa de tu stack está incompleta, antes de que gastes en la equivocada.
Con el stack armado, la pregunta cambia de "con qué lo mando" a "qué le digo". Y ahí empieza la anatomía de un outbound por correo que sí obtiene respuesta.
