Transferir un buzón: guía segura para cambiar el DNS

Cómo transferir un buzón a otro proveedor de correo: guía para cambiar el DNS

Al transferir los datos de un buzón entre proveedores, la estrategia de DNS puede marcar la diferencia entre un cambio limpio y una interrupción de hasta 48 horas. Un TTL mal configurado o un include de SPF olvidado puede provocar rebotes y pérdidas comerciales.

No es un ejercicio creativo, sino una secuencia de operaciones técnicas precisas. Esta guía explica cómo transferir el contenido de un buzón de forma segura: ajustar los tiempos de propagación, combinar las identidades de autenticación SPF, DKIM y DMARC, y dirigir el correo al proveedor nuevo con el menor riesgo posible de perder mensajes.

Para conocer el proceso de migración de datos, es decir, cómo trasladar los mensajes, consulte la guía de sincronización IMAP.

Por qué la propagación DNS no es inmediata al transferir un buzón

El DNS es un sistema de caché distribuido. Cuando cambia un registro, depende de que cada resolutor recursivo, desde los servidores DNS del proveedor de Internet y el 8.8.8.8 de Google hasta los routers locales, respete el valor de tiempo de vida (TTL).

Si el TTL mantiene el valor habitual de 86,400 segundos (24 horas), durante la transición puede haber enrutamiento dividido hasta que caduquen las cachés. Parte del correo podría llegar al buzón nuevo y otra parte al antiguo.

La cola larga y la caché negativa

Dos factores poco visibles suelen complicar los cambios al transferir buzones:

• La cola larga: incluso con un TTL bajo, se estima que entre el 1 y el 5% de los resolutores mundiales no respetan valores inferiores a 60 minutos. Prevea que durante alrededor de una hora después del cambio aún llegue algo de tráfico al proveedor antiguo.
• Caché negativa (SOA): si consulta un registro antes de que exista, por ejemplo, un selector DKIM nuevo demasiado pronto, la respuesta NXDOMAIN se almacena según el TTL mínimo del registro SOA, a menudo 1 hora. Esto puede impedir que el registro válido sea visible hasta que caduque esa caché, aunque ya se haya publicado.

Fase 1: la cuenta atrás de 48 horas

No cambie todavía los registros MX. Prepare primero el entorno para recibir la modificación.

Paso 1: reduzca los TTL (48 horas antes)

Localice los registros MX, SPF (TXT) y DMARC. Reduzca su TTL a 300 segundos (5 minutos).

Esto acorta la ventana prevista de propagación. Cuando haga el cambio definitivo, las cachés que respeten el TTL podrán actualizarse en unos 5 minutos en lugar de esperar hasta 24 horas.

Paso 2: combine SPF (24 horas antes)

SPF (RFC 7208) autoriza las IP que pueden enviar en su nombre. Durante la transición debe autorizar simultáneamente a ambos proveedores.

El problema: SPF admite un máximo de 10 consultas DNS. Combinar dos proveedores, como Google Workspace y TrekMail, puede superar ese límite.

La solución: simplifique el registro. Sustituya los include: anidados por mecanismos ip4: directos cuando el proveedor publique direcciones estables y admita expresamente esta configuración.

Ejemplo de registro para la transición:

Si utiliza el SMTP externo de TrekMail, como Amazon SES o SendGrid, incluya en su lugar los registros SPF correspondientes.

Paso 3: publique DKIM con antelación

DKIM utiliza selectores, por ejemplo, google._domainkey. Genere las claves DKIM en el proveedor nuevo con un selector único, como tm1._domainkey. No reutilice el nombre de un selector; puede publicar el nuevo con varios días de antelación sin que entre en conflicto con el proveedor anterior.

Paso 4: relaje DMARC

Si la política DMARC es p=reject o p=quarantine, cámbiela a p=none al menos 24 horas antes de la transición. Durante las primeras horas pueden producirse fallos de autenticación. p=none permite registrarlos en los informes RUA sin solicitar el rechazo por DMARC, aunque la entrega sigue dependiendo de otros controles del receptor. La guía de configuración de DMARC de Google explica cómo definir correctamente la política.

