¿Cuánto tiempo va a seguir llegando correo a mi servidor anterior?

Google indica que los registros MX nuevos pueden tardar hasta 72 horas en ser reconocidos, y que hasta que se actualicen en todo el mundo vas a seguir recibiendo tráfico en el servidor anterior. Nosotros dejamos los buzones viejos aceptando correo al menos una semana, porque un remitente lento puede aparecer el día cinco.

¿Tengo que reemplazar mis registros aspmx por smtp.google.com?

No. Google documenta un solo registro que apunta a smtp.google.com para las configuraciones nuevas, y dice que los valores antiguos que empiezan con aspmx siguen siendo compatibles y no requieren cambios si tu correo funciona. En una migración dejamos en paz un registro antiguo que funciona y cambiamos una cosa a la vez.

¿Cambiar el registro MX puede romper mi sitio web o mis envíos?

El registro MX solo decide qué servidor recibe el correo entrante de tu dominio. Tu sitio web usa registros aparte, y la capacidad de enviar en nombre de tu dominio depende de SPF, DKIM y DMARC, que hay que actualizar por separado. Un cambio de MX impecable con un SPF desactualizado es la razón habitual de que el correo empiece a caer en spam después de una migración.

Cambiar registros MX a Google Workspace sin perder correos

El cambio de MX es el momento en que los clientes se quedan callados en la llamada. Casi todo lo demás en una migración se puede deshacer en una tarde. Esto se siente como desconectar el teléfono de la empresa, y la pregunta siempre es la misma: ¿qué pasa con los correos que lleguen mientras se hace el cambio?

La respuesta honesta es que no tiene que perderse nada, y cuando algo se pierde casi nunca es culpa del registro. Es culpa de una cuenta que todavía no existía, de un buzón viejo que se apagó demasiado pronto, o de una autenticación de envío que nadie actualizó. Este es el orden que seguimos con un cliente, y lo que revisamos en cada paso.

Qué controla de verdad el registro MX

Un registro MX responde una sola pregunta para todos los servidores de correo del mundo: cuando alguien escribe a tu dominio, ¿qué servidor debe recibir ese mensaje? Eso es todo. No mueve el correo que ya está en tus buzones viejos, no decide quién puede enviar en nombre de tu dominio y no tiene nada que ver con tu sitio web.

Esa diferencia importa porque las dos mitades del correo se rompen por motivos distintos. Lo que entra sigue el MX. Lo que sale se juzga con SPF, DKIM y DMARC, que viven en registros DNS completamente aparte. Hemos visto cortes perfectos del lado de la recepción mientras todas las facturas que la empresa envió esa semana caían en spam, porque el SPF seguía listando solo al hosting anterior.

Y algo que conviene decir claro: el DNS no se cambia, se vence. Cada servidor que consultó tu dominio hace poco se queda con la respuesta anterior durante el tiempo que permita el TTL del registro, así que por un rato el correo llega a dos lugares. Planifica el traslape en vez de intentar evitarlo.

Baja el TTL primero, días antes de tocar algo

El TTL, o tiempo de vida, es la cantidad de segundos que otros servidores pueden seguir usando una copia en caché de tu registro antes de volver a consultarlo. La guía de DNS de Google lo dice sin rodeos: un registro con TTL de 86400 segundos significa que los cambios tardan hasta 24 horas en aplicarse, y recomienda un valor de 3600 para que los servidores consulten cada hora.

Hay un detalle que a mucha gente le cuesta un día entero. Un TTL más corto empieza a valer solo después de que venza el periodo anterior. Si tu MX está en 86400 y lo bajas a 3600 una hora antes del corte, el resto de internet todavía tiene derecho a la respuesta vieja por un día más. Por eso bajar el TTL es un paso propio, hecho con al menos un periodo completo de anticipación. Para un registro de 24 horas, lo bajamos dos días antes.

Antes de planificar la ventana, mira qué tienes:

dig +noall +answer MX ejemplo.com
dig +nocmd +noall +answer TXT ejemplo.com | grep spf1

