Separación de dominios para equipos de cold email — cómo aislar el cold de la marca principal sin perder credibilidad

El dominio principal de una empresa es activo de marca y reputación construido durante años. Usarlo para cold email es exponerlo a riesgo desproporcionado: cualquier complaint o blacklist generado por cold contamina la reputación del dominio entero, afectando emails transaccionales legítimos, marketing opt-in y comunicaciones internas. La práctica establecida en programas cold serios es separar arquitectónicamente: dominios secundarios específicos para cold, dominio principal protegido. Este post cubre cómo se diseña esa separación correctamente.

Por qué la separación es no opcional

El argumento técnico es directo. Los receptores (Gmail, Microsoft, Yahoo) evalúan reputación en varios niveles: IP, dominio del From, subdominio. Cuando emails desde su-empresa.com generan complaints, esa señal afecta a TODO email enviado desde su-empresa.com — incluyendo notificaciones transaccionales, marketing opt-in legítimo, comunicaciones de servicio crítico.

El cold email tiene perfil de complaints inherentemente más alto que transaccional. Receptores que no esperaban el mensaje son más propensos a marcar como spam. Tasa de complaints de programa cold bien hecho: 0.3-0.6% (vs 0.05% en transaccional). Tasa de programa mal hecho: 1-2%+. Ambos rangos son material para la reputación del dominio.

Si el dominio principal su-empresa.com tiene reputación 99% inbox placement actualmente, después de 6 meses de cold contaminando su reputación puede caer a 75-85% — pérdida sustancial que afecta el activo de marca. Recuperar esa reputación lleva meses. Mientras tanto, transaccional crítico (password resets, confirmaciones de pago) llega a spam más frecuentemente, generando tickets de soporte y churn medible.

La separación arquitectónica elimina este riesgo. Cold envía desde dominios secundarios cuyo único propósito es cold. Si su reputación se deteriora, no afecta al dominio principal. Si se queman irrecuperablemente, se reemplazan con dominios nuevos sin afectar al activo de marca.

Patrón típico de naming de dominios secundarios

Los dominios secundarios deben ser plausibles para receptores y filtros. Tres patrones funcionan bien:

Variante de TLD del dominio principal: si la empresa es su-empresa.com, dominios secundarios como su-empresa.io, su-empresa.co, su-empresa.net. Mantienen relación visual con la marca, son plausibles operativamente. Coste: 10-30 EUR/dominio/año.

Subbrand-like names: variantes que evocan equipo o función específica. su-empresa-team.com, su-empresa-outreach.com, get-su-empresa.com, hello-su-empresa.com. Algo más distantes del dominio principal pero clarmente identificables.

Función-específicos sin marca: dominios sin mención directa de la marca pero con propósito claro. growth-leads.com, b2b-connect.io, business-outreach.net. Para programas cold a gran escala donde se rotan dominios cada 6-12 meses, este patrón puede ser preferible — protección máxima de marca pero más fricción para que el receptor identifique al sender legítimo.

El número típico de dominios para programa serio: 3-8 dominios secundarios activos simultáneamente. Permite distribuir volumen, rotar si alguno tiene problemas, y experimentar sin afectar al resto.

Configuración técnica de cada dominio secundario

Cada dominio secundario debe tener configuración técnica completa. Lista de verificación:

1. MX records configurados para recibir replies. Esto es crítico — un dominio sin MX es señal típica de spammer (envía pero no puede recibir). Configurar MX que apunte a buzón monitoreado activamente. El equipo debe procesar replies dentro de minutos para casos donde el prospect quiere responder.

2. SPF correctamente configurado. Incluir las IPs del proveedor de envío. Política conservadora ~all durante warming, cambiar a -all tras 4-6 semanas estable.

3. DKIM con clave 2048 bits propia. No usar la clave default del proveedor. Generar par específico, publicar en DNS bajo selector identificable. Esto es crítico para alignment DMARC.

4. DMARC en p=none inicialmente. Empezar en modo monitoreo durante 4-6 semanas. Tras estabilidad, mover a p=quarantine con pct gradual. Para cold, p=reject puede ser objetivo final aunque algunos operadores prefieren mantenerse en quarantine.

5. Reverse DNS de las IPs apuntando al dominio del sender. Las IPs que envían desde get-su-empresa.com deben tener PTR record que apunte a algo identificable como get-su-empresa.com. Receptores verifican.

