Un registro _dmarc en CNAME: ¿trampa o práctica válida?

Las trampas: exclusividad, destino evaporado, cachés apiladas, interfaces reacias

Un CNAME no convive con nada. Las RFC del DNS son categóricas: un nombre que lleva un alias no puede llevar ningún otro registro. Es imposible, por tanto, añadir un segundo TXT en _dmarc —un token de verificación pedido por una herramienta de terceros, un registro de prueba temporal—. Las buenas interfaces rechazan la creación; las malas la aceptan y producen una zona cuyo comportamiento depende del servidor que responda. El día en que un proveedor exige «un TXT en _dmarc» para validar cualquier cosa, el alias obliga a dar el rodeo por el destino.

El destino que desaparece. Es el escenario más insidioso. Una suscripción cancelada en el colector, una zona central borrada durante una migración, una errata en el destino: _dmarc.ejemplo.es resuelve desde entonces en NXDOMAIN y la política se evapora —sin ninguna alerta, porque nada se rompe de forma visible—. El correo legítimo sigue circulando; simplemente ya no queda política que los receptores puedan aplicar, la suplantación vuelve a ser posible y las exigencias de los grandes proveedores para los remitentes de volumen dejan de cumplirse. Un matiz de DMARCbis: para un subdominio, el Tree Walk sube por la jerarquía y aterriza en la política del dominio organizativo —una red parcial—. Para el propio dominio organizativo, nada frena la caída. El síntoma visible llega a menudo semanas más tarde, cuando alguien nota que los informes han dejado de llegar.

Los TTL se apilan. Una cadena delegada mantiene vivos dos registros, es decir, dos TTL y dos cachés independientes. Un cambio de política hecho en el destino se propaga según el TTL del destino, pero el propio alias sigue en la caché de los resolutores: el plazo real se vuelve más difícil de predecir que con un TXT directo, y un TTL muy largo en cualquiera de los eslabones puede frenar un endurecimiento —o, peor aún, una marcha atrás de urgencia—.

Las interfaces reacias. El último obstáculo es prosaico: algunos gestores DNS de gran público rechazan un CNAME sobre un nombre que empieza por guion bajo, o solo validan _dmarc como TXT. La salida pasa por el editor de zona en bruto o por la API cuando existen —y cuando no existen, el montaje es sencillamente imposible en ese proveedor—.

Una política en manos de un tercero

Las trampas anteriores eran técnicas; esta es de gobernanza, y pesa más. Un alias hacia un nombre controlado por un tercero equivale a entregar a ese tercero el poder de escribir la política DMARC del dominio. Lo que el destino publica, los receptores lo aplican: un p=reject relajado a p=none sin consulta previa, una dirección rua redirigida, una etiqueta sp= modificada —todo eso se vuelve posible sin que aparezca una sola modificación en la zona del titular—. La zona del proveedor se convierte además en superficie de ataque: comprometerla es comprometer de golpe la política de todos sus clientes.

La rejilla de lectura es sencilla. Un alias hacia una zona de la misma organización (la zona central del grupo) mutualiza sin ceder soberanía: el control queda en casa, solo cambia el lugar. Un alias hacia un tercero es una decisión de delegación con todas las letras y merece el mismo trato que una externalización: cláusula contractual de reversibilidad, vigilancia independiente de lo que el destino publica realmente y un procedimiento de salida probado —porque el día de la marcha, recuperar el control se reduce a sustituir el alias por un TXT directo, siempre que se sepa qué contenido poner—.

El paralelo con DKIM: rutina en los selectores, debate en _dmarc

La ironía del debate es que el mismo montaje se practica a diario sin que nadie levante una ceja —del lado DKIM—. Conectar un enrutador de correo pasa casi siempre por CNAME de selectores: s1._domainkey.ejemplo.es apuntando a un nombre alojado en SendGrid, Mailjet, Brevo o Amazon SES, que publica la clave pública y la rota sin intervención del cliente. Esa rotación delegada es incluso un argumento de seguridad: las claves cambian más a menudo que si cada cliente tuviera que editar su propia zona.

