Cambiar de proveedor de correo del dominio: guía DNS

Puedes cambiar el alojamiento del correo de tu dominio conservando direcciones si reconstruyes sus buzones, alias y permisos. Una modificación DNS incorrecta puede afectar al flujo. La copia de mensajes y el cambio de recepción son tareas distintas; mezclarlas puede provocar rebotes o entregas repartidas.

Para una visión general, consulta el correo para empresas. Esta guía se centra en trasladar el servicio de un dominio administrado entre proveedores, coordinando MX, SPF, DKIM y DMARC mientras los usuarios trabajan.

Prepara buzones antes de copiar, reduce TTL con antelación, publica la autenticación nueva y cambia MX cuando el destino esté probado. Alterar ese orden puede añadir trabajo de corrección.

Qué significa trasladar el correo de un dominio

Conservas dominio y direcciones autorizadas, pero cambias el proveedor de recepción y la autenticación de los servicios que envían. No es un traslado de registrador ni permite modificar el dominio de una cuenta personal. La copia también importa; DNS, cachés y autenticación requieren coordinación.

Normalmente son tres tareas:

1. Copiar mensajes antiguos al destino, con los buzones de destino creados previamente.
2. Completar y verificar los mismos buzones, alias y reenvíos, con sus permisos.
3. Cambiar DNS si se traslada la recepción del dominio propio.

No cambies MX antes de preparar los buzones y verificar la copia previa. También prueba SPF y DKIM: un error puede afectar a la autenticación saliente, sin que determine por sí solo recepción en spam o rechazo.

Divide el trabajo en preparación, transición y estabilización. El texto describe importación IMAP de Gmail, Outlook, Yahoo, iCloud u otro servidor en Starter y superiores; verifica acceso y compatibilidad. IMAP copia mensajes, no calendarios, contactos ni todos los ajustes. Consulta imapsync para la operación de copia.

Fase 1: preparar el cambio con 24-48 horas de antelación

La preparación puede reducir riesgos. Crea primero buzones de destino, prepara autenticación, reduce TTL y copia el correo. El margen depende de cachés y del entorno, no de un plazo universal.

1. Reducir TTL de los registros existentes

300 segundos es un TTL ilustrativo para MX, SPF y DMARC si tu proveedor lo permite. Un margen de 24-48 horas puede servir de referencia, no garantiza actualización global; cambiarlo cinco minutos antes no elimina cachés anteriores. Estas consultas son básicas: la última combina argumentos y no es una comprobación fiable de DMARC; los TXT de la raíz tampoco verifican el selector DKIM:

dig example.com MX

dig example.com TXT

dig example.com TXT _dmarc.example.com

Si el TTL anterior era 3600 o 86400, algunos resolutores conservarán respuestas hasta su caducidad. Empieza días antes, no a las 4:55 PM del viernes, y comprueba por separado autoridades y resolutores relevantes.

2. Copiar mensajes antes de cambiar MX

Importa mientras el origen sigue activo, después de crear el buzón de destino. El asistente TrekMail copia desde cuentas IMAP externas según acceso y compatibilidad; verifica contenido, fechas, carpetas e indicadores en una prueba previa.

Vincula el dominio, crea el buzón y consulta iniciar una importación en el panel. El importador usa credenciales IMAP directas: contraseñas de aplicación Gmail según políticas o un acceso alternativo autorizado con otra herramienta si OAuth es obligatorio. El texto describe TrekMail sin POP3; eso no hace que POP rompa siempre la continuidad, pero debes respaldar correo local no sincronizado antes de retirar perfiles.

3. Completar todas las identidades de destino

Antes de cambiar tráfico, crea y prueba cada buzón, alias, reenvío y dirección comodín. Revisa permisos, restricciones de reenvío y los casos menos habituales.

Ejemplo: billing@, support@, careers@, noreply@, un buzón comodín y un reenvío antiguo al Gmail del fundador. Omitir uno puede dejar mensajes sin su ruta prevista aunque gran parte de la migración funcione.