Fase 2: ejecución del cambio

Los TTL ya son bajos y la autenticación incluye ambos sistemas. Es el momento de dirigir el buzón al alojamiento nuevo.

Paso 1: compare la respuesta autoritativa y la recursiva

Compruebe que los registros nuevos aparecen en el servidor de nombres autoritativo antes de consultarlos desde resolutores públicos:

Paso 2: actualice los registros MX

Añada y compruebe los registros MX nuevos antes de retirar los antiguos, o aplique todo el cambio de forma atómica si su proveedor DNS lo permite. Para usuarios de TrekMail:

Mantenga el TTL en 300 segundos. Todavía no lo aumente.

Paso 3: vacíe la caché y compruebe

Vacíe la caché DNS local con ipconfig /flushdns en Windows o sudo dscacheutil -flushcache en macOS. Ejecute dig de nuevo; verá los registros MX nuevos cuando el resolutor consultado haya actualizado su caché.

Fase 3: estabilización posterior al cambio

Vigile los errores de atribución del tenant (550 5.7.64)

Este fallo es habitual al transferir el alojamiento del buzón a Microsoft 365 o a una suite similar. Si el destino todavía no ha aprovisionado por completo el dominio en su directorio interno, puede rechazar el correo con «Relay Access Denied». Compruebe que el dominio figure como «Verified» o «Healthy» en el panel del proveedor nuevo antes de cambiar los MX.

Supervise los informes DMARC (72 horas)

Revise los informes RUA durante tres días:

• Correcto: el tráfico procedente de las IP del proveedor nuevo supera SPF y DKIM.
• Fallo: el tráfico legítimo de sistemas de facturación o plataformas de marketing no supera la autenticación. Actualice SPF o DKIM de inmediato.

Limpieza (72 horas después)

Cuando el tráfico se haya estabilizado:

1. Quite del registro SPF el include: del proveedor anterior.
2. Elimine los registros CNAME/TXT de DKIM antiguos solo después de un margen seguro para los mensajes que todavía lleven firmas anteriores.
3. Vuelva a subir los TTL a 3,600s (1 hora) o 86,400s (24 horas).
4. Vuelva a aplicar DMARC con p=quarantine o p=reject.

Resumen de la lista para transferir un buzón

TrekMail simplifica la transferencia del buzón

La gestión manual del DNS propicia los errores. Un solo fallo de sintaxis en un registro TXT puede invalidar toda la política SPF.

Para pequeñas empresas

TrekMail ofrece una comprobación del estado del DNS en tiempo real. El panel consulta los servidores de nombres autoritativos y valida los registros MX, SPF y DKIM frente a la configuración necesaria. Esto confirma la publicación autoritativa, no la propagación en todos los resolutores, y señala los errores de sintaxis antes de que puedan causar rebotes.

Obtenga más información sobre cómo configurar el correo en su propio dominio.

Para agencias

Gestionar más de 50 dominios exige estandarización. TrekMail permite aplicar una plantilla DNS uniforme a todos los tenants de clientes. En los planes Starter y Agency, el SMTP administrado se ocupa de la reputación de IP y de las cabeceras de entrega, lo que puede evitar configuraciones complejas de SPF y calendarios propios de calentamiento de IP.

Descubra cómo funciona el alojamiento de correo multidominio para agencias.

Todos los planes de pago incluyen una prueba gratuita de 14 días y requieren una tarjeta. El plan Nano no requiere tarjeta.

Conclusión

Al trasladar un buzón a otro proveedor, el cambio de DNS es uno de los puntos más delicados. Reduzca los TTL con antelación, combine los registros de autenticación, cambie los MX durante una ventana de mantenimiento y supervise los informes DMARC durante 72 horas. Ese es el procedimiento.

Si prefiere evitar la gestión manual de varios registros DNS, pruebe TrekMail gratis y utilice el panel para validar la configuración.