El número de la segunda columna en la respuesta MX es el TTL que queda, en segundos. Ese número, y no el calendario, define con cuánta antelación empiezas.

Los valores que Google publica hoy

La página de configuración de Google ahora muestra un solo registro MX que apunta a smtp.google.com, y los registradores suelen pedirlo con prioridad 1. Las cuentas que empezaron antes de 2023 tienen el conjunto anterior de valores que comienzan con aspmx; Google indica que esos valores antiguos siguen siendo compatibles y que no hace falta cambiarlos si tu correo funciona. En una migración no reescribimos un registro antiguo que ya funciona. Un cambio riesgoso a la vez es suficiente. Consultado en la página de ayuda de Google Workspace sobre configuración de MX el 29 de septiembre de 2026.

; así se ve una configuración actual de un solo registro
ejemplo.com.    3600    IN    MX    1 smtp.google.com.

Dos detalles causan la mayoría de los hilos de soporte. Los formatos de cada registrador son distintos: unos exigen el punto final, otros quieren la prioridad y el host en un mismo campo como 1 smtp.google.com, y otros agregan tu dominio al valor de forma automática, así que terminas con smtp.google.com.ejemplo.com. Y los MX viejos tienen que irse. Las instrucciones de Google dicen que elimines cualquier otro registro MX, porque el correo puede no funcionar bien si quedan registros incorrectos. Un registro olvidado con prioridad 10 apuntando al hosting anterior es la forma más común de terminar con la mitad del correo en un buzón que nadie lee.

Crea las cuentas antes de tocar el DNS

Este es el paso que de verdad pierde mensajes, y no es un paso de DNS. La guía de Google para evitar problemas al cambiar los MX pide crear las cuentas de usuario en la consola de administración primero, junto con los grupos y los alias que use tu dominio.

Digamos que un despacho contable de 12 personas tiene diez buzones, dos direcciones compartidas para clientes, una dirección desde la que envía el sistema de facturación y un alias impreso en una tarjeta antigua. Si facturacion@ existe en el servidor viejo pero no en Workspace, el correo a esa dirección empieza a rebotar en el minuto en que cambia el registro, y un rebote no se recupera. Armamos el inventario con la lista de cuentas del servidor anterior y con un mes de logs, no de memoria, porque las direcciones que la gente olvida son justo las que usan las máquinas.

Entrega dual y entrega dividida: las dos redes de seguridad

No tienes que elegir entre el sistema viejo y el nuevo en una sola noche. Google admite dos arreglos para el traslape, los dos configurados en la consola de administración en Aplicaciones, luego Google Workspace, luego Gmail, luego Enrutamiento.

La entrega dual deja una copia de cada mensaje entrante en los dos sistemas. Cualquiera de los dos puede ser el principal: Google recomienda Gmail como principal, y señala que puedes mantener el servidor anterior como principal durante un piloto o una migración, y pasar a Gmail solo cuando termine el piloto. Lo usamos cuando un equipo quiere una semana leyendo correo en los dos lados antes de comprometerse.

La entrega dividida enruta los mensajes entrantes a dos sistemas distintos según los destinatarios que nombres, lo que le sirve a una empresa que se mueve por departamentos. La documentación de Google aclara que los cambios de enrutamiento pueden tardar hasta 24 horas, aunque normalmente aplican más rápido, así que cuéntalo en el plan en vez de probar cinco minutos después de guardar.

Para una pyme que mueve a todos de una vez, ninguna de las dos es indispensable. Para un cambio por fases, o para un buzón compartido del que depende el negocio, el traslape es un seguro barato.

La hora del corte, en orden

El consejo de Google es programar el cambio cuando tu volumen de correo sea bajo, una noche o un fin de semana. Nosotros agregamos una regla: elige una hora en la que la gente que puede responder preguntas todavía esté despierta.

