Al migrar WordPress de hosting, el correo suele fallar por DNS, no por la web. Lo más habitual es que se hayan roto los registros MX, SPF, DKIM o DMARC, o que los nameservers apunten a una zona DNS distinta a la que maneja el correo.
Errores en migración entre hosts: DNS y pérdida de emails se resuelven revisando dónde debe vivir el DNS antes de moverlo, validando buzones y TTL, y comprobando que la propagación no haya dejado el correo apuntando al sitio equivocado. Si el correo falla tras cambiar de hosting, mira primero si afecta a recibir, a enviar o a ambos.
Qué hacer si el correo falla tras migrar
Si el correo falla tras cambiar de hosting, empieza por mirar si el problema afecta a recibir, a enviar o a ambos. Esa diferencia te ahorra tiempo, porque no se corrige igual un fallo de MX que un fallo de SMTP.
El primer filtro es muy sencillo. Abre un buzón externo, como Gmail o Outlook, y manda un correo a tu dominio, luego responde desde ese dominio y mira qué pasa. Si la web abre pero no entran correos, el problema suele estar en los registros MX o en el proveedor que recibe el correo. Si salen mensajes de error al enviar, la causa suele estar en autenticación o en el servidor SMTP.
Síntomas que confirman el fallo
Un correo que no llega es distinto de un correo que llega tarde. Si ves mensajes intermitentes, casi siempre hay propagación DNS en marcha o un TTL bajo que hace que unas consultas vayan al DNS viejo y otras al nuevo.
Si el problema es de recepción, revisa primero el registro MX. Ese registro dice a qué servidor debe ir el correo, como si fuera la dirección de una oficina de reparto. Si apunta al sitio equivocado, el mensaje se pierde por el camino o aterriza en un buzón que no toca.
Si el problema es de salida, mira SPF, DKIM y DMARC. SPF dice qué servidores pueden enviar por tu dominio, DKIM firma el mensaje para demostrar que no se ha alterado, y DMARC indica qué hacer cuando algo falla.
Revisión rápida de DNS y buzones
Haz una revisión en este orden. Primero comprueba qué nameservers están activos. Luego revisa la zona DNS actual y verifica que el dominio sigue apuntando al proveedor correcto de correo, no al hosting nuevo por error.
Después mira si se han creado buzones automáticos en el panel nuevo. Algunos paneles, al detectar un dominio, crean cuentas o rutas de entrega sin pedir permiso. Esto puede sobrescribir el destino real del correo y mezclar el tráfico con un buzón local que nadie usa.
Cuándo parar la migración
Para la migración si no puedes confirmar dónde se gestiona el correo. Mover solo la web suele ser seguro, pero mover el DNS completo sin mapa previo es como cambiar de oficina sin avisar al cartero.
Evita mover los nameservers sin revisar el correo
La causa más común del fallo no está en WordPress, sino en la decisión de mover o no mover los nameservers. Nameservers son los servidores que dicen dónde está la zona DNS del dominio, es decir, el plano que reparte la web, el correo y otros servicios.
La mayoría de guías dicen que hay que mover todo al nuevo hosting. Lo que no mencionan es que muchas empresas usan un proveedor distinto para el email, como Google Workspace o Microsoft 365. En ese caso, mover el DNS completo solo añade riesgo y no aporta nada a la web.
Mueve solo la web si el correo vive fuera
Si el correo está en Google Workspace, Microsoft 365, un servidor independiente o un servicio de email externo, deja el DNS donde funciona y cambia solo el registro A o el CNAME del sitio. Es la forma más limpia de mover WordPress sin tocar el correo.
Un cambio parcial suele tardar menos y da menos sustos. Si ya sabes qué dominio usa la web y qué servidor usa el correo, la corrección puede ser rápida; si no, se alarga.
Cambia todo solo si vas a copiar la zona
Si decides mover nameservers, copia antes toda la zona DNS. Eso incluye MX, SPF, DKIM, DMARC, A, CNAME y cualquier subdominio que envíe o reciba correo.
La forma rápida es exportar la zona desde el proveedor viejo y replicarla en el nuevo. La forma correcta es verificar que cada registro coincide, sobre todo las prioridades MX y los valores SPF.
Cambiar nameservers solo compensa si vas a mantener la misma lógica de correo en el nuevo panel y has copiado cada registro de forma exacta.
Usa este criterio para decidir
Si el correo depende del mismo hosting que la web, mover todo puede tener sentido, pero solo con copia completa y prueba previa. Si el correo depende de otro proveedor, conservar el DNS antiguo es más seguro y suele ser la mejor opción.
No siempre es buena idea cambiar los nameservers cuando migras un hosting. Si el dominio ya usa un proveedor externo para el correo, lo más seguro suele ser conservar la zona DNS donde está funcionando y mover solo el registro A o el CNAME de la web. Así evitas que una migración de hosting arrastre por error los MX o los ajustes de autenticación del correo. Por ejemplo, muchas empresas alojan WordPress en un servidor y el email en Google Workspace o Microsoft 365; en ese escenario, mover el DNS completo añade riesgo sin beneficio real.
Solo compensa trasladar nameservers cuando vas a replicar la zona DNS entera y tienes claro qué servicios dependen de ella.
Revisa MX, SPF, DKIM y DMARC antes
Antes de tocar el DNS, valida los cuatro registros que más suelen romper el correo. MX define el destino de entrada. SPF define qué servidores pueden enviar. DKIM añade una firma técnica. DMARC decide qué hacer si algo no cuadra.
Un registro correcto hoy puede dejar de serlo mañana si el panel nuevo cambia la zona o si un asistente automático reescribe el dominio. Por eso conviene revisar valores, no solo nombres.
Comprueba el MX y su prioridad
Mira que el MX apunte al proveedor real de correo, no al host web. Si usas varios MX, revisa la prioridad, porque el número más bajo suele ser el primero en usarse.
Alinea SPF, DKIM y DMARC
Copia el SPF exactamente como lo daba el proveedor anterior o actualízalo con los nuevos servidores autorizados. DKIM debe seguir firmando desde el mismo selector o con uno nuevo, pero bien publicado.
DMARC conviene dejarlo en modo de vigilancia primero, si aún no has validado todo. Eso permite detectar fallos sin bloquear mensajes de golpe.
| Registro |
Qué controla |
Fallo típico tras migrar |
| MX |
Dónde entra el correo |
Recepción rota o mensajes perdidos |
| SPF |
Qué servidores pueden enviar |
Rebotes o spam |
| DKIM |
Firma del mensaje |
Correo no validado |
| DMARC |
Qué hacer si algo falla |
Bloqueos o avisos de política |
Guarda una copia antes del cambio
Haz una copia de la zona DNS completa antes de mover nada. Es tu red de seguridad si algo sale mal y necesitas volver atrás en minutos.
Antes de mover nada, conviene hacer una checklist de correo y DNS para no dejar huecos invisibles. Revisa que los registros MX apunten al proveedor correcto, que SPF incluya solo los servidores autorizados, que DKIM esté publicado con el selector activo y que DMARC no esté en una política agresiva mientras dura la transición. Comprueba también el TTL de los registros críticos, porque un valor alto puede alargar la propagación DNS durante horas, y verifica que los buzones de correo existen en el panel correcto.
En migraciones con Google Workspace o Microsoft 365, este paso es clave: la web puede funcionar al instante, pero un MX mal copiado puede hacer que el correo entrante se pierda o rebote sin aviso.
Diagnostica el fallo por síntomas reales
El diagnóstico debe empezar por el síntoma, no por la herramienta. Si no recibes correos, si envías pero no te contestan, si hay rebotes o si la web apunta al hosting antiguo, cada caso tiene una causa distinta.
Un caso habitual es que el usuario vea la web nueva, pero el correo siga llegando al servidor antiguo o a ningún sitio. Eso suele pasar por propagación DNS parcial.
Si no recibes correos entrantes
Si no entra nada, revisa primero el MX y luego el proveedor real del buzón. Comprueba también que el dominio no siga apuntando al hosting viejo por una caché DNS local.
Si envías pero no recibes respuestas
Si puedes enviar, pero no recibes contestación, suele haber un problema de MX, de reenvío o de filtrado en el destino. También puede pasar que el correo entrante esté llegando a un buzón que nadie revisa.
Si los mensajes rebotan
Un rebote suele hablar de autenticación o de dirección incorrecta. Si el error menciona SPF, DKIM o DMARC, el problema es de identidad del remitente. Si habla de “host not found” o “mail exchanger”, suele ser DNS.
Si la web sigue en el hosting antiguo
Si la web aún apunta al hosting antiguo, el A record o el CNAME no se han actualizado, o el DNS sigue en otro proveedor. Eso no siempre afecta al correo, pero sí indica que la migración quedó a medias.
SMTP, IMAP y POP3 sin líos
SMTP es el canal de salida, IMAP es el que sincroniza el buzón con el servidor y POP3 suele descargar mensajes a un equipo. Si cambias de hosting y solo tocas WordPress, estos tres protocolos no deberían romperse, salvo que el correo dependa del mismo servidor.
Decide entre ayuda manual o soporte
La migración manual sirve si controlas el DNS, el correo y el panel nuevo. La asistencia del hosting ayuda si el proveedor te da una migración guiada, pero no siempre revisa tus registros de email.
La decisión correcta no es “manual o asistida”, sino “quién verifica DNS, correo y propagación antes de tocar el dominio”.
Una buena forma de detectar el problema es ordenar los síntomas por prioridad. Si no recibes correos entrantes, revisa primero MX, buzones y cachés DNS; si puedes enviar pero nadie responde, el fallo suele estar en el correo entrante o en el destino del buzón; si los mensajes rebotan, mira el texto exacto del error para distinguir entre un problema de autenticación con SPF, DKIM o DMARC y un fallo de resolución DNS; y si la web sigue apuntando al hosting antiguo, el conflicto puede estar en el A record, el CNAME o en una propagación DNS incompleta.
Esta lectura por síntomas evita tocar registros que no tienen relación con el fallo real.
Corrige DNS sin romper el correo
Corrige primero el registro que causa el fallo y luego valida el resto. Si el problema es MX, arregla MX. Si el problema es SPF, DKIM o DMARC, corrige autenticación. Si el dominio apunta mal, ajusta A o CNAME.
Ajusta el MX en la zona DNS
Pon el MX del proveedor correcto y elimina duplicados que ya no usas. Si cambias de proveedor de correo, revisa que el destino nuevo esté activo antes de borrar el antiguo.
Alinea SPF, DKIM y DMARC
Actualiza SPF para que incluya solo los servidores que de verdad envían. Revisa DKIM para que la firma siga siendo válida y asegúrate de que DMARC no esté bloqueando algo que aún no has probado.
Verifica en cPanel, cloudflare y otros paneles
En cPanel, revisa zonas DNS, cuentas de correo y enrutamiento del correo. En Cloudflare, confirma que el registro de correo no esté proxyado, porque el correo no debe pasar por la nube naranja.
Haz la prueba final con dos buzones
Prueba con dos cuentas reales, una externa y una interna. Envía desde fuera y responde desde dentro. Esa prueba corta te dice en minutos si la recepción, la salida y la entrega están bien.
Si la prueba entre dos buzones funciona, el cambio está bien; si no, no sigas tocando la web y corrige solo la capa de correo.
No confundas correo, web y dominio
Correo, web y dominio no son lo mismo, aunque compartan dirección. El dominio es el nombre. La web es el contenido que cargas. El correo es el servicio que reparte mensajes.
WordPress no envía como un buzón normal
WordPress no gestiona el correo como un cliente de email. Suele enviar avisos desde el servidor o desde un plugin SMTP.
La propagación no falla igual en todo el mundo
La propagación DNS no llega al mismo tiempo a todas partes. Una oficina puede ver el nuevo servidor y otra seguir en el viejo durante horas.
El SSL no arregla el correo por sí solo
Un certificado SSL/TLS protege la conexión, pero no corrige MX, SPF, DKIM ni DMARC. Si la web ya carga con candado, eso no prueba que el correo esté bien.
No aplica si la migración no toca el dominio ni el DNS, o si el correo está gestionado por un servicio externo y no vas a mover nameservers ni registros. Tampoco es prioritario si el problema es solo de acceso a WordPress, plugins o base de datos sin impacto en email.
Preguntas comunes
¿Por qué WordPress no envía correos electrónicos?
Porque WordPress no es un servidor de correo completo, sino una web que puede lanzar envíos mediante PHP o SMTP.
¿Por qué se envía mi correo electrónico de
Porque el envío y la recepción usan rutas distintas, y la recepción depende del MX y del proveedor de buzón.
¿Cuáles son los errores más comunes en WordPress?
Los fallos más comunes tras una migración son DNS mal copiado, MX ausente, SPF viejo, DKIM roto y buzones automáticos del hosting nuevo.
¿Por qué no funciona mi correo electrónico de
Porque el problema suele estar en la autenticación del envío o en el DNS, no en la página.
¿Cuándo conviene no mover los nameservers?
Conviene no moverlos cuando el correo ya está en un proveedor externo y el hosting nuevo solo va a alojar la web.
¿Cuánto tarda en arreglarse la propagación DNS?
Suele ir de unas horas a 48 horas, según TTL, cachés y proveedor.
¿Cuándo debo pedir ayuda profesional?
Debes pedir ayuda cuando no sabes qué proveedor gestiona el correo o cuando el rebote menciona varios errores a la vez.
El plan concreto
Si vas a cambiar de hosting, decide primero dónde vive el correo. Si está fuera del hosting, conserva el DNS donde funciona y cambia solo la web. Si el correo también se mueve, copia la zona DNS completa, valida MX, SPF, DKIM y DMARC, y prueba dos buzones antes de dar el cambio por bueno.
La regla práctica es esta: si el correo no depende del nuevo hosting, no muevas nameservers; si depende, copia todo y prueba antes de apagar el origen antiguo.
Si ya has cambiado algo y el correo está fallando, vuelve atrás por capas. Primero DNS, luego buzones, después autenticación. Esa secuencia suele resolver el problema sin tocar más de la cuenta.
