🔥 Prepárese para el Black Friday, el Cyber Monday... 20 % de descuento* con el código BF26 👉🏻 Registrarme

El subdominio marthastewart.msn.com apuntaba mediante un CNAME a msnmarthastewartsweeps.com, un dominio que llevaba 21 años sin propietario. En septiembre de 2022, alguien lo compró. Desde ese momento controlaba las respuestas DNS del subdominio, SPF incluido, y sus servidores pudieron enviar correo autenticado en nombre de marthastewart.msn.com. Guardio Labs documentó el caso el 26 de febrero de 2024 en su informe SubdoMailing.

Un registro CNAME (Canonical Name) es un alias DNS: el nombre que lo lleva remite a otro nombre, y el resolvedor toma las respuestas de este último. Sirve para conectar un subdominio con un servicio externo, por ejemplo un ESP, sin copiar sus direcciones IP. Se crea con unas pocas líneas en la zona DNS y se comprueba con dig. Si se olvida tras cancelar el servicio, se convierte en una puerta de entrada.

Qué es un registro CNAME

Un CNAME es un alias DNS: un nombre que remite a otro nombre. Lo define la RFC 1034 (sección 3.6.2), publicada en noviembre de 1987. Declara a su propietario como alias y coloca el nombre canónico en el dato del registro. En el ejemplo de la RFC (USC-ISIC.ARPA como CNAME de C.ISI.EDU), cuando un servidor de nombres no encuentra el tipo solicitado en un nombre con CNAME, devuelve el CNAME y repite la consulta sobre el destino. Solo una consulta de tipo CNAME no se repite.

En una zona DNS, el registro se escribe así: enlaces.tudominio.es. 3600 IN CNAME destino.esp-ejemplo.net. El punto final marca un nombre completo y 3600 es el TTL, es decir, 3600 segundos. La RFC 2181 (julio de 1997) fija el vocabulario: la etiqueta que lleva el CNAME es el alias y el valor es el nombre canónico.

Un destino puede ser a su vez un CNAME. La RFC 1034 pide al software que siga estas cadenas y señale los bucles como error. Cada eslabón añade una consulta.

CNAME o registro A: cuál elegir

Usa un CNAME cuando el servicio te da un nombre (CDN, SaaS, ESP) y un A o un AAAA cuando tienes una dirección IP. La RFC 2181 (sección 10.1) fija la regla de fondo: para un nombre dado, o existe un CNAME solo, o existen registros de otros tipos, o el nombre está vacío. Un CNAME excluye cualquier vecino en ese nombre.

Diferencias entre un registro A o AAAA y un registro CNAME
Criterio A / AAAA CNAME
Valor Una dirección IPv4 (A) o IPv6 (AAAA) Un nombre de dominio
El proveedor cambia de dirección IP Modificas el registro No haces nada, el nombre de destino lo sigue
Otros tipos a su lado (MX, TXT) Posibles Excluidos
Dominio raíz (apex) Sí No en DNS estándar
Consultas DNS Una Al menos una más

El CNAME cubre IPv4 e IPv6 a la vez, mientras que con registros propios hacen falta un A (IPv4) y un AAAA (IPv6): el destino publica sus propios A y AAAA y tú mantienes una sola línea. Encaja cuando un CDN o una plataforma SaaS publica un nombre en lugar de una dirección. En un dominio personalizado sobre este tipo de servicio, el CNAME no transporta ningún certificado: el servicio debe emitir un certificado TLS para tu nombre, o el navegador mostrará un error.

CNAME en el dominio raíz y en www

En el dominio raíz no se puede. El apex de una zona siempre lleva registros SOA y NS, lo que excluye el CNAME según la regla anterior. La mayoría de los dominios añaden además sus registros MX. La RFC 2181 (sección 10.3, julio de 1997) prohíbe, por cierto, que un MX o un NS apunte a un alias: el valor debe llevar direcciones directamente.

El sitio habitual de un CNAME es www. Escribes www.tudominio.es como CNAME hacia el servicio; la raíz remite a www con una redirección HTTP.

Algunos proveedores DNS esquivan el límite. La documentación de Cloudflare indica que el CNAME flattening permite un CNAME en la raíz: Cloudflare resuelve el destino, incluso a través de varios CNAME, y devuelve la dirección IP final en lugar del CNAME. La función se activa por defecto en todos los planes cuando la raíz es un CNAME.

Para qué sirve un CNAME en el envío de emails

