El playbook de infraestructura para cold email
Si sus emails no llegan a la bandeja principal, nada más importa en outbound. La copy no lo salva. La IA no lo salva. Solo lo salva una infraestructura autenticada, diversificada y con rotación.
Este es el patrón que vemos cada semana. Un equipo compra 120 inboxes en 40 dominios a un reseller. Hace warmup durante dos o tres semanas. Lanza campañas. Cero respuestas, ni siquiera avisos de out-of-office. Entra en pánico. Cambia la copy. Sigue sin pasar nada. A las seis semanas la deliverability se hunde por completo. Se desecha la infraestructura y se empieza de cero.
Nueve de cada diez veces, el problema es la infraestructura, no la copy. Una copy “mala” enviada sobre una infraestructura bien autenticada se entrega. Una copy “buena” enviada sobre una infraestructura rota, no. El encuadre y la autenticación importan 10 veces más que las palabras spam.
El triángulo de autenticación: SPF, DKIM, DMARC
Cada dominio de envío en frío necesita tres registros DNS, configurados de forma alineada. Si falta alguno o está mal configurado, la deliverability se desploma.
SPF (Sender Policy Framework)
SPF indica a los servidores de correo receptores qué IPs están autorizadas a enviar desde su dominio. Un registro SPF estándar de Google Workspace se ve así: v=spf1 include:_spf.google.com ~all. La regla crítica: la dirección de retorno (envelope-from) debe coincidir con la dirección del remitente para que SPF pase; esto se llama alineación SPF. El reenvío rompe la alineación, y por eso una dirección “reply-to” distinta en una campaña en frío suele hundir la deliverability.
DKIM (DomainKeys Identified Mail)
DKIM es una firma criptográfica, el sello postal que demuestra que el mensaje salió realmente del dominio que dice haberlo enviado. Google Workspace genera la clave DKIM en la consola de administración; usted la copia en el DNS como registro TXT. Microsoft 365 funciona de forma similar. Compruebe que pasa enviándose un email a su propia cuenta de Gmail y usando “Mostrar original”: SPF, DKIM y DMARC deberían mostrar PASS.
DMARC (Domain-based Message Authentication)
DMARC es la política que indica a los receptores qué hacer cuando SPF o DKIM fallan. Las tres políticas son none, quarantine y reject. La mejor práctica para el envío en frío es:
v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; sp=none
p=reject es el estándar de oro una vez que SPF y DKIM pasan. Obliga a tener una infraestructura limpia: nada sin autenticar llega a destino. Incluir rua= (URI de informes agregados) significa recibir informes diarios sobre quién intenta enviar en su nombre. Omitir rua= es un error típico de principiante; sin él, vuela a ciegas.
Error de configuración habitual: activar p=reject antes de verificar que SPF y DKIM pasan. Si la autenticación falla, su propio correo nunca llega a su bandeja principal. Envíe una prueba a mail-tester.com, confirme el 10/10 y revise “Mostrar original” en Gmail hasta ver SPF/DKIM/DMARC en PASS antes de endurecer DMARC.
Warmup de dominios: 28 días, no dos semanas
Los dominios nuevos necesitan un mínimo de 28 días de warmup antes de lanzar campañas reales. Dos semanas no bastan. Tres semanas es el mínimo para resultados marginales. Con cuatro semanas, los reply rates se estabilizan.
Herramientas de warmup: Warmup Inbox, Warmbox, Warmforge, Mailwarm, Folderly, Mailreach y Warmy simulan conversaciones para construir la reputación del dominio. Use una que se integre con su sequencer. Durante el warmup, los health scores del inbox deberían subir desde cero hacia 80-100. Si tras tres semanas con dominios nuevos siguen por debajo de 20, algo está roto antes en la cadena, normalmente el bloque de IPs del reseller o un error de configuración DNS.
Lo que el warmup hace de verdad: demuestra que su dominio tiene tráfico de email legítimo y de apariencia humana. Lo que no hace: compensar una mala copy, listas sin verificar o un registrar de dominios que figura en una blocklist de spam.
Placement testing, proveedor por proveedor
Cada proveedor de email aplica sus propios criterios de entrega. El filtro de spam de Google no es el de Microsoft 365. Mimecast, Barracuda y Proofpoint (antispam enterprise) clasifican cada uno a su manera. Un placement test le dice qué proveedores entregan en el inbox y cuáles ponen el correo en cuarentena, antes de desperdiciar una campaña con una audiencia que nunca la verá.
Herramientas que usamos:
- mail-tester.com: health score básico, revisión de palabras spam, verificación de autenticación
- Folderly, placement testing completo más monitoreo continuo de la deliverability
- GlockApps, inbox placement detallado por proveedor
- Emailguard / Mailreach / Warmy, monitoreo continuo del placement
- Inbox Placement (Smartlead), el chequeo rápido más barato
Haga placement tests sobre la infraestructura nueva antes de salir en vivo y repítalos cada dos semanas. La deliverability se degrada con el tiempo: un dominio que entra en el inbox en la semana cuatro puede estar en cuarentena en la semana ocho. Detéctelo pronto y rote antes de que mueran las respuestas.
El stack multi-ESP y multi-registrar
El estándar de oro en 2026: dos registrars de dominios y dos ESPs (Google Workspace + Microsoft 365), como mínimo. Tres de cada uno a escala real. El razonamiento es simple: un único punto de fallo mata todo el pipeline. Cuando Google da de baja a un reseller de zona gris o Microsoft endurece sus cuotas, usted rota a su segundo stack mientras arregla el primero.
Así se ve en la práctica para un equipo que envía más de 100.000 emails al mes:
- Lote 1: 30 dominios en el registrar A, Google Workspace, sequencer 1: envía durante dos semanas y luego descansa
- Lote 2: 30 dominios en el registrar B, Microsoft 365, sequencer 2, envía mientras el lote 1 descansa
- Lote 3: reserva de reemplazo inmediato: con warmup previo, lista para desplegar cuando cualquiera de los dos lotes se queme
Por eso las agencias que operan más de 100 inboxes sin rotación ven caer la deliverability en picado cada seis semanas. Queman un stack tras otro. La rotación reparte el desgaste y prolonga la vida útil de la infraestructura.
Nombres de dominio: solo letras, .com o .co, sin excepciones
Los administradores de sistemas de las cuentas enterprise objetivo bloquean activamente los TLDs inusuales y los dominios de aspecto sospechoso. Su dominio de envío debe parecerse exactamente a un dominio corporativo normal en el que un sysadmin confiaría a primera vista.
- Use: .com, .co y TLDs geográficos (.de, .nl, .fr, .uk) para campañas locales
- Evite: .xyz, .online, .site, .tech, .info, .biz, todos marcados por los filtros enterprise
- Evite: números (company1.com), guiones (get-company.com), patrón de phishing
- Prefiera: variantes solo con letras (trycompany.com, hqcompany.com, getcompany.com, usecompany.com, joincompany.com)
Su dominio principal nunca debe usarse para envíos en frío: el riesgo reputacional es demasiado alto. Use dominios look-alike comprados sobre una infraestructura separada y mantenga limpio su dominio principal para la comunicación con clientes.
Dos inboxes por dominio, no tres
Datos de deliverability de miles de setups de envío en frío: dos inboxes por dominio en Google Workspace rinden más que tres. Más inboxes por dominio no significa más throughput, significa más riesgo cuando un dominio se quema. Quince dominios con dos inboxes cada uno (30 buzones) superan en deliverability a diez dominios con tres inboxes cada uno (30 buzones).
Palabras spam e higiene de la copy
Las listas de palabras spam están sobrevaloradas. El encuadre y la infraestructura importan 10 veces más. Dicho esto, no llene un mensaje a propósito de “gratis”, “garantía”, “urgente”, “actúe ya” o el típico lenguaje de vendedor. Use el spam checker de Mailmeteor o el word checker de Folderly para una revisión rápida.
Más importante que las palabras sueltas:
- Mantenga los cold emails por debajo de 50-60 palabras (los datos de copy de Leadbird muestran de forma consistente que lo corto se entrega mejor)
- No incluya HTML, CSS ni píxeles de tracking en el primer contacto: gana el texto plano
- Nada de links en el primer email salvo que tenga una razón excepcional
- Un CTA, no tres
- Spintax o variantes generadas con IA en cada línea para evitar el fingerprinting por patrones
Lo que construimos para nuestros clientes
Un engagement típico de deliverability:
- Auditoría de la flota de dominios existente, los registros de autenticación, los pools de warmup y el placement
- Setup de una arquitectura multi-ESP y multi-registrar dimensionada al volumen
- Configuración de SPF, DKIM y DMARC p=reject con reporting rua=
- Calendario de rotación (lotes 1/2/3) y reserva de reemplazo inmediato
- Cadencia de placement testing integrada (cada 2 semanas, con alertas automatizadas)
- Ingesta de las métricas de deliverability en HubSpot junto a los datos de secuencias y respuestas
- Formación de su equipo para operar el sistema y diagnosticar desviaciones
Plazo: de cuatro a seis semanas desde el contrato hasta el primer envío limpio, según el tamaño de la flota de dominios y el estado del warmup. Durante el warmup lanzamos campañas de LinkedIn y cold calling para que no tenga que esperar un mes para generar pipeline.
Arregle su deliverability antes de tocar la copy
Auditamos, reconstruimos y rotamos la infraestructura para que sus reply rates reflejen su oferta, no sus registros de autenticación.
Reservar una llamada