Cambiar de proveedor de correo sin romper DMARC

ejemplo.es.  IN TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all"

Antes del cambio, todavía: el DKIM del nuevo, activado y probado

La segunda tarea preparatoria pesa al menos tanto: la firma DKIM del nuevo proveedor debe estar activada, publicada y verificada antes de que un solo usuario cambie. En concreto: en Google Workspace, la publicación del selector google._domainkey como registro TXT y la activación de la firma en la consola; en Microsoft 365, dos registros CNAME (selector1._domainkey y selector2._domainkey) apuntando a la infraestructura de Microsoft, y después la activación explícita de la firma para el dominio — sin ese último paso, los mensajes salen firmados por el dominio técnico onmicrosoft.com, sin alineamiento con el dominio visible.

Fuera de las dos grandes suites el gesto es idéntico, pero la consola cambia de sitio — y ahí es donde las migraciones pierden sus jornadas. En GoDaddy igual que en IONOS, el registro se coloca en la interfaz DNS del registrador, que no siempre ofrece un campo dedicado a DMARC y obliga a introducirlo como TXT en bruto; en Infomaniak y en Zoho Mail, el selector DKIM se genera desde el panel de administración y luego se copia a mano en la zona, con el riesgo de truncamiento que acarrea toda clave larga. La dificultad nunca es conceptual: está en dónde se esconde el botón.

La verificación no se apoya en la palabra de la consola de administración, sino en un mensaje real: un envío de prueba a buzones externos en varios proveedores, y después la lectura de la cabecera Authentication-Results — dkim=pass por sí solo no basta; el d= de la firma debe corresponder al dominio emisor. Ese alineamiento, y solo ese, es lo que DMARC contabiliza.

Llega entonces el periodo de solapamiento: de dos a cuatro semanas durante las cuales los dos proveedores están plenamente autenticados y la migración avanza por oleadas — primero un departamento piloto, luego los equipos por grupos, las aplicaciones al final. Cada oleada que cambia lo hace hacia un destino cuyo SPF y DKIM ya están en verde. Ese es el corazón del método: la prueba precede al movimiento.

Durante: los informes RUA, día a día

Una vez lanzado el cambio, los informes agregados (RUA) cambian de estatus: de cuadro de mando semanal pasan a ser el instrumento de pilotaje diario. Cada mañana de la ventana de migración, unas pocas preguntas sencillas encuentran respuesta en los datos de la víspera. ¿Se desplaza el volumen de la fuente antigua a la nueva al ritmo de las oleadas? ¿Qué flujos siguen enganchados a la infraestructura antigua — y están identificados, planificados u olvidados? ¿Produce el nuevo proveedor fallos de alineamiento residuales, la señal delatora de un dominio por defecto o de una ruta de retorno mal configurada?

Los informes también hacen su papel de atalaya: una fuente totalmente desconocida que aparece en plena migración es o bien un flujo interno olvidado que vuelve a la superficie, o bien un intento de suplantación oportunista — a los defraudadores les encantan los periodos de transición, en los que un correo del «departamento informático» anunciando un cambio de sistema de correo resulta de lo más plausible. En ambos casos, descubrirlo al día siguiente vale infinitamente más que descubrirlo al cabo de un mes.

Un pico de fallos concentrado en un flujo concreto es una señal de parada: la siguiente oleada espera hasta que la causa esté comprendida y corregida. Esa disciplina es la que separa una migración pilotada de una migración padecida.

Bajar la política un escalón: un arbitraje, no un reflejo

¿Conviene relajar la política DMARC durante la ventana? La respuesta honesta: a veces, y nunca por defecto. Un dominio en p=reject cuyo inventario deja zonas grises —aplicaciones mal cartografiadas, filiales autónomas, historial DNS dudoso— puede legítimamente bajar a p=quarantine mientras dure la mudanza: un flujo olvidado acabará en spam, recuperable, en lugar de ser destruido.

_dmarc.ejemplo.es.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:rua@ejemplo.es"

Pero esa bajada es un arbitraje documentado, no un retoque técnico inocuo: reabre una ventana de suplantación durante toda su duración. La decisión merece una traza escrita —motivo, perímetro, fecha de retorno prevista— y la vuelta a p=reject forma parte integral del plan de migración, no de un vago «más adelante». Conviene recordar que DMARCbis, el estándar vigente, suprimió la etiqueta pct que antaño permitía un endurecimiento progresivo por porcentajes: los escalones de política son hoy francos, y el modo de prueba se expresa con la bandera t=y. Bajar un escalón es, por tanto, una elección entera, que se asume como tal.

El punto de comparación útil: un dominio con inventario completo y DKIM probado en el nuevo proveedor migra perfectamente con p=reject constante. La bajada compensa un déficit de visibilidad — no sustituye el trabajo de preparación.

Después: la purga del proveedor antiguo