Un CNAME publica tus claves DKIM en el proveedor, pone tu nombre en los enlaces de clic y aísla un subdominio de envío. La autenticación del dominio condiciona la entregabilidad del email. En Brevo es obligatoria desde el 1 de febrero de 2024, con los requisitos de Gmail y Yahoo. Las tres plataformas de la tabla piden CNAME bajo tu dominio, con variantes.

CNAME que piden tres plataformas de envío según su documentación
Plataforma CNAME solicitados Función
Twilio SendGrid 1 CNAME para el dominio de envío y 2 CNAME de link branding SPF y DKIM el primero; seguimiento de clics y aperturas los otros dos
Microsoft 365 2 CNAME de selector DKIM (selector1._domainkey y selector2._domainkey) Apuntar a las claves públicas DKIM
Brevo 2 CNAME DKIM o 1 registro TXT, según la cuenta Firmar los mensajes en nombre de tu dominio

En DKIM, el CNAME deja la clave pública en el proveedor: tú publicas el puntero y él conserva el control de la clave. Microsoft 365 gestiona dos pares de claves, de ahí sus dos CNAME de selector. La firma lleva entonces tu dominio en la etiqueta d=. El detalle importa para DMARC: Microsoft precisa que DKIM solo valida DMARC si el dominio firmante está alineado con el dominio de la dirección del remitente. El mecanismo se explica en el artículo sobre la firma DKIM.

Un dominio de tracking personalizado sustituye al dominio genérico del proveedor en los enlaces de clic. Con un dominio genérico, los enlaces de todos los clientes del proveedor comparten el mismo dominio. Con el tuyo, la reputación de los enlaces es tuya. Los pasos del lado del remitente están en el artículo sobre cómo personalizar los DNS de envío.

El CNAME sirve también para aislar la reputación. Microsoft aconseja un subdominio para los envíos masivos que no controlas (por ejemplo marketing.contoso.com). La elección de la dirección IP es distinta: IP compartida o dedicada. Un subdominio nuevo parte sin historial, por eso conviene calentarlo de forma gradual antes de subir el volumen. Los límites del método se discuten en el artículo sobre los subdominios de envío. El dominio de retorno de los rebotes (el Return-Path) y los envíos de confirmación (emails transaccionales) se configuran con el mismo principio.

Cómo configurar un CNAME paso a paso

Necesitas acceso a la zona DNS, alojada en tu registrador o en un proveedor especializado.

  1. En la plataforma de envío o de alojamiento, abre la página de autenticación del dominio (en Brevo: Settings > Senders, Domains, IPs > Domains > Authenticate) y copia cada pareja nombre + valor sin modificarla.
  2. Abre la zona DNS del dominio y busca el nombre que vas a crear. Comprueba que no exista ningún otro registro en él (A, AAAA, TXT, MX). Si ya hay uno, la regla de la RFC 2181 impide crear el CNAME.
  3. Añade el registro: tipo CNAME, nombre (solo el subdominio en la mayoría de las interfaces, por ejemplo enlaces o s1._domainkey) y destino (el nombre que te dan, con punto final si la interfaz lo pide).
  4. Deja el TTL por defecto en el primer intento. Bájalo a unos minutos solo si prevés modificar el registro.
  5. En Cloudflare, pon el registro en «DNS only» (nube gris). Mantén desactivada la opción que aplana todos los CNAME, o fallará el paso siguiente.
  6. Comprueba con dig o nslookup (sección siguiente) y lanza después la validación desde la interfaz del proveedor.

Si tu proveedor DNS rechaza los guiones bajos en el nombre de un CNAME, no podrás publicar los selectores DKIM («_domainkey»). Twilio señala este caso en su función de seguridad automatizada. Contacta entonces con el soporte de la plataforma o con el del proveedor DNS.

Verificar un CNAME con dig y nslookup

Ejecuta «dig enlaces.tudominio.es CNAME +short». La respuesta muestra el destino, con su punto final. Una respuesta vacía significa que tu resolvedor no ve ningún CNAME.

La cadena completa aparece con «dig enlaces.tudominio.es A». La sección ANSWER lista el CNAME y después las direcciones del destino. En Windows, nslookup se instala con TCP/IP: «nslookup -type=CNAME enlaces.tudominio.es 8.8.8.8» consulta el resolvedor público de Google y muestra una línea «canonical name = ».

Tu resolvedor local puede conservar la respuesta antigua en caché. Para consultar la fuente, obtén los servidores de nombres con «dig tudominio.es NS +short» y ejecuta «dig @ns1.ejemplo.net enlaces.tudominio.es CNAME» (sustituyendo ns1.ejemplo.net por uno de ellos). Si el servidor autoritativo responde bien, el registro está publicado.

TTL y propagación: cuánto esperar

El TTL es el tiempo, en segundos, que un resolvedor guarda una respuesta antes de revalidarla. En Cloudflare, el valor Auto de un registro con proxy equivale a 300 segundos. Una respuesta guardada en caché antes de tu cambio se sigue sirviendo hasta que expira su TTL.

En una sustitución, el plazo depende del TTL del registro anterior. Twilio indica que los cambios DNS pueden tardar hasta 48 horas: repite la comprobación pasado ese plazo. Baja el TTL la víspera de una migración.

Errores que hacen fallar un CNAME

  • Ya existe un registro TXT, A o MX en el mismo nombre: un nombre con CNAME no puede llevar nada más.
  • El dominio aparece dos veces: algunas interfaces añaden el dominio por su cuenta y enlaces.tudominio.es se convierte en enlaces.tudominio.es.tudominio.es.
  • Un CNAME con proxy o aplanado en Cloudflare: el resolvedor recibe direcciones IP en lugar del CNAME esperado y el proveedor de envío no reconoce el registro. La documentación de Cloudflare advierte de que aplanar todos los CNAME puede hacer fallar la verificación de un dominio por un servicio externo.
  • Un destino que ya no resuelve: tras el aplanamiento, Cloudflare devuelve una respuesta vacía (NODATA), que parece un fallo de propagación aunque el destino esté roto.
  • Un nombre fuera de los límites: una etiqueta admite como máximo 63 caracteres y el nombre completo 253, según la documentación de Cloudflare.
  • Una verificación que sigue fallando pasadas 48 horas: Twilio SendGrid invita entonces a contactar con su soporte, porque el plazo de propagación ya ha pasado.
  • Un MX que apunta a un nombre que a su vez es un CNAME, algo que prohíbe la RFC 2181.

CNAME huérfano y subdomain takeover

Un CNAME huérfano (dangling) apunta a un recurso que ya no existe. Microsoft describe el escenario: creas greatapp.contoso.com como CNAME de una aplicación alojada, eliminas la aplicación pero no el CNAME, y un tercero crea un recurso con un nombre idéntico. Tu subdominio sirve entonces su contenido. Microsoft menciona dos consecuencias: las cookies recuperadas en los subdominios y un certificado TLS válido obtenido para el subdominio secuestrado.

En el correo, el subdominio hereda los registros de su destino, SPF incluido, como muestra el caso de MSN. Guardio contabilizaba más de 8.000 dominios afectados en su informe de febrero de 2024, entre ellos marcas como eBay, VMware o McAfee.

Audita tu zona: para cada CNAME exportado, consulta el destino con dig y busca respuestas «NXDOMAIN» o páginas de «recurso no encontrado» del servicio. Elimina el CNAME en cuanto canceles una herramienta, antes de cerrar la cuenta.

Preguntas frecuentes

¿Puede un CNAME apuntar a una dirección IP?

No. El dato de un CNAME es un nombre de dominio. Para una dirección IP, usa un A (IPv4) o un AAAA (IPv6).

¿Se pueden poner dos CNAME en el mismo nombre?

Tampoco. La RFC 2181 (sección 10.1) prevé un único nombre canónico por alias. Si dos servicios reclaman ese alias, dale a cada uno su propio subdominio.

¿CNAME o redirección 301?

El CNAME resuelve un nombre en el DNS y deja la URL intacta. La redirección 301 es una respuesta HTTP que cambia la URL mostrada y avisa a Google de que la página se ha mudado. Para un cambio de dirección del sitio, usa la redirección.

Validar la lista antes del próximo envío

Un DNS correcto no quita de tu archivo las direcciones inexistentes: el hard bounce se produce con cualquier CNAME. CaptainVerify clasifica cada dirección en seis estados (válida, inválida, desconocida, gratuita, de riesgo, desechable) y regala 100 créditos de email al crear una cuenta. Prueba tu próxima lista antes del envío.

Añadir Captain Verify como fuente preferida en Google
Nicolas Forni
Author

Fundador de Captain Verify, trabajo en la verificación de emails y números móviles desde 2015. En este blog escribo sobre entregabilidad, higiene de las bases de contactos, reglas de los proveedores de correo y marketing por SMS. Artículos concretos, pensados para los equipos de marketing que envían cada semana.