Migrar de herramienta de outbound no reinicia el calentamiento de tu dominio. La reputación de envío la llevan Google Workspace o Microsoft 365. La herramienta (Instantly, Smartlead o la plataforma que estés dejando) solo se conecta a un buzón que ya existe.
Lo que sí se rompe si lo haces mal son dos cosas concretas: el registro SPF (un dominio admite un solo registro, así que se fusiona en vez de duplicarse) y el rastreo de quién ya respondió en la herramienta vieja.
La regla de corte: migra dominio por dominio, corre las dos herramientas en paralelo, y apaga la anterior en ese dominio solo cuando la semana que acaba de correr cerró por debajo de 2% de rebote.
¿Se reinicia el calentamiento de mi dominio si cambio de herramienta?
No, porque la reputación del dominio y del buzón vive en el proveedor de correo, no en la plataforma de envío. Instantly conecta las cuentas por OAuth cuando el proveedor es Google Workspace o Microsoft 365, y exige IMAP y SMTP configurados a mano para cualquier otro (Instantly Help Center, "How to connect your email accounts to Instantly", consultado el 2026-09-09). La herramienta se autentica contra un buzón que ya existe; en ningún momento le pide al dominio empezar de cero.
Hay dos métricas que se confunden todo el tiempo:
- La reputación real es la que mide el proveedor de correo (lo que ves en Google Postmaster Tools o en el equivalente de Microsoft) y depende de cuánta gente abre, responde o marca como spam, acumulado durante meses.
- El warmup score del dashboard es una métrica propia de cada plataforma, calculada con su propia red de calentamiento. Arranca en cero en cuanto conectas el buzón ahí, aunque el dominio lleve medio año caliente.
Perder el warmup score no cuesta nada, pero perder el SPF sí. Si no tienes claro qué es un dominio secundario frente al dominio de marca, la capa de dominios de infraestructura de outbound: el stack completo lo cubre. Y los límites de envío por buzón siguen siendo los del proveedor después de migrar: Google Workspace o Microsoft 365 para enviar outbound compara los dos.
¿Se migra igual una herramienta de envío que una de datos?
No: cambian tanto lo que se exporta como lo que hay que rehacer a mano.
| Capa que migras | Se exporta | Se reconstruye a mano |
|---|---|---|
| Envío (Instantly, Smartlead, Lemlist) | Buzones conectados, el texto de cada correo, el estado de cada contacto (abierto, respondido, rebotado) | La lógica de ramas de la secuencia: "si abrió el correo 2 y no respondió, manda el 3 en 3 días" |
| Datos y enriquecimiento (Apollo, Clay) | El CSV de contactos ya enriquecidos: nombre, correo verificado, cargo, empresa | El waterfall completo: orden de proveedores y condiciones de fallback |
El trabajo real está en la columna de la derecha. La lógica de ramas de una secuencia no viaja como configuración portable entre plataformas, y ningún formato de exportación captura una cascada de enriquecimiento: cada herramienta arma las suyas distinto. Presupuesta esas horas.
Si el motivo real para migrar es de datos (cobertura de la lista, costo por contacto) y no de envío, cambia solo esa capa: la decisión la resuelve cuándo Apollo alcanza y cuándo necesitas Clay. Y si de verdad tienes que cambiar las dos, no en el mismo mes: cuando algo se rompe la primera semana, no vas a saber cuál de las dos fue.
¿Qué hay que tocar en el DNS antes de conectar la herramienta nueva?
El registro SPF que ya existe, para fusionarlo con el de la herramienta nueva. Google Workspace lo documenta así: "Cada dominio puede tener un registro SPF, pero este puede especificar servidores y terceros adicionales que pueden enviar correos electrónicos desde tu dominio" (Google Workspace, "Acerca de los registros SPF", consultado el 2026-09-09).
Publicar un segundo registro TXT de SPF en vez de editar el que ya está rompe el SPF del dominio entero. El estándar es explícito: si la consulta devuelve más de un registro, la verificación termina en permerror (RFC 7208 § 4.5, 2014). Y el registro fusionado tiene techo: 10 mecanismos que consultan DNS (include:, a, mx, exists), así que apilar herramientas puede tumbar el chequeo aunque el TXT se vea bien escrito.
Fusionar mal el SPF dejó de ser un detalle desde el 1 de febrero de 2024: Google exige SPF o DKIM más DMARC en el dominio de envío a quien mande más de 5,000 mensajes diarios a cuentas de Gmail, y una tasa de spam por debajo del 0.30% en Postmaster Tools (Google, "Directrices para remitentes de correo", consultado el 2026-09-09). Un stack con dominios secundarios casi nunca llega a ese volumen por dominio, pero el criterio de autenticación con el que te miden es ese, y un SPF invalidado a media migración lo falla completo.
El orden, en tres pasos:
- Edita el registro SPF existente y agrégale el
include:de la herramienta nueva. Nunca crees un segundo. - Publica el selector DKIM de la plataforma nueva. DKIM no se comparte: cada herramienta firma con su propia clave, así que necesita su propio selector además del SPF ya fusionado. Son dos cambios distintos.
- Verifica que el TXT ya resuelve con el valor fusionado antes de conectar el primer buzón de prueba. Los cambios de DNS tardan en propagarse y ese día perdido es más barato que el diagnóstico de por qué no llega nada.
Sesgo de las fuentes: la documentación de Instantly y la de Smartlead describen cada una su propio flujo de conexión como el simple, y ninguna cubre qué pasa cuando el SPF que ya está publicado es de un competidor. Por eso el mecanismo se cita del estándar y de Google Workspace, no del vendor.
¿Migras todo de un jalón o dominio por dominio?
Dominio por dominio. La unidad de riesgo en outbound es el dominio, porque todos los buzones de un mismo dominio comparten reputación. Migrar todos los buzones de todos los dominios el mismo día multiplica cuántas cosas pueden salir mal a la vez y no deja ninguna forma de aislar cuál fue.
El ejemplo, con números: un stack de 10 buzones repartidos en 2 dominios, 5 buzones cada uno. Migras el dominio A completo (sus 5 buzones), lo corres en paralelo con la herramienta anterior y solo cuando ese dominio no muestra señal roja apagas ahí la vieja. Después repites con el dominio B. Nunca los dos el mismo día.
Dentro de un mismo dominio, en cambio, sí conviene mover los buzones juntos. Están bajo el mismo SPF y el mismo DKIM ya fusionados, así que probar buzón por buzón no aísla ningún riesgo adicional: solo alarga la migración.
¿Cuánto tiempo corres las dos herramientas en paralelo?
Hasta que la semana que acaba de correr en el dominio migrado cierre por debajo de 2% de rebote. No antes, aunque la herramienta nueva se vea impecable desde el primer día.
Ese 2% es el umbral operativo que Improvitz usa como señal roja en su propia operación de envío en México, donde dos campañas propias corrieron con 1.79% de rebote sobre 4,804 correos (industria, 1,657 empresas) y 1.40% sobre 9,211 correos (software, 3,162 empresas), en la ventana de mayo a agosto de 2026. Un rebote por encima de 2% en la primera semana con la plataforma nueva señala que algo de la conexión (autenticación, lista, configuración del envío) no quedó bien.
La cuenta completa: si el dominio A tarda 2 semanas en entregar una semana limpia y el dominio B otras 2 después de empezar su traslape, migrar los 10 buzones toma 4 semanas y cuatro semanas de dos licencias corriendo a la vez. No es un fin de semana. Tampoco exige reiniciar el calentamiento, porque el dominio ya está caliente y lo único que se prueba es la conexión.
Durante el traslape, la lista de contactos activos se reparte entre las dos herramientas sin duplicarse. Un contacto que ya está en secuencia sigue en la vieja hasta que su secuencia termina o hasta el día del corte de ese dominio. Subir el mismo contacto a las dos plataformas es mandarle el mismo correo dos veces desde dos remitentes distintos.
Esa redundancia —dos licencias, dos syncs, a veces un webhook de respaldo— es transitoria a propósito. El plan de migración incluye apagar los syncs de seguridad cuando el dominio ya cerró limpio; no dejarlos eternos "por si acaso". Una red de seguridad que nadie programa para retirar se vuelve deuda operativa: dos fuentes de verdad otra vez, y el mismo riesgo que venías a cerrar.
Para el criterio completo de qué más cuenta como señal roja además del rebote (quejas de spam, caída de apertura), cómo calentar un dominio nuevo sin quemarlo en la semana dos usa la misma lógica de comparar contra tu propia semana anterior.
¿Qué pasa con quien ya respondió o está a media secuencia?
Se exporta la lista completa de quienes abrieron, respondieron o rebotaron en la herramienta vieja y se sube a la nueva como lista de exclusión, antes de cargar un solo contacto. Si te saltas ese paso, el correo 1 de la secuencia nueva le llega a alguien que ya contestó el correo 3 de la anterior.
Eso incluye el DNC y cualquier lista legacy de no-contactar. Migrar sin ownership claro —quién carga el DNC al sistema nuevo, y qué pasa con las listas que quedaron fuera— produce incendios de compliance, no “detalles de cutover”. Nombra al dueño de la carga antes de apagar la herramienta vieja; si las listas legacy no entran al sistema nuevo el día del corte, asume que van a reaparecer como contactos tocados dos veces.
Un contacto a media secuencia no se transfiere "a la mitad": nadie exporta "está en el paso 2 de 5, esperando 3 días más". Solo hay dos rutas, y las dos son aceptables:
- Termina su secuencia en la herramienta vieja, que sigue corriendo mientras dure el traslape.
- Se reinicia como contacto nuevo en la plataforma nueva, desde el correo 1.
Los rebotes ya registrados se suben también como exclusión, junto con quien respondió. Reintentar un rebote duro de entrada sube el rebote de la conexión nueva contra ese umbral de 2%.
La sincronización con el CRM se reconfigura antes del primer envío, no después: es la misma lógica que describe la capa de CRM del stack completo de infraestructura de outbound: que nadie reciba un correo de secuencia si ya está en conversación activa.
Cuándo no migrar todavía
No es el momento si el problema real es el volumen o la calidad de la lista. Cambiar de plataforma de envío no arregla un problema de datos ni de copy: pagas el tiempo del equipo, las semanas de traslape y dos licencias simultáneas, y la causa sigue ahí.
Tampoco si hay una campaña con volumen alto corriendo esta semana. Espera a que termine o pausa antes de tocar el DNS de producción. Modificar el SPF a media campaña añade una variable a un sistema en movimiento: si algo sale mal, no vas a poder separar el cambio de DNS del ritmo de envío.
Y no migres dos dominios a la vez si nadie va a revisar el rebote diario durante el traslape. El umbral de 2% es una señal y no una alarma automática, así que no sirve como regla de decisión si nadie lo mira.
Migrar sin resolver esto solo muda el problema de herramienta, y mientras tanto pagas dos licencias por algo que la plataforma nueva tampoco va a arreglar.
¿Qué revisas la primera semana después del corte?
Lo mismo que usaste para decidir el corte: rebote, quejas de spam y tasa de apertura, comparados contra tu propia semana anterior y no contra un promedio de la industria. Si el rebote se mantiene por debajo de 2% y la tasa de spam en Google Postmaster Tools no pasa del 0.30%, ese dominio quedó migrado y puedes empezar con el siguiente.
Si algo sube, el problema casi siempre está en la conexión: SPF mal fusionado, DKIM sin propagar, o una lista subida sin pasar por el filtro de exclusión. Ese es el orden en que se revisa, y es el mismo con el que se diagnostica una tasa de apertura que cae de golpe.
Improvitz, consultoría de prospección B2B con IA en México, aplica este orden de corte (dominio por dominio, con el rebote como señal) dentro del método IMPRO (Investiga, Mensajes que llegan, Personalizados, Respuestas, Oportunidades). Esta pieza cubre la "I": dejar la infraestructura verificada antes de que salga un solo correo nuevo.
El paso del lunes es corto: cuenta cuántos dominios tienes y cuántos buzones cuelgan de cada uno. Ese número te dice cuántas semanas de traslape vas a pagar. Si prefieres que alguien revise el plan de corte antes de que toques el DNS de producción, agenda un diagnóstico.
Nota: los resultados citados corresponden a implementaciones concretas, con su propio punto de partida, equipo y stack. No son una proyección de lo que va a pasar en otra empresa. Este artículo describe cómo se construyó el sistema, no promete su resultado.
