DNS e infraestructura
CNAME en apex y errores típicos de alias
Por qué un CNAME en la raíz del dominio choca con MX/TXT y qué alternativas usan los DNS modernos.
11 min de lectura · Actualizado 2026-07-22
La regla RFC que sorprende en migraciones
En DNS clásico (RFC 1034), si un nombre es CNAME, no puede coexistir con otros registros en ese mismo nombre. El apex @tudominio.com no puede ser CNAME y tener simultáneamente MX, TXT (SPF, DKIM, DMARC) o NS — requisitos normales de correo y autenticación.
Paneles de CDN (Cloudflare, Vercel, Netlify) a veces sugieren «apunta CNAME @ a nuestro host». En DNS estándar eso elimina o bloquea MX/TXT existentes. Síntoma: web en CDN pero correo dejó de entrar o SPF desapareció sin que nadie tocara correo explícitamente.
Algunos proveedores implementan ALIAS/ANAME/flattened CNAME en apex: resuelven en authoritative a A/AAAA dinámicos manteniendo MX/TXT paralelos. Funciona solo si tu DNS lo soporta nativamente (Cloudflare CNAME flattening, Route53 ALIAS, DNS Made Easy ANAME).
Antes de aceptar plantilla del proveedor SaaS, lee si pide CNAME en @ y verifica impacto en correo con /toolbox/dns-suite.
Errores típicos en producción
Migración web a hosting gestionado: CNAME @ → host.infrastructure.com borra MX hacia Google. Correo rebota 550 o se queda en cola. Fix: ALIAS apex o A record a IP estable del CDN + MX intactos.
Duplicar zona en registrador y Cloudflare con CNAME solo en uno: respuestas NXDOMAIN o inconsistentes según resolver. Un solo authoritative activo.
CNAME en www pero A manual en @ con IP obsoleta: www funciona, apex no (o viceversa). Usuario reporta «a veces cae» según escriba www o no. Unifica estrategia: redirect apex→www o ambos al mismo destino.
Certificado TLS emitido solo para www mientras marketing comparte links sin www — error cert en apex. Solución: cert SAN o redirect 301 en capa CDN.
Alternativas correctas por escenario
CDN con flattening: activa CNAME/ALIAS apex en proveedor compatible; confirma MX/TXT siguen visibles en consulta dig MX @ y dig TXT @. Cloudflare muestra registros MX junto a CNAME flattening en panel pero valida externamente.
Sin flattening: usa A/AAAA records a IPs publicadas por CDN (Cloudflare publica rangos; algunos CDNs dan IP anycast fija). Actualiza A si el proveedor cambia rangos — suscríbete a avisos.
Subdominio app.tudominio.com como CNAME libre; apex mantiene MX/TXT y redirige HTTP a app. Patrón común en SaaS B2B.
Email en subdominio mail.tudominio.com con MX propio rara vez choca con web en apex CNAME flattening — pero SPF/DKIM del dominio de envío deben alinearse con From visible.
Diagnóstico paso a paso
dig CNAME tudominio.com — si responde y también existían MX, tu DNS puede estar en conflicto o usando flattening. dig MX tudominio.com — vacío tras migración web = incidente P1 correo.
dig TXT tudominio.com — confirma SPF presente. Ausencia post-migración explica spam súbito en salida.
/toolbox/dns-suite consolida A, AAAA, CNAME, MX, TXT en reporte legible para ticket a proveedor.
Tras corregir, /toolbox/dns-propagation en MX y A por separado. Correo puede propagar distinto a web si TTL differían.
Prevención en diseño de arquitectura
Documenta en runbook: «apex reservado para MX+TXT+ALIAS web; no CNAME puro». Onboarding de marketing/CDN debe pasar revisión TI antes de aplicar plantilla DNS.
Staging: subdominio preview.tudominio.com CNAME libre para pruebas; no experimentes en apex producción.
Si operas DirectAdmin + Cloudflare, define si DNS master es Cloudflare (proxy naranja) o solo DNS — registros mail suelen ser DNS only (gris) para evitar proxy SMTP.
Migraciones enterprise con zero downtime combinan TTL bajo, validación multi-resolver y ventana de guardia. DevOps-as-a-Service evita repetir el error CNAME apex en cada cambio de proveedor web.
Ponlo en práctica ahora
Usa las herramientas gratuitas del Toolbox para validar tu configuración en minutos.
¿Necesitas que lo resolvamos contigo?
Un ingeniero de Conecta puede aplicar esto en tu operación: servicio relacionado o conversación directa.