El nuevo sitio puede funcionar perfectamente mientras dejan de llegar facturas, enlaces para restablecer contraseñas y respuestas de clientes. El error consiste en tratar el cambio de servidores de nombres como un ajuste exclusivo de la web. Este plan sirve a una pequeña empresa que cambia de proveedor DNS y conserva su servicio de correo. Describe un procedimiento, no una garantía de entrega ininterrumpida. Los ejemplos utilizan el nombre reservado example.com: sustitúyalo por su dominio y los valores de su proveedor. DEFINIR QUÉ SE TRASLADA Anote tres servicios separados: el registrador del dominio, el proveedor que responde a las consultas DNS autoritativas y la empresa que aloja los buzones. En esta migración, cambie únicamente el segundo. Mantenga el alojamiento web, la suscripción de correo y los servicios de envío. Si un compañero quiere trasladar también los buzones, organice otro proyecto con otra fecha. Separar los cambios permite identificar el origen de un fallo sin investigar varias migraciones al mismo tiempo. INVENTARIAR ANTES DE CAMBIAR LOS SERVIDORES Exporte la zona actual y conserve una copia legible junto al archivo. La tabla debe incluir nombre, tipo, valor, prioridad, TTL, finalidad, responsable del servicio y resultado de verificación. Incluya el nombre raíz, www, mail, autodiscover, selectores DKIM, _dmarc y todos los registros de verificación. Añada los del CRM, la herramienta de facturación y el soporte aunque nadie recuerde quién los creó. Pregunte a sus responsables si todavía envían mensajes desde su dominio. Los registros MX identifican servidores de correo; los TXT pueden publicar políticas de correo. SPF, DKIM y DMARC cumplen funciones diferentes: conservar uno no sustituye a los demás. Sus especificaciones aparecen al final. Anote los valores realmente existentes en lugar de copiar una configuración genérica. No publique una segunda política SPF competidora simplemente porque la propone el nuevo panel DNS. ENSAYAR LA ZONA DE DESTINO Cree la nueva zona y compárela con el inventario línea por línea. La detección automática es un punto de partida, no una prueba de aceptación. En el ejemplo ficticio, sales@example.com sigue con el mismo proveedor de buzones: los destinos y las prioridades MX deberían mantenerse. También puede conservarse el registro A de la web. Migrar DNS no exige inventar nuevas direcciones de correo ni de sitio. Antes de cambiar la delegación, consulte directamente cada nuevo servidor autoritativo. Guarde las respuestas de MX, el TXT raíz, _dmarc y todos los selectores DKIM activos. Puede utilizar dig @NEW_NAMESERVER example.com MX y sustituir el marcador por el servidor asignado. Compare valores completos, no solo la existencia del registro. Un selector ausente puede afectar únicamente a un remitente y pasar inadvertido en una comprobación superficial. Elija una ventana tranquila y designe a una persona para ejecutar el cambio. Registre los servidores anteriores y el identificador de la nueva zona en el mismo ticket. Si pretende reducir los TTL, hágalo antes y espere a que expire el TTL previo: cambiarlo a última hora no vacía las cachés de inmediato. Establezca cuándo decidir una reversión y quién puede autorizarla. TRATAR DNSSEC COMO UN CONTROL SEPARADO Si DNSSEC está activado, revise los datos DS actuales y siga el procedimiento del proveedor de destino. No deje en la zona superior un DS que señale una clave que la nueva zona no puede utilizar. La documentación de configuración completa de Cloudflare explica esta dependencia. Una zona firmada necesita un paso DNSSEC explícito en el ticket, en lugar de suponer que el formulario de servidores de nombres resuelve todo. PROBAR EL RECORRIDO DEL CLIENTE, NO SOLO LA WEB Antes y después del cambio, envíe un mensaje con una referencia única desde un buzón externo a una dirección empresarial real y responda. Repita con un segundo proveedor externo. Después, active un restablecimiento de contraseña, una notificación de soporte y una factura de prueba desde las aplicaciones inventariadas. Utilice clientes de prueba y contenido no sensible. Anote qué mensaje esperaba, si llegó y si sus cabeceras muestran los resultados de autenticación previstos. Si la web funciona pero el correo entrante falla, empiece por MX y el servicio receptor. Si solo fallan los mensajes del CRM, compare sus registros de autenticación y sus logs. Si el problema aparece en una red y no en otra, contraste respuestas DNS antes de cambiar la aplicación. Este recorrido de diagnóstico es una propuesta: reduce la búsqueda, pero por sí solo no demuestra la causa. CERRAR CON EVIDENCIAS Mantenga ambos servicios DNS disponibles durante el periodo de observación acordado. Evite cambios ajenos mientras reúne resultados. Cierre el ticket únicamente cuando la comparación del inventario, las pruebas de correo externo y los controles de herramientas empresariales tengan responsables y resultados documentados. Conserve el export final, la hora y las excepciones pendientes. Ese pequeño expediente será más útil para la próxima migración que una captura con el estado activo. ¿Está preparando una marca nueva? Compare nombres en el catálogo de DomainEvery: https://domainevery.com/es/domains e incluya a los responsables de correo y DNS en el plan de lanzamiento. FUENTES PRIMARIAS Cloudflare: cambiar servidores de nombres: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/; Cloudflare: registros de correo: https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/; Formatos DNS, RFC 1035: https://www.rfc-editor.org/rfc/rfc1035.html; SPF, RFC 7208: https://www.rfc-editor.org/rfc/rfc7208; DKIM, RFC 6376: https://www.rfc-editor.org/rfc/rfc6376.html; DMARC, RFC 7489: https://www.rfc-editor.org/rfc/rfc7489.html.