Tu proveedor de hosting te envía un mensaje: «Tienes que cambiar el registro A».
Google te pide añadir un TXT para verificar el dominio.
La plataforma con la que vas a enviar newsletters quiere que configures un CNAME y varios registros para autenticar el correo.
O estás trasladando tu WordPress a otro servidor y alguien te dice: «Cuando esté todo preparado, cambiamos las DNS».
Y aquí empieza el problema.
Porque probablemente sabes entrar en WordPress, cambiar un texto, publicar una entrada o sustituir una fotografía. Pero cuando llegas al panel del dominio y aparecen términos como A, CNAME, MX, TXT, NS o TTL, es bastante razonable preguntarse qué puedes tocar sin romper algo.
La respuesta corta es: los DNS son una de esas partes de tu infraestructura donde un cambio aparentemente pequeño puede tener consecuencias importantes.
Puedes dejar la web inaccesible, interrumpir la recepción del correo corporativo o hacer que los mensajes que envías desde tu dominio empiecen a tener problemas de entrega.
No necesitas convertirte en administrador de sistemas para evitarlo. Pero sí te interesa entender qué estás cambiando, quién controla actualmente tus DNS y qué servicios dependen de ellos.
Cuando escribes midominio.com en un navegador, este necesita averiguar a qué servidor debe conectarse.
Internet no trabaja realmente con el nombre comercial de tu dominio, sino con direcciones técnicas. El DNS —Domain Name System— se encarga de relacionar unas con otras.
Una comparación habitual es pensar en la agenda del teléfono:
Nombre → número de teléfono
En DNS tendríamos algo parecido:
midominio.com → servidor donde se encuentra la web
Hay una diferencia importante que conviene tener clara:
Tu DNS no contiene tu web. Indica dónde encontrarla.
Tu WordPress, sus imágenes y su base de datos pueden estar alojados en un servidor completamente distinto de la empresa donde compraste el dominio.
Y el correo puede estar incluso en un tercer proveedor.
Esta separación explica por qué puedes cambiar de hosting sin cambiar de dominio o utilizar Microsoft 365 o Google Workspace para el correo mientras mantienes WordPress en otro proveedor.
Aquí suele empezar buena parte de la confusión.
En una web empresarial pueden intervenir varias empresas diferentes.
El registrador es la empresa donde tienes registrado el dominio.
Los nameservers o servidores de nombres determinan quién mantiene la zona DNS activa del dominio.
El hosting aloja tu web.
Y después pueden existir otros proveedores para el correo, newsletters, CRM, CDN, analítica o cualquier otro servicio conectado.
No tienen por qué ser la misma empresa.
Por eso, cuando alguien te dice «entra donde tienes el dominio y cambia este registro», esa instrucción puede ser incorrecta. Si los nameservers apuntan a otro proveedor, la configuración DNS que realmente está funcionando puede encontrarse en otro panel.
Antes de cambiar nada hay que saber quién tiene la autoridad sobre esa zona DNS.
No necesitas memorizar todos los tipos de registros que existen. Para gestionar una web de empresa hay cinco que conviene reconocer.
El registro A relaciona un dominio o subdominio con una dirección IPv4.
Por ejemplo:
midominio.com → 203.0.113.10
Esa IP correspondería al servidor al que quieres dirigir las visitas.
Es uno de los registros que normalmente se modifica durante una migración de hosting de WordPress.
El riesgo es fácil de entender: si introduces una IP equivocada, eliminas el registro necesario o haces el cambio antes de que la nueva web esté preparada, los visitantes pueden dejar de llegar a tu WordPress.
Por eso el orden importa.
Primero se prepara y comprueba la web en el servidor nuevo. Después se modifica el DNS.
Un CNAME permite que un nombre apunte a otro nombre de dominio en lugar de directamente a una dirección IP.
Por ejemplo:
www.midominio.com → midominio.com
También se utiliza mucho para conectar subdominios con servicios externos.
Imagina que una plataforma te pide crear:
newsletter.midominio.com → servicio.proveedor.com
No necesitas saber dónde aloja técnicamente ese servicio el proveedor. El CNAME establece el alias y el proveedor puede gestionar después su propia infraestructura.
Esto resulta cómodo, pero hay que comprobar que el nombre que vas a utilizar no tenga ya otro registro incompatible.
Los registros MX —Mail Exchange— indican qué servidores deben recibir los mensajes enviados a las cuentas de tu dominio.
Si utilizas:
ventas@midominio.com
los servidores de Internet consultan los MX de midominio.com para averiguar dónde deben entregar ese correo.
Por eso cambiar el hosting de una web y cambiar el correo son dos operaciones diferentes.
Puedes tener:
Y todo funcionar perfectamente.
El problema aparece cuando durante una migración alguien modifica los DNS pensando únicamente en la web y se olvida del correo.
La página puede seguir funcionando mientras la empresa deja de recibir mensajes.
Para un negocio, ese fallo puede ser bastante más grave que unas horas con la web caída.
Los registros TXT permiten publicar determinada información asociada al dominio.
Te los encontrarás continuamente cuando conectes servicios externos.
Google puede pedirte uno para demostrar que el dominio es tuyo. Una herramienta de email marketing puede utilizarlo para verificar que tiene permiso para enviar mensajes en tu nombre.
También se utilizan para mecanismos fundamentales de autenticación del correo como SPF, DKIM y DMARC.
Simplificando mucho:
No son detalles reservados a grandes empresas.
Si utilizas el correo corporativo para enviar presupuestos, facturas, comunicaciones comerciales o newsletters, esta configuración influye en la entregabilidad y protección de tu correo.
Un error frecuente es ir añadiendo registros TXT cada vez que una aplicación lo solicita sin comprobar qué existe previamente. Con SPF, por ejemplo, no se trata simplemente de crear un segundo registro cada vez que incorporas un nuevo servicio de envío.
Los registros NS —Name Servers— indican cuáles son los servidores de nombres autoritativos del dominio.
Dicho de forma sencilla: determinan dónde está la configuración DNS que manda.
Cambiar un registro A modifica un destino concreto.
Cambiar los nameservers es una operación de mucho mayor alcance.
Si sustituyes unos NS por otros, la nueva zona debe contener correctamente todo lo que necesitas conservar: web, correo, subdominios, verificaciones y demás servicios.
Por eso deberías desconfiar de una instrucción del tipo:
«Para utilizar nuestro servicio solo tienes que cambiar tus nameservers por estos».
Puede ser exactamente lo que haya que hacer. Pero antes conviene saber qué configuración estás abandonando y si está reproducida correctamente en el nuevo proveedor.
Los cambios DNS no siempre son instantáneos.
Cada registro tiene asociado un TTL —Time To Live—, que indica durante cuánto tiempo puede mantenerse en caché determinada información antes de volver a consultarla.
Esto provoca una situación desconcertante durante algunos cambios.
Tú puedes entrar en la web y ver el servidor nuevo mientras un cliente sigue llegando al antiguo. En el móvil puede aparecer una versión y desde el ordenador otra.
No significa necesariamente que algo esté roto.
Los resolvers, proveedores y dispositivos pueden estar utilizando temporalmente información almacenada anteriormente.
Por eso se habla de propagación DNS.
Según la configuración y las cachés implicadas, los cambios pueden apreciarse rápidamente o tardar bastante más. La conocida referencia de «hasta 24-48 horas» es un margen habitual, no una regla que obligue a esperar siempre ese tiempo.
Esto también explica por qué una migración profesional no debería consistir en cambiar la IP y esperar a ver qué pasa.
Supongamos que quieres abandonar tu alojamiento actual porque es lento, tienes problemas de soporte o necesitas una infraestructura mejor.
Un error sería contratar el nuevo servidor y cambiar inmediatamente el registro A.
Primero debería migrarse WordPress.
Después hay que comprobar que funcionan:
También deberías disponer de una copia recuperable antes de iniciar el proceso. En nuestra guía sobre copias de seguridad en WordPress explicamos por qué tener un backup no es lo mismo que saber que podrás restaurarlo cuando lo necesites.
Solo cuando el nuevo servidor está preparado tiene sentido cambiar el DNS.
Nuestra guía para migrar WordPress de hosting explica el proceso completo con más detalle.
Aquí el riesgo es diferente.
Supongamos que hasta ahora utilizabas las cuentas de correo proporcionadas por tu hosting y decides trasladarlas a un proveedor especializado.
No basta con crear las nuevas cuentas.
Normalmente habrá que modificar:
Y hay que hacerlo en el orden adecuado.
Uno de los peores escenarios es mezclar durante tiempo indefinido configuraciones antiguas y nuevas sin saber qué servidor debería recibir o enviar realmente el correo.
Antes de modificar los MX conviene inventariar las cuentas existentes, preparar las nuevas, estudiar cómo se migrarán los mensajes antiguos y comprobar la autenticación.
Tu prioridad empresarial aquí no debería ser “cambiar los MX”. Debería ser “hacer la transición sin perder correo”.
Ese cambio de perspectiva es importante.
Este probablemente sea el caso que más veces te encontrarás.
Contratas una plataforma de email marketing.
Configuras un CRM.
Das de alta un servicio para enviar correos desde los formularios.
Verificas el dominio en una plataforma.
Y aparece una pantalla diciendo:
Añade este TXT.
Crea este CNAME.
Muchas veces es una operación sencilla. El problema es tratar todas esas instrucciones como si fueran inocuas.
Antes de guardar un nuevo registro conviene comprobar:
Cinco minutos de comprobación pueden ahorrar varias horas intentando descubrir después por qué ha dejado de funcionar algo que aparentemente no tenía relación con el cambio.
Es probablemente el error con mayor capacidad para provocar daños de golpe.
El nuevo proveedor te facilita dos nameservers. Los introduces en el registrador y aparentemente has seguido correctamente sus instrucciones.
Pero la zona anterior contenía los MX del correo, varios TXT de autenticación, un subdominio para una aplicación y alguna verificación.
Si esos registros no existen en la nueva zona, cambiar los NS puede hacer que todos ellos dejen de aplicarse.
La pregunta antes de hacerlo es sencilla:
¿Tenemos replicada en el nuevo proveedor toda la configuración que necesitamos conservar?
Si no puedes responderla, no hagas todavía el cambio.
Otro clásico.
Quedan MX del antiguo hosting y se añaden encima los del nuevo proveedor.
El resultado no es necesariamente un fallo limpio y fácil de detectar. Precisamente por eso puede resultar peor: aparecen rebotes, entregas inconsistentes o comportamientos difíciles de reproducir.
La configuración debe responder a una arquitectura deliberada, no a una acumulación histórica de registros.
Visualmente son simplemente dos opciones dentro del panel, pero hacen cosas diferentes.
Un registro A apunta directamente a una IP.
Un CNAME apunta a otro nombre.
Además, existen restricciones sobre dónde puede utilizarse un CNAME estándar. Algunos proveedores ofrecen mecanismos equivalentes como ALIAS, ANAME o CNAME flattening para determinados casos, pero no debes asumir que todos los paneles funcionan igual.
Si las instrucciones del proveedor dicen A, utiliza A. Si dicen CNAME, utiliza CNAME. Y si entran en conflicto con algo existente, no borres lo anterior hasta entender para qué servía.
Este es menos espectacular, pero probablemente sea uno de los más frecuentes.
Alguien añadió hace tres años:
selector1._domainkey.midominio.com
¿Para qué?
Nadie lo sabe.
¿Se puede borrar?
Quizá.
Y ese «quizá» acaba convirtiendo cada limpieza de DNS en arqueología digital.
Una pyme debería conservar como mínimo:
No hace falta montar un sistema complejo. Una documentación sencilla ya cambia completamente la capacidad para diagnosticar problemas.
Delegar la gestión técnica no significa perder el control.
De hecho, hay varias preguntas que cualquier propietario de una web empresarial debería poder responder:
¿Dónde está registrado mi dominio?
¿Quién gestiona actualmente sus DNS?
¿Quién tiene acceso a esa cuenta?
¿Dónde está alojada mi web?
¿Quién gestiona mi correo?
¿Qué otros servicios dependen del dominio?
No necesitas saber de memoria la IP de tu servidor ni la sintaxis de DMARC.
Necesitas conocer quién controla cada pieza y quién responde cuando hay que modificarla.
Es la misma filosofía que defendemos al explicar qué partes de WordPress puedes gestionar tú mismo y cuáles conviene delegar.
Puedes publicar contenidos o realizar cambios cotidianos sin depender constantemente de un técnico. Pero hay determinadas operaciones donde el coste de equivocarse es muy superior al ahorro de hacerlas por tu cuenta.
DNS es una de ellas.
El mantenimiento de WordPress suele asociarse a actualizar plugins, realizar copias o vigilar la seguridad.
Es una visión demasiado limitada.
Una web empresarial depende de muchas piezas externas a WordPress: dominio, DNS, certificado SSL, servidor, correo, CDN, formularios, servicios SMTP, herramientas de analítica y plataformas de terceros.
Por eso defendemos un mantenimiento WordPress orientado al funcionamiento real del negocio, no simplemente a entrar una vez al mes en el panel y pulsar «Actualizar».
La gestión DNS entra dentro de esa misma lógica.
Cuando hay que intervenir en los DNS de una web, el primer paso no debería ser editar registros.
Debería ser hacer inventario.
Hay que revisar, entre otras cosas:
El objetivo es construir un pequeño mapa de dependencias.
Así sabemos qué puede modificarse y qué debemos conservar.
Antes de una modificación importante conviene guardar la configuración existente.
Dependiendo del proveedor puede hacerse mediante una exportación de la zona, documentación de los registros o capturas complementarias.
Después se prepara el cambio, se aplica y se comprueban los servicios afectados.
En una migración, por ejemplo, no basta con abrir la portada y comprobar que carga.
Hay que verificar también aquello que realmente utiliza el negocio.
Y documentar el resultado.
Es el mismo criterio que aplicamos a las actualizaciones importantes de WordPress: preparar, hacer copia, cambiar, comprobar y conservar una vía de recuperación.
Con los años es habitual encontrar verificaciones de servicios que ya no existen, subdominios abandonados o configuraciones de antiguos proveedores.
No todo registro desconocido debe eliminarse.
Precisamente lo peligroso es borrar por intuición.
Pero una revisión periódica permite documentar la infraestructura y retirar configuraciones obsoletas cuando se ha comprobado que ya no tienen ninguna función.
Esta gestión encaja dentro de nuestros servicios de mantenimiento y soporte WordPress: ocuparnos de la parte técnica para que el propietario de la empresa no tenga que convertirse en administrador de sistemas cada vez que incorpora una herramienta nueva.
No necesitas aprender a administrar servidores DNS para gestionar correctamente la web de tu empresa.
Pero tampoco conviene que tu dominio sea una caja negra.
Quédate con cinco ideas:
Sobre todo, aplica una regla sencilla:
Antes de cambiar un DNS, averigua qué hace el registro actual y guarda la configuración que funciona.
Si alguien te ha pedido modificar los nameservers, estás preparando una migración de hosting, quieres cambiar el correo corporativo o simplemente has heredado una configuración DNS que nadie sabe explicar, en arreglotuweb.com podemos revisar primero cómo está configurado tu dominio y realizar los cambios de forma controlada.
Puedes contactar con nosotros para revisar la configuración antes de tocarla.
Porque con los DNS, saber volver atrás suele ser bastante más importante que saber dónde está el botón Guardar.