Para varias marcas, un modelo multidominio puede simplificar tareas dentro de sus límites. Consulta alojamiento de correo para varios dominios si necesitas escala, no solo una transición.

4. Fusionar SPF antes del traslado

Durante la superposición, autoriza todos los servicios legítimos que todavía envían, antiguos y nuevos, para la identidad SMTP evaluada. El RFC 7208 limita a 10 los mecanismos y modificadores evaluados que requieren consultas DNS, incluidos los anidados; no cuenta todos los paquetes o consultas de red. Este ejemplo solo corresponde si esos proveedores siguen autorizados:

v=spf1 include:_spf.google.com include:spf.trekmail.net -all

El texto describe SMTP externo en TrekMail Free y gestionado en planes de pago; comprueba condiciones y rutas reales. Publica una política SPF por nombre DNS, no dos políticas separadas; otros TXT no relacionados pueden coexistir.

5. Publicar DKIM y revisar la política DMARC

Publica el selector nuevo antes del cambio y configura la firma real del proveedor. No sobrescribas el antiguo mientras siga firmando; conserva su clave pública mientras mensajes en tránsito puedan necesitarla. Cambiar a p=none es una decisión temporal opcional del propietario tras evaluar riesgos, no un paso obligatorio ni una garantía contra rechazos. Puedes mantener las solicitudes de cuarentena o rechazo de DMARC si la autenticación está comprobada.

Considera también caché negativa: un selector consultado antes de existir puede quedar ausente en caché según el SOA descrito en el RFC 2308. Publica pronto y verifica caducidad y respuestas reales.

Fase 2: ejecutar la transición

Verifica registros en DNS autoritativo, cambia MX cuando el destino esté listo, revisa resolutores públicos y prueba recepción y envío entre cuentas reales. La duración depende del entorno.

Haz el cambio previsto, evitando tareas DNS no relacionadas. Mantén un plan de reversión y el origen disponible para recepción tardía y sincronización administrativa.

1. Comprobar que el destino está preparado

Revisa las comprobaciones posibles antes de MX y prueba los buzones. Active y marcas verdes dependen del estado publicado y no prueban todo el flujo. Consulta añadir un dominio a TrekMail. El texto de marzo de 2026 muestra este ejemplo; usa los valores actuales de tu cuenta y una política DMARC aprobada, no lo publiques a ciegas:

MX   @              mail.trekmail.net.   priority 10
TXT  @              v=spf1 include:spf.trekmail.net -all
TXT  dkim._domainkey  [unique value from dashboard]
TXT  _dmarc         v=DMARC1; p=quarantine;

Sustituye MX de Google Workspace, Microsoft 365, Zoho, cPanel o registrador cuando corresponda. Sus prioridades suelen indicar preferencia y alternativa, no reparto uniforme; mantener destinos que aceptan correo puede dejar entregas en diferentes servidores.

2. Cambiar MX y mantener TTL bajo

Reemplaza el conjunto MX del dominio propio tras validar la preparación. Mantener 300 durante la transición es una opción ilustrativa; no obliga a todos los emisores a actualizar al mismo tiempo.

dig @8.8.8.8 example.com MX

dig @1.1.1.1 example.com MX

Consulta al menos dos resolutores públicos y compara la autoridad. Envía pruebas desde fuera al dominio y desde el buzón nuevo hacia fuera; repite las pasadas de cambios para llegadas tardías, movimientos e indicadores, incluidos mensajes con fecha antigua.

3. Revisar clientes IMAP

Comprueba ajustes actuales: IMAP imap.trekmail.net en 993 con TLS y SMTP smtp.trekmail.net en 465 con TLS implícito o 587 con STARTTLS. Verifica cadena de certificados, nombre del servidor y dirección completa y contraseña del buzón, no del panel. Consulta ajustes IMAP y SMTP para clientes.

