Fusiones y adquisiciones: consolidar los dominios de correo sin brechas de autenticación
Por Thomas · CISO virtual · 30 de agosto de 2026
En una operación de fusión o adquisición, el correo electrónico casi nunca entra en la data room. Los juristas desmenuzan los contratos, los equipos financieros reelaboran las cuentas, los equipos técnicos auditan el código y la infraestructura — pero nadie pide la lista de zonas DNS ni el estado de las políticas DMARC de la empresa adquirida. El día del cierre, el comprador se convierte sin embargo en responsable de un patrimonio que no construyó: decenas de dominios de correo acumulados a lo largo de marcas, filiales y compras anteriores, con un nivel de autenticación perfectamente heterogéneo.
El asunto va más allá de la deuda técnica. El periodo de integración es precisamente aquel en el que la suplantación de identidad más rinde: la operación se anuncia públicamente, las direcciones cambian, los reenvíos se multiplican y cada empleado espera recibir mensajes inusuales de interlocutores aún desconocidos. Los defraudadores leen la prensa económica — desde su punto de vista, un comunicado de compra es un calendario de ataque.
Esta guía despliega el método para atravesar la operación sin abrir una brecha de autenticación: la due diligence de correo antes de la integración, la protección del periodo de transición, la estrategia de consolidación de los dominios, la gobernanza del DNS tras la fusión y el destino de los dominios heredados que no volverán a enviar jamás.
Lo que una adquisición trae de verdad: un parque de dominios desconocido
Sobre el papel, la operación afecta a una empresa y a su dominio principal. En la práctica, la adquirida llega con un parque entero: los dominios de las marcas comerciales, las variantes locales de las entidades por país (.de, .es, .co.uk), los dominios históricos de las sociedades que ella misma había absorbido una década antes, los nombres defensivos registrados contra el typosquatting, los dominios de campaña creados por marketing para un lanzamiento y nunca retirados, y una larga cola de nombres aparcados cuyo origen ya nadie recuerda.
El nivel de autenticación de ese parque es heterogéneo sin excepción. Un dominio principal a veces bien configurado; unos cuantos p=none publicados un día sin que nadie leyera después los informes; registros SPF contradictorios, retocados por proveedores sucesivos; selectores DKIM que apuntan a plataformas dadas de baja hace años; y una mayoría de dominios sin ningún registro. Peor aún: la lista de los juristas — marcas registradas, nombres renovados en el registrador — solo coincide parcialmente con la realidad operativa. Hay zonas DNS que viven en un segundo registrador, abiertas por una agencia local, a veces bajo una cuenta personal.
El error clásico consiste en ocuparse solo del dominio principal de la adquirida y descubrir el resto del parque incidente a incidente. El enfoque sólido invierte el problema: primero inventariar, después decidir.
La due diligence de correo: tres inventarios antes de integrar
Idealmente, esta due diligence se realiza antes del cierre, al mismo nivel que la auditoría de seguridad; en su defecto, abre las primeras semanas de la integración. Se resume en tres inventarios.
El primero es el propio parque de dominios: qué nombres, en qué registradores, bajo qué cuentas, renovados por quién y hasta cuándo. La contabilidad de proveedores de la adquirida (facturas de renovación) y una búsqueda por titular completan útilmente la lista oficial — ahí es donde suelen aflorar los dominios abiertos por una filial o una agencia.
El segundo es el estado de autenticación, dominio por dominio: presencia y contenido del SPF, selectores DKIM activos, registro DMARC y su política, MX y — señal reveladora — la presencia de una dirección rua, que dice si alguien, algún día, miró los informes. Todo cabe en una tabla con una columna por mecanismo, que se convierte en el mapa de riesgo de la integración.
El tercero, el más largo, se refiere a los remitentes externos de la adquirida: CRM, facturación, nóminas, soporte, plataformas de marketing, herramientas de negocio que envían «en nombre de» sus dominios. El método es exactamente el del inventario de remitentes externos, con una dificultad propia de las fusiones: el ecosistema por cartografiar no lo conoce nadie en el equipo de integración, y las personas que lo conocían a veces dejan la empresa con la operación.
Un reflejo inmediato rinde mucho: publicar v=DMARC1; p=none; rua=mailto:… en cada dominio de la adquirida que no tenga nada. Un puñado de registros TXT basta para que los datos fluyan durante toda la integración — cuando lleguen las decisiones de consolidación, ya habrá semanas de informes disponibles.
El periodo de transición: el momento de máxima exposición
La transición suele empezar con una decisión de apariencia inofensiva: redirigir las direcciones de la antigua empresa hacia las nuevas. nombre.apellido@ejemplo.net se convierte en un reenvío automático hacia nombre.apellido@ejemplo.es, a menudo para cientos de buzones de golpe. Pero el reenvío SMTP clásico rompe SPF: cada mensaje que un tercero envía a la antigua dirección y que sale reenviado hacia la nueva falla la verificación a la llegada, porque la IP del servidor que reenvía no figura en el SPF del remitente original. DKIM sobrevive mientras el contenido no se modifique, y ARC ayuda en los grandes proveedores, pero un flujo masivo de reenvíos degrada mecánicamente la alineación, contamina los informes de ambos parques con falsos positivos — y pierde los mensajes de los remitentes en p=reject cuya firma DKIM no resiste.
El segundo riesgo pesa más: la suplantación oportunista. El anuncio de una fusión es público por construcción — nota de prensa, prensa especializada, registros mercantiles. El escenario más rentable es el fraude del cambio de datos bancarios: una factura con el aviso «a raíz de nuestra fusión, nuestras cuentas bancarias cambian», enviada a los proveedores y clientes de ambas entidades desde un dominio suplantado o parecido. Las condiciones son ideales: todo el mundo espera cambios, los circuitos de validación están desorganizados, los interlocutores aún no se conocen. Un dominio de la adquirida que permanezca en p=none durante esa ventana es una puerta abierta, en el peor momento posible.
El tercer riesgo es silencioso: la dilución de responsabilidades. Dos equipos informáticos coexisten, los perímetros se solapan y los informes agregados se quedan meses sin un lector asignado. La contramedida cabe en una decisión: designar, desde el día de la firma, un responsable único de la autenticación de correo de ambos parques, con todos los informes reunidos en un mismo lugar.
La estrategia de consolidación: qué dominio sobrevive
La primera decisión estructural es el dominio superviviente — casi siempre el del comprador, a veces el de la adquirida cuando se conserva su marca comercial. Cuando la marca debe sobrevivir sin su dominio, un subdominio de transición del dominio superviviente (marca.ejemplo.es) ofrece una vía limpia: la identidad visible se preserva, la autenticación queda bajo la política organizativa del grupo y solo queda un parque que gobernar. Después viene el calendario, en tres fases.
La doble vida. Ambos dominios envían en paralelo mientras migran los buzones y las herramientas, bajo vigilancia de los informes. Es la fase en la que los flujos aplicativos — facturación, CRM, notificaciones, nóminas — basculan uno a uno hacia el dominio superviviente, con la misma mecánica que una migración de proveedor de correo: fuente a fuente, nunca en big bang.
La congelación de envío. A partir de una fecha anunciada internamente, ningún envío legítimo sale ya del antiguo dominio. Los informes sirven entonces de prueba: unas semanas de volumen legítimo nulo confirman que la congelación es efectiva y que no queda ningún flujo olvidado. El modo de prueba de DMARCbis (t=y, sucesor del pct retirado del estándar) permite endurecer la política observando el efecto antes de hacerla definitiva.
El cierre. El SPF del antiguo dominio se reduce a v=spf1 -all, la política pasa a p=reject, completada en el dominio organizativo con sp=reject y con la etiqueta np= de DMARCbis, que cubre los subdominios inexistentes — valiosa en un dominio cuyo árbol histórico ya no se domina. La recepción, en cambio, puede continuar: conservar los MX durante años para no perder ningún mensaje dirigido a las antiguas direcciones es perfectamente compatible con rechazar la usurpación en el envío.
Gobernanza: de quién es el DNS después de la fusión
La pregunta parece administrativa; es estructural. Mientras las zonas DNS de la adquirida sigan en su registrador histórico, bajo las cuentas de sus antiguos proveedores, cualquier registro de autenticación puede modificarse fuera de todo control. El trabajo de gobernanza cabe en cinco puntos: consolidar las cuentas de registrador bajo la entidad que gobierna; revocar los accesos de agencias, proveedores y empleados salidos con la operación; poner las zonas bajo control de cambios, idealmente como infraestructura como código; nombrar un propietario por dominio; y centralizar la recepción de todos los informes en una misma herramienta multidominio.
El modelo objetivo es el de la gobernanza de una cartera multimarca: política central, ejecución delegada y ningún registro de autenticación modificado fuera del circuito. Los meses que siguen a una fusión son exactamente aquellos en los que un proveedor olvidado retoca un SPF «como antes» y rompe una alineación sin que nadie entienda de dónde viene el incidente — un registro al día de quién posee qué es el único antídoto.
El destino de los dominios heredados durmientes
Terminada la consolidación, queda la cola: las marcas abandonadas, los nombres de las sociedades absorbidas a lo largo de los años, conservados por propiedad intelectual o por simple prudencia. Esos dominios no volverán a enviar un correo legítimo — y sin embargo cada uno sigue siendo una identidad suplantable, con la historia y la credibilidad de una marca real.
El tratamiento es estándar y está detallado en la protección de los dominios aparcados: SPF reducido a v=spf1 -all, política p=reject — con una dirección rua, para ver cómo los intentos de suplantación siguen fracasando —, y MX nulo (RFC 7505) si el dominio ya no recibe nada. Dos rituales completan el dispositivo: en cada renovación, comprobar que el cierre sigue en su sitio; y antes de cualquier abandono previsto, recordar que un dominio caducado se puede comprar — resucitaría entonces, con veinte años de historia de marca, en manos de un desconocido.
En resumen
Una fusión o adquisición trae siempre un parque de dominios más grande, más viejo y peor autenticado de lo previsto. El método cabe en cinco tiempos: inventariar — dominios, políticas, remitentes externos de la adquirida — antes del cierre o justo después; publicar p=none y direcciones de informe allí donde no hay nada; atravesar la transición sabiendo que los reenvíos masivos degradan SPF y que el anuncio público atrae el fraude; consolidar por fases — doble vida, congelación de envío, cierre en p=reject —; y gobernar el DNS unificado como un activo, hasta los dominios durmientes reducidos a v=spf1 -all.
El primer paso no exige presupuesto ni accesos: pasar cada dominio del parque — los del comprador y los de la adquirida — por un análisis DMARC gratuito da en segundos el mapa de las brechas de autenticación. Para seguir después decenas de dominios durante la integración y documentar la subida hacia p=reject, la apertura de una cuenta centraliza informes, alertas e histórico — el utillaje natural de una consolidación que no deja ningún dominio atrás.
Guías relacionadas
- Inventariar los remitentes terceros de un dominio: el mapa antes de DMARC
Ningún proyecto DMARC sobrevive a un tercero olvidado: familias de remitentes, tres fuentes de verdad y un método para mapear los envíos antes de p=reject.
- Multimarca, multidominio: la gobernanza DMARC
Treinta marcas, doscientos dominios: a esa escala DMARC exige gobernanza. Tipología del parque, registro central, DNS centralizado y p=reject por oleadas.
- El dominio está suplantado: la respuesta al incidente, paso a paso
Dominio suplantado: quejas de destinatarios, volumen en fallo disparado en los informes RUA, NDR en masa. Del reconocimiento del incidente a p=reject.
Sobre el autor
Thomas — Thomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.