Confirma que todas las direcciones del inventario existen en Workspace, incluidos grupos y alias.
Confirma que el lado del envío está listo: el SPF autoriza a Google, la clave DKIM está publicada y activada, y el registro DMARC existe.
Confirma que los buzones viejos siguen aceptando correo y que lo harán por lo menos una semana más.
Publica el registro MX de Google y borra todos los demás registros MX del dominio.
Vuelve a leer el registro desde fuera de tu red con dig, no desde la pantalla de confirmación del registrador.
Envía una prueba desde una dirección externa y responde desde el buzón nuevo hacia algo externo.
Vigila los dos sistemas el resto de la noche. El viejo va a seguir recibiendo un rato, y eso es lo esperado, no una falla.

El correo que todavía llega al hosting anterior

Google es explícito: los registros MX nuevos pueden tardar hasta 72 horas en ser reconocidos, y hasta que se actualicen en todo el mundo vas a seguir recibiendo tráfico en tu servidor anterior. Tómalo como una semana de prudencia y no como una cuenta regresiva de tres días, porque un dominio que resuelve bien en todas partes el día dos suele tener un remitente terco el día cinco.

Dos cosas evitan que ese correo se pierda. La primera, deja los buzones viejos aceptando y, si el hosting lo permite, reenviando a las direcciones nuevas. Nadie debe cancelar el plan de hosting anterior el día del corte, y lo dejamos por escrito antes de arrancar el proyecto. La segunda, trae el historial como se debe. El servicio de migración de datos y la herramienta de importación de Google jalan el correo por IMAP desde la consola de administración, en Datos, luego Importación y exportación de datos, con un archivo que mapea direcciones de origen y destino; la documentación indica un límite de 100 usuarios IMAP por importación y que hay que entrar como superadministrador. La importación va después del corte, y luego una segunda pasada para lo que haya caído en el servidor anterior durante el traslape.

Autentica de nuevo y prueba con un correo real

La recepción ya es Google. El envío también tiene que decirlo, y aquí es donde un cambio de MX impecable igual produce una semana de correos en spam.

Si Google Workspace es lo único que envía por tu dominio, Google documenta el registro como v=spf1 include:_spf.google.com ~all, donde ~all pide a los receptores tratar como sospechoso a cualquier remitente no listado. La mayoría de las pymes no es tan simple: la tienda, el CRM, el sistema de facturación y la mesa de ayuda también envían, y cada uno que agregas gasta parte del presupuesto de 10 consultas que permite SPF.

; Google más un remitente externo, como ejemplo
v=spf1 include:_spf.google.com include:sendgrid.net ~all

El DKIM hay que generarlo y activarlo en la consola de administración, no dejarlo al comportamiento por defecto. Google recomienda el prefijo de selector google y una clave de 2048 bits, dice que bajes a 1024 solo si tu proveedor de DNS no acepta el valor largo, y señala que la autenticación puede tardar hasta 48 horas en empezar a funcionar. La consola puede seguir mostrando un aviso de que actualices el DNS hasta 48 horas después de que la clave ya esté bien, lo cual conviene saber antes de que alguien empiece a cambiar cosas que estaban correctas.

Después, revísalo del lado del receptor y no del tuyo. Los requisitos para remitentes de Gmail establecen que todos los remitentes deben configurar SPF o DKIM, y que quienes envían 5,000 mensajes o más al día a Gmail deben tener SPF, DKIM y DMARC. Postmaster Tools tiene una vista de autenticación con el porcentaje de tu correo que pasa cada verificación, que es el único número que zanja una discusión sobre si la migración afectó la entregabilidad.

Cómo ayuda Guanacos Tech

Hacemos los cortes de MX como una hora agendada con un orden de operaciones por escrito, porque las fallas aquí vienen de la secuencia y no de la dificultad: una dirección que no existía, un registro borrado antes de tiempo, un sistema de envío que nadie inventarió. Nuestra página de consultores de migración a Google Workspace explica el alcance con el que trabajamos, incluida la semana de traslape y las verificaciones de autenticación posteriores. Lleva tu registro MX actual y la lista de todo lo que envía correo como tu dominio a una llamada de 30 minutos, y saldrás con la hora del corte, los riesgos propios de tu caso y lo que debes mantener encendido hasta que el último remitente se ponga al día.

Cambiar los registros MX a Google Workspace sin perder ni un correo