«Puedo enviar pero no recibir» requiere diagnóstico: revisa DNS, buzones y alias, cuotas, filtros, carpetas, cachés y conexión del cliente. Usa pruebas y registros para identificar la causa real.

Fase 3: observar las primeras 72 horas

Las primeras 72 horas son una ventana ilustrativa, no prueba de finalización. Vigila recepción, autenticación y servicios que aún usan el origen. Retira autorizaciones temporales solo tras confirmar que ya no hacen falta.

El cambio puede parecer completo después de diez minutos y mostrar dependencias durante los días siguientes. Sigue supervisando según el tráfico y los servicios.

1. Buscar tráfico que usa el proveedor antiguo

CRM, escáneres, formularios WordPress, facturación y soporte pueden conservar SMTP antiguo. Revisa cabeceras y registros; actualiza y prueba cada integración antes de retirar su autorización o endurecer la política.

2. Vigilar autenticación, no solo entrega

Un mensaje entregado puede tener fallos de autenticación; eso no prueba por sí solo una caída de reputación. Comprueba resultados añadidos por el receptor de confianza y alineación con From. DMARC puede pasar mediante SPF válido y alineado o cualquier firma DKIM válida y alineada. El reenvío puede afectar SPF, pero DKIM solo ayuda si sigue válido y alineado.

Si reenvías fuera, consulta reenviar correo del dominio a Gmail para efectos y configuración.

3. Retirar superposición tras verificar el tráfico

Retira del SPF los servicios que ya no están autorizados y conserva registros DKIM antiguos mientras colas o verificaciones de mensajes reenviados los necesiten. Puedes volver a un TTL ilustrativo de 3600 según la operación. Si elegiste p=none, revisa inventario, pruebas e informes antes de recuperar las solicitudes de cuarentena o rechazo de DMARC.

La retirada verificada forma parte del traslado: evita mantener autorización innecesaria, sin borrar claves o servicios aún utilizados por un plazo fijo.

Improvisación y proceso controlado

No confundas el cambio de alojamiento con un traslado de registrador. Prepara buzones y copia, planifica una única sustitución MX, valida autenticación y usa herramientas con comprobaciones que no sustituyan pruebas completas.

Si administras más de un dominio, compara TrekMail por dominios propios, buzones IMAP, dirección comodín, SMTP externo en Nano o incluido en planes de pago, reenvío, importación y API según condiciones actuales. El texto sitúa Starter desde $3.50 al mes y menciona Free, Starter, Pro, Agency y Enterprise. Consulta los precios de TrekMail para límites y costes vigentes.

Lista final del traslado

La lista resume preparación, copia, identidades, SPF, DKIM, decisión DMARC, transición, pruebas y retirada verificada. La lista no autoriza cambiar MX antes de crear y comprobar el destino ni obliga a relajar políticas.

1. Reducir TTL con un margen ilustrativo de 24-48 horas y considerar cachés anteriores.
2. Copiar el correo por IMAP con los buzones de destino ya creados.
3. Completar y verificar buzones, alias, reenvíos y dirección comodín.
4. Fusionar autorizaciones SPF en una política por nombre.
5. Publicar DKIM con selector nuevo y configurar la firma real.
6. Considerar p=none solo si el propietario aprueba el ajuste temporal y sus riesgos.
7. Verificar destino, acceso y comprobaciones disponibles.
8. Reemplazar MX publicados conservando recepción antigua temporal.
9. Probar entrada y salida y repetir sincronizaciones de cambios.
10. Después de una ventana ilustrativa de 72 horas, evaluar tráfico y claves en tránsito antes de retirar autorizaciones o ajustar DMARC.

Un traslado controlado exige inventario, pruebas y seguimiento, no solo editar ajustes. TrekMail puede ofrecer un modelo multidominio con almacenamiento compartido e importación IMAP según el plan; evalúa límites y costes sin asumir ausencia de interrupciones, pérdida o suplementos.