Dominios y correo · Elaine System
DNS para empresas: A, AAAA, CNAME, MX y TXT sin confundir dominio y hosting
Entiende qué publica cada registro DNS, cómo se conectan web y correo corporativo, y qué documentar antes de cambiar una zona.
Qué hace DNS y qué no hace
El Sistema de Nombres de Dominio publica información que permite localizar servicios asociados con nombres como www.example.com. Un registro puede señalar una dirección de red, indicar dónde recibir correo o publicar un valor de verificación. El navegador y otros clientes consultan esa información para decidir a qué destino conectarse.
DNS no es el dominio registrado, el servidor web ni el proveedor de correo. Son piezas distintas: el registrador administra la titularidad del nombre; la zona DNS publica registros; el hosting ejecuta o entrega el sitio; y el servicio de correo gestiona buzones y entrega de mensajes. Una sola empresa puede ofrecer varios de estos servicios, pero sus funciones siguen siendo diferentes.
Registros frecuentes en una operación empresarial
Los tipos siguientes cubren tareas habituales. La documentación oficial deCloudflare describe estos registros y sus usos; cada proveedor puede presentar formularios o limitaciones particulares.
| Tipo | Función común | Uso típico |
|---|---|---|
| A | Relaciona un nombre con una dirección IPv4. | Destino de un sitio o servicio. |
| AAAA | Relaciona un nombre con una dirección IPv6. | Destino disponible sobre IPv6. |
| CNAME | Hace que un nombre funcione como alias de otro nombre. | Apuntar un subdominio a un destino administrado. |
| MX | Indica servidores que reciben correo para el dominio. | Entrega entrante de correo corporativo. |
| TXT | Publica texto asociado con un nombre. | Verificaciones y políticas de correo como SPF, DKIM o DMARC. |
La tabla explica propósitos, no valores para copiar. Las direcciones de destino, nombres de servidor y cadenas de autenticación deben venir del proveedor que administra el sitio o el correo. Un dato ilustrativo con example.comno configura un dominio real.
DNS también participa en la autenticación del correo
Para el correo saliente, tres mecanismos suelen publicarse en registros TXT. SPF declara qué remitentes están autorizados por el dominio. DKIM permite comprobar una firma asociada al mensaje. DMARC define cómo debe procesarse correo que no supera las comprobaciones y puede habilitar informes. Ninguno garantiza por sí solo la llegada a la bandeja de entrada: también intervienen reputación, contenido, políticas del receptor y la configuración del servicio.
No inventes ni reutilices valores vistos en una guía ajena. Solicita los valores exactos al proveedor de correo; confirma el nombre del host, el tipo de registro, el contenido y si el panel añade el dominio automáticamente. Antes de publicar SPF, revisa si ya existe una política para no dejar configuraciones duplicadas o contradictorias. La documentación de Cloudflare ofrece descripciones deMX, DKIM, SPF y DMARC, mientras el proveedor de correo debe dar los valores propios de la cuenta.
Antes de modificar una zona DNS
- Identifica quién es autoridad. Comprueba qué servidores de nombres delega el registrador. Editar una zona en un panel que no es autoritativo no cambia las respuestas públicas.
- Haz inventario. Guarda los registros existentes, su propósito conocido y el TTL indicado. Registra qué sitio, correo, verificación o integración depende de cada entrada.
- Obtén los valores del destino. Confirma con el proveedor del sitio o correo los nombres, tipos, prioridades y valores exactos requeridos.
- Planea el cambio y la reversión. Define qué registro cambiará, qué servicio podría verse afectado, cómo observarás el resultado y qué valor anterior restaurarías si falla.
- Valida por separado. Revisa resolución del sitio y envío/recepción de correo. Un sitio que abre no prueba que el correo funcione, y un correo enviado no prueba que todos los registros estén bien.
El TTL orienta cuánto tiempo puede conservar una respuesta una caché; no es un botón de propagación inmediata. Tras un cambio, distintos resolutores y dispositivos pueden seguir observando respuestas anteriores durante el periodo de caché correspondiente. Consulta las instrucciones del proveedor para el procedimiento concreto de migración.
Errores que conviene evitar
- Reemplazar toda la zona DNS cuando solo hacía falta modificar un registro.
- Borrar registros de correo o verificación porque parecen irrelevantes para la web.
- Suponer que el hosting, el correo y el registrador comparten necesariamente el mismo proveedor.
- Copiar IP, MX o cadenas SPF/DKIM de un ejemplo sin confirmar que pertenecen a la cuenta actual.
- Declarar la migración terminada tras una sola consulta o una sola prueba desde una red.
La lección principal es sencilla: trata cada modificación DNS como un cambio de infraestructura. Conserva el estado previo, conoce el servicio dependiente y valida web y correo como recorridos diferentes.
Fuentes oficiales
Confirma la vigencia de estas fuentes. Documentación, requisitos y comportamientos pueden cambiar; confirma la guía aplicable a tu versión y proveedor antes de modificar sistemas.