6. Página web mínima viable en el dominio. El dominio que solo tiene MX y nada en HTTPS es señal sospechosa. Página simple con identificación del equipo, política de privacidad, dirección postal. No tiene que ser sofisticado — solo presente.

7. WHOIS con información identificable. La empresa registrada no anónima. Receptores y filtros consultan WHOIS para evaluar legitimidad.

8. Dominio "envejecido" antes de uso. Idealmente, dominio registrado con 30-90 días de antelación al primer envío. Dominios recién registrados ese mismo día son señal de spammer típica. Si no es posible esperar, comprar dominio con histórico previo (servicios de aged domains existen pero requieren due diligence).

Pattern operativo: cómo se asignan a senders del equipo

Tres modelos de asignación de dominios a senders individuales del equipo:

Modelo A — un dominio por sender. John envía desde get-su-empresa.com (john@get-su-empresa.com). María desde hello-su-empresa.com (maria@hello-su-empresa.com). Sergio desde su-empresa-team.com. Cada sender opera en su dominio dedicado. Si John tiene problemas de deliverability, no afecta a María. Aislamiento máximo. Coste mayor (más dominios, más mantenimiento).

Modelo B — varios senders por dominio. Tres senders comparten get-su-empresa.com (john@, maria@, sergio@get-su-empresa.com). Otros tres comparten hello-su-empresa.com. Eficiencia operativa mayor (menos dominios), pero un sender problemático puede afectar a los otros del mismo dominio.

Modelo C — rotación dinámica. Pool de 5-8 dominios, asignación de remitente a dominio cambia mensualmente o por campaña. Más complejo de operar pero distribuye carga reputacional dinámicamente.

Para equipos pequeños (1-3 senders activos), Modelo A es típicamente correcto. Para equipos medianos (4-10 senders), Modelo B es común. Para equipos grandes con automatización compleja, Modelo C aporta valor pero requiere tooling.

Disciplina de capacidad por dominio

Cada dominio tiene capacidad sostenible limitada. Recomendación operativa para programa cold serio:

• 50-150 mensajes diarios por sender en el dominio (durante operación estable, post-warming)
• 500-1.000 mensajes diarios por dominio total (suma de todos los senders del dominio)
• Spread temporal del envío: no todo en una hora, distribuir a lo largo de 8-12 horas del día laboral del receptor
• Pausas semanales: viernes tarde y fin de semana sin envío (los receptores ven envíos a esas horas como sospechosos)

Programas que intentan exceder estos volúmenes por dominio típicamente disparan filtros de Gmail/Microsoft tras pocas semanas. La disciplina de respetar la capacidad por dominio es lo que permite operación sostenida.

Plan de rotación y reemplazo

Los dominios secundarios eventualmente se queman. Algunos por errores operativos (lote de lista mal limpia generando bounces), otros por evolución natural de receptores que aprenden a clasificar mejor. La planificación correcta asume rotación.

Práctica típica: mantener 1-2 dominios "frescos" en warming continuo además de los activos. Cuando un dominio activo muestra signos de degradación irrecuperable (Gmail reputation cae a Bad sostenido, blacklist persistente, complaint rate sobre 1.5% durante semanas), retirarlo y promover uno fresco al pool activo.

El ciclo completo de vida de un dominio cold serio: 12-24 meses típicamente. Los registros se mantienen activos pero con pause de envío para preservar opción de reactivar más adelante. Los senders del dominio retirado se reasignan a dominios activos.

Esta rotación planificada evita el "tras 6 meses todo se quema simultáneamente". Distribuir warming y retirada en el tiempo da continuidad operativa al programa entero.

El argumento de marca que muchos equipos pasan por alto

Hay un beneficio adicional de la separación de dominios que el análisis técnico no captura: protege la marca de exposición negativa explícita. Cuando un prospect recibe cold de get-su-empresa.com, sabe que es outreach. Si lo molesta, su frustración es contra get-su-empresa.com, no contra su-empresa.com (su producto principal). El cliente de su-empresa.com que algún día entra al sales pipeline no asocia la marca con cold molesto previo.

En contraste, cuando todo viene de su-empresa.com — cold, transaccional, marketing — el prospect que se molestó por cold puede generalizar a "esta empresa hace email spam" y la decisión futura de comprar el producto se ve afectada. Es daño de marca medible aunque difícil de cuantificar.

La separación arquitectónica es práctica madura del sector. Los programas cold serios la implementan desde día 1. Los programas que la postergan acaban implementándola tras experimentar el daño que evita — proceso reactivo más caro y más lento.