La migración no termina cuando cambia el último usuario, sino cuando el proveedor antiguo ha perdido todo poder de emisión. Esa purga, demasiado a menudo descuidada, tiene tres frentes. Primero el SPF: el include del antiguo se retira en cuanto treinta días de informes RUA dejan de mostrar emisión legítima por su infraestructura. Después el DKIM: los selectores del proveedor antiguo se revocan del DNS — unas claves de firma abandonadas equivalen a un poder de firma en manos de un tercero ya fuera de contrato, exactamente el riesgo que cubre la rotación limpia de las claves de firma. Por último los accesos: cuentas de servicio, contraseñas de aplicación, conectores SMTP salientes, buzones compartidos y los reenvíos temporales creados «para la transición» se cierran uno a uno.

Un dominio mal purgado arrastra autorizaciones fantasma durante años: un include SPF que delega la emisión en una infraestructura olvidada, una clave DKIM todavía activa en un proveedor abandonado hace tiempo. Es precisamente el tipo de pasivo que aflora, del lado del comprador, en el historial de correo de un dominio comprado — mejor no ser el vendedor que lo dejó atrás.

Los olvidados clásicos: impresoras, aplicaciones de negocio, alias

Tres familias de remitentes escapan casi sistemáticamente a los planes de migración, porque ningún humano los ve enviar. Primero, las fotocopiadoras y los escáneres: la función «escanear a correo» está configurada con SMTP autenticado contra el servidor antiguo, con una contraseña puesta hace cinco años por un proveedor desaparecido. El día en que el SMTP antiguo se apaga, la digitalización se detiene — y la conexión con la migración de correo no se establece de inmediato.

Después, las aplicaciones de negocio: el ERP que envía las facturas, el CRM que envía los recordatorios, la supervisión que envía las alertas, las copias de seguridad que envían sus resúmenes nocturnos, los scripts programados escritos por un desarrollador que ya se fue. Cada una lleva credenciales SMTP del mundo antiguo. El síntoma típico llega con retraso: todo funciona durante tres semanas, y luego los recordatorios trimestrales de facturación fallan en masa — porque ese flujo en concreto solo se dispara una vez por trimestre.

Por último, los alias y reenvíos: un reenvío reemite el mensaje desde la infraestructura que reenvía, lo que rompe SPF aguas abajo; solo una firma DKIM intacta mantiene entonces viva la autenticación. Una migración redibuja esos caminos de reencaminamiento, y un alias histórico puede pasar de un caso «DKIM sobrevive» a un caso «ya no pasa nada». Los informes RUA del periodo de solapamiento son el único lugar donde esos flujos discretos se hacen visibles.

La lista de control de fin de migración

Una migración está terminada cuando cada línea de esta lista es un estado constatado — no una intención:

• el include SPF del proveedor antiguo está retirado, y el contador de resoluciones DNS vuelto a comprobar tras la retirada;
• los selectores DKIM del proveedor antiguo están revocados del DNS, con la fecha de revocación anotada;
• las cuentas de servicio, contraseñas de aplicación y conectores SMTP de la infraestructura antigua están cerrados;
• treinta días de informes RUA ya no muestran emisión alguna por el proveedor antiguo;
• la política DMARC ha vuelto a su nivel anterior si se había bajado, y el arbitraje está archivado;
• el inventario de remitentes está al día, fotocopiadoras, aplicaciones de negocio y alias incluidos;
• la documentación DNS refleja el estado final: un SPF adelgazado, los selectores activos, el registro DMARC.

Siete líneas, ninguna heroica; su única dificultad es existir por escrito y comprobarse en una fecha fija en lugar de «algún día».

En resumen

Una migración de correo rompe DMARC cuando se juega en desorden: SPF reemplazado en lugar de ampliado, DKIM nunca probado, proveedor antiguo cortado demasiado pronto o nunca purgado. La secuencia segura invierte la carga de la prueba: antes del cambio, un SPF aditivo hace coexistir a los dos proveedores y el DKIM del nuevo se verifica con mensajes reales; durante, los informes RUA se leen día a día y la política solo baja un escalón mediante un arbitraje documentado, con fecha de retorno; después, el proveedor antiguo pierde metódicamente todo poder de emisión — include retirado, claves revocadas, cuentas cerradas. Las fotocopiadoras, las aplicaciones de negocio y los alias de reenvío son los olvidados que deciden, por sí solos, si la migración acaba bien.

El buen punto de partida no depende de ningún calendario de cambio: un análisis DMARC gratuito del dominio muestra, antes incluso de elegir la fecha, quién envía realmente en su nombre y qué deberá preservar la migración. Y para pilotar la ventana de solapamiento con los informes de cada día en lugar de a ciegas, la apertura de una cuenta da a la migración el instrumento que más a menudo le falta: la prueba, día tras día, de que nada se ha roto.