¿Por qué la misma técnica pasa sin debate allí y levanta cejas aquí? Porque el alcance no es comparable. Un selector DKIM es material técnico, ligado a un flujo de envío, revocable individualmente y uno entre varios: su compromiso o su desaparición degrada un flujo, no el dominio. El registro _dmarc, en cambio, es único y gobierna el tratamiento de todo el correo del dominio —y, vía sp y el Tree Walk, el de sus subdominios—. Delegar un selector es entregar la llave de un piso; delegar _dmarc es entregar la llave maestra del edificio. Misma técnica, distinto peso —de ahí exigencias de confianza distintas—.

Cuándo es preferible el TXT directo

La conclusión práctica se dibuja sola. El TXT directo sigue siendo la opción por defecto en la mayoría de las situaciones: uno o dos dominios que gestionar, una política estable que cambia tres veces en la vida de un dominio, un equipo que quiere leer la configuración en su propia zona sin seguir una cadena. El alias no aportaría allí ningún ahorro real y añadiría una pieza móvil más.

El CNAME se gana su sitio en dos casos asumidos: la flota numerosa pilotada desde una zona central de la misma organización —la ganancia operativa es masiva y la soberanía queda intacta— y la delegación consciente a un proveedor, documentada como tal, con vigilancia y puerta de salida. Entre ambos, la regla cabe en una frase: el alias es una herramienta de escala y de delegación, no un ajuste por defecto; a pequeña escala y sin nada que delegar, solo tiene inconvenientes.

Verificar una cadena delegada con dig

La verificación cabe en dos comandos. El primero sigue la cadena como lo haría un receptor:

$ dig +short _dmarc.ejemplo.es TXT
dmarc.grupo-ejemplo.es.
"v=DMARC1; p=reject; rua=mailto:informes@grupo-ejemplo.es"

La primera línea muestra el alias; la segunda, el TXT leído al final: ese valor es el que aplicarán los receptores. El segundo comando aísla cada eslabón: dig +short _dmarc.ejemplo.es CNAME confirma el destino exacto, y dig +short dmarc.grupo-ejemplo.es TXT consulta el destino en directo. Los puntos de control: una cadena de un solo salto, un destino que responde con exactamente un TXT que empieza por v=DMARC1, ningún registro parásito en el mismo nombre y TTL razonables en ambos lados. Un NXDOMAIN en cualquier eslabón significa política evaporada —un caso de corrección inmediata, no de investigación tranquila—. Y como la cadena puede romperse del lado del destino sin que nada haya cambiado en la zona del propio dominio, una verificación periódica automatizada vale más que un control puntual en el momento del despliegue.

En resumen

Un _dmarc en CNAME no es ni una herejía ni un ajuste anodino. El DNS lo permite plenamente: el alias delega el nombre entero, la resolución sigue la cadena y el TXT leído al final es el que cuenta para todos los receptores. Dos usos lo justifican —la delegación a un colector de informes y la gestión de una flota desde una zona central—. Enfrente, cuatro trampas documentadas: la exclusividad del CNAME, que prohíbe cualquier otro registro en el mismo nombre; el destino que puede desaparecer llevándose la política sin alerta; los TTL que se apilan; y las interfaces DNS que rechazan el montaje. El factor decisivo sigue siendo la gobernanza: un alias hacia la propia zona central mutualiza sin ceder nada; un alias hacia un tercero delega el poder de escribir la política y se trata como una externalización. A pequeña escala, el TXT directo conserva todas sus ventajas.

Para zanjar la duda sobre un dominio concreto, el análisis DMARC gratuito sigue las cadenas CNAME exactamente como lo haría un servidor receptor y muestra la política realmente leída al final —alias incluido, eslabón a eslabón—. Y cuando toda una flota descansa sobre este montaje, abrir una cuenta mantiene cada eslabón bajo vigilancia continua: un destino que se evapora se detecta entonces en cuestión de horas, no cuando el primer mensaje falsificado lleva el nombre del dominio.