Cambiar los proveedores de correo cambia los nombres de host de recepción, la propiedad de los certificados y, a veces, el comportamiento de reserva. MTA-STS puede exponer una orden de migración insegura: DNS comienza a anunciar un nuevo proveedor mientras algunos remitentes aún aplican una política que permite solo el antiguo.
Inventario de ambos lados de la migración
Referencias: RFC 8461 §4, RFC 8461 §8.2.
Registre los nombres MX antiguos y propuestos, prioridades, direcciones, STARTTLS comportamiento e identidades de certificados. Obtenga la ruta actual del nuevo proveedor y la guía MTA-STS , luego verifique los nombres exactos en su propio cambio DNS planificado. La marca de un proveedor o un comodín adivinado no es un inventario de nombres de host autorizado.
Revise si la política de alojamiento HTTPS o DNS de descubrimiento también está vinculada al proveedor saliente. Mover el correo recibido mientras se cancela accidentalmente el host de la política crea una segunda falla. Mantenga la publicación de políticas, la renovación de certificados y los destinos de informes de propiedad explícita durante la mudanza.
Publicar primero una política de compatibilidad
Referencias: RFC 8461 §3.2, RFC 8461 §4, RFC 8461 §8.1.
Prepare una política que permita los hosts receptores nuevos y antiguos necesarios sin cambiar todavía el enrutamiento del correo. Pruebe que ambos grupos coincidan y que el nuevo grupo pase las comprobaciones del certificado SMTP y STARTTLS . Publique el cuerpo HTTPS antes de cambiar la identificación de descubrimiento.
Permita un intervalo de transición basado en la política max_age publicada anteriormente, TTL DNS y el comportamiento de actualización observado. Reducir max_age en el momento de la migración no acorta una política obtenida anteriormente. Siempre que sea posible, conserve una ruta antigua que funcione y que satisfaga las políticas antiguas almacenadas en caché mientras se distribuye la nueva política. No prometa que cambiar la identificación actualizará instantáneamente a todos los remitentes.
Ensayar los tres estados políticos
Referencias: RFC 8461 §4.1.
Utilice dos nombres sintéticos, mx.old.example y mx.new.example . La política A solo permite viejos; la política B permite ambos; La política C solo permite vehículos nuevos. La matriz de compatibilidad esperada es A: antiguo verdadero, nuevo falso; B: ambas verdaderas; C: antiguo falso, nuevo verdadero. El dispositivo fuera de línea limitado proporcionado se volvió a ejecutar para esta revisión y registra estas comparaciones de nombres, no la entrega.
Esta matriz prueba sólo la relación de membresía de la política nombrada. Un ensayo realista también necesita respuestas DNS , certificados válidos, STARTTLS , aceptación del destinatario y entrega real del mensaje de prueba. Esas pruebas de migración en vivo no se realizaron para este artículo. Preservar sus productos futuros por separado en lugar de tratar la matriz local como una transición exitosa de proveedores.
Mover la ruta y retirarse deliberadamente
Referencias: RFC 8461 §5.1, RFC 8461 §8.1.
Después de la etapa de compatibilidad, cambie el enrutamiento MX a través del proceso de cambio aprobado. Observe la entrega en ambos proveedores, errores del remitente, colas e informes TLS . Confirme los destinatarios comerciales y las rutas de recuperación, incluidas las direcciones de bajo volumen que una sola prueba de bandeja de entrada pasaría por alto. Mantener disponible el servicio antiguo para la superposición planificada.
Sólo entonces limite la política al nuevo conjunto previsto y anuncie otra identificación. Conserve el cuerpo anterior y considere cómo funcionaría la reversión si los remitentes almacenan en caché la política de solo nueva. Es posible que volver a agregar el antiguo MX solo en DNS no restablezca la entrega para esa cohorte. Cierre la migración cuando la ruta, la política y la evidencia operativa respalden el retiro, no simplemente cuando el editor DNS muestre el nuevo proveedor.
Evidencia histórica retenida y alcance restante
A continuación se describen las observaciones conservadas del 7 de noviembre de 2026, no un experimento de red repetido para esta revisión. Las comprobaciones fuera de línea recién ejecutadas se registran por separado.
El ensayo ampliado vincula la matriz de membresía con la publicación y el estado de vida. A1 solo permite datos antiguos y puede seguir siendo válido hasta el momento lógico 1086700, cuando se considera su última recuperación modelada. B2 permite ambos proveedores; su cuerpo se recupera a través del punto final HTTPS del laboratorio después de que cambia la identificación DNS . C3 permite sólo nuevos. Los tiempos de vencimiento modelados de B2 y C3, 1004200 y 1004500, ocurren antes del límite anterior de A1 porque A1 usó una vida útil más larga. Por lo tanto, promover C3 o cambiar DNS en el momento de la publicación B2 por sí solo no es evidencia de que todos los remitentes antiguos estén listos. El seguimiento demuestra DNS /HTTPS local real más aritmética explícita de estado de política. No prueba la aceptación del destinatario del proveedor, las cachés DNS públicas, la entrega de correo ni la cobertura de direcciones comerciales; éstas siguen siendo la puerta de transición.