Los errores de sintaxis DMARC más comunes (y sus correcciones)

_dmarc.ejemplo.es.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.es"

rua= sin mailto:: informes que nunca salen

La dirección de recogida de los informes agregados no es una dirección de correo desnuda: es una URI. rua=dmarc@ejemplo.es parece diáfana, pero ningún generador de informes la aceptará — la forma correcta es rua=mailto:dmarc@ejemplo.es. El olvido del prefijo mailto: es probablemente el error más extendido de todo este anecdotario, y su síntoma no admite réplica: un registro por lo demás correcto, una política aplicada y cero informes recibidos, indefinidamente.

La regla vale para cada destino. Varias direcciones se separan con comas, y cada una lleva su propio prefijo: rua=mailto:dmarc@ejemplo.es,mailto:archivo@ejemplo.es es correcto; rua=mailto:dmarc@ejemplo.es,archivo@ejemplo.es solo lo es a medias, pues la segunda dirección queda ignorada. La misma exigencia se aplica a ruf, la dirección de los informes de fallo, allí donde se usa.

Puntos y comas, comillas y caracteres invisibles

El punto y coma es el separador de etiquetas, y su ausencia fusiona dos etiquetas en un único valor ilegible. v=DMARC1; p=none rua=mailto:dmarc@ejemplo.es convierte «none rua=mailto:…» en el valor de p: política inválida, con repliegue silencioso hacia p=none en el mejor de los casos. A la inversa, los puntos y comas sobrantes (;;, ; ;) son tolerados por algunos analizadores y rechazados por otros: mejor atenerse a la forma canónica — un punto y coma entre cada par, un eventual punto y coma final sin consecuencias.

Las comillas son una trampa de interfaz. En un archivo de zona, el valor TXT se escribe entre comillas; en la interfaz web de un proveedor de DNS, casi siempre sobran, porque la propia interfaz las añade. Pegar "v=DMARC1; p=none" con comillas incluidas en un campo que no las espera produce un registro cuyo primer carácter es una comilla literal: la etiqueta v ya no abre el valor, y el registro entero queda descartado. El síntoma se aprecia en la consulta DNS: comillas duplicadas o escapadas alrededor del valor publicado.

Los caracteres invisibles, por último, son el enemigo del copiar y pegar. Un registro redactado en un procesador de textos o recuperado de un PDF arrastra con gusto un espacio de no separación en lugar de un espacio simple, comillas tipográficas, una raya larga en vez del guion. A simple vista, nada distingue estos caracteres de sus equivalentes ASCII; para el analizador de un receptor, la etiqueta sencillamente deja de existir. La contramedida es simple: volver a teclear el valor en un editor de texto plano en lugar de pegarlo desde un documento con formato.

La ubicación equivocada y el registro duplicado

Un registro perfecto en el lugar equivocado no vale nada. Publicado en el dominio desnudo — ejemplo.es en lugar de _dmarc.ejemplo.es —, jamás será consultado: los receptores solo interrogan el subdominio _dmarc. El error inverso también existe: algunas interfaces DNS añaden automáticamente el nombre de la zona, y teclear _dmarc.ejemplo.es en el campo «nombre» produce _dmarc.ejemplo.es.ejemplo.es. Según el proveedor, el campo espera _dmarc a secas o el nombre completo; una comprobación de lo realmente publicado zanja la duda en segundos.

El registro duplicado es más insidioso. Cuando dos TXT que empiezan por v=DMARC1 coexisten en _dmarc.ejemplo.es — uno antiguo nunca borrado, otro nuevo puesto por otra herramienta u otro equipo —, el estándar no deja lugar a dudas: los receptores no eligen ninguno. Dos políticas equivalen a cero políticas, y el dominio regresa al estado desprotegido. La misma trampa existe en el lado SPF, donde la duplicación produce un error permanente; el mecanismo y su corrección se detallan en el caso de los registros SPF múltiples.

Caso particular: cuando _dmarc está delegado por CNAME hacia un registro gestionado en otro lugar — práctica corriente con las plataformas de supervisión —, poner un TXT local al lado es imposible o conflictivo, y las modificaciones locales quedan sin efecto. El funcionamiento y los límites de esa delegación se explican en el registro DMARC en CNAME.

Los falsos errores: las mayúsculas y las etiquetas de DMARCbis

No todo lo que hiere la vista es un error. Las mayúsculas, primero: la comparación de las etiquetas y de sus valores es insensible a la caja. p=REJECT vale exactamente lo mismo que p=reject, y P=Quarantine se interpreta sin dificultad. Es un error de diagnóstico muy común: ante un problema de entregabilidad, la atención se fija en unas mayúsculas «sospechosas», la «corrección» no cambia rigurosamente nada — y el error verdadero, un mailto: ausente tres etiquetas más allá, sobrevive a la revisión. La forma en minúsculas (con DMARC1 en mayúsculas) sigue recomendada por legibilidad, pero pertenece a la convención, no a la validez.

Las etiquetas modernas, después. El estándar vigente — DMARCbis, publicado como RFC 9989 a 9991 — introdujo np (la política de los subdominios inexistentes), t (el modo de prueba, que sustituye al antiguo pct) y psd (un marcador ligado al DNS Tree Walk, sucesor de la Public Suffix List). Un registro que contiene np=reject o t=y es perfectamente válido; sin embargo, validadores en línea envejecidos, nunca actualizados, lo señalan como «etiqueta desconocida». Es un falso positivo: la sintaxis DMARC es extensible por diseño, y una etiqueta desconocida se ignora, nunca resulta fatal. A la inversa, un pct=50 heredado de un despliegue antiguo no invalida nada, pero los receptores modernos ya no lo interpretan: el modo de prueba se expresa hoy con t=y.

El reporting externo: cuando rua apunta a otro dominio

Un último caso, en la frontera de la sintaxis: el registro es impecable, la política se aplica, y los informes siguen sin llegar. Cuando la dirección rua pertenece a un dominio distinto del que publica el registro — ejemplo.es enviando sus informes a dmarc@ejemplo.org —, los generadores de informes exigen una prueba de consentimiento del destinatario. El dominio que recibe debe publicar un registro de autorización en la ubicación ejemplo.es._report._dmarc.ejemplo.org, con el simple valor v=DMARC1. Sin esa autorización, la mayoría de los generadores se abstienen de enviar — silenciosamente, como siempre.

Las plataformas de recogida serias publican esta autorización de oficio, a menudo en forma genérica válida para todos sus clientes; el problema apenas se encuentra fuera de una recogida artesanal entre dominios de una misma organización. La puesta en marcha completa de una dirección de recogida — autorización incluida — se desarrolla paso a paso en la configuración de la dirección rua.

El método: corregir y demostrar la corrección

Toda corrección empieza por una lectura del estado real, no del supuesto. El comando dig TXT _dmarc.ejemplo.es +short (o su equivalente nslookup -type=TXT) muestra lo que los receptores ven efectivamente — que puede diferir de lo que la interfaz del proveedor exhibe, por culpa de una caché, de una zona secundaria desincronizada o de una delegación olvidada.

Sobre esa salida, la revisión sigue una lista corta: un solo registro que empiece por v=DMARC1; v en primerísima posición; una p presente, con uno de los tres valores admitidos; un mailto: delante de cada dirección de rua y de ruf; un punto y coma entre cada par; ninguna comilla literal al principio del valor; ningún carácter exótico — la duda se despeja tecleando de nuevo el valor a mano en un editor plano.

Publicada la corrección, toca paciencia: el TTL del registro antiguo puede mantener la versión defectuosa en caché durante horas. Una nueva consulta desde varios resolutores confirma la propagación. La prueba final no es sintáctica sino operativa: unos informes agregados que llegan en 24 a 48 horas atestiguan que la cadena completa — ubicación, sintaxis, política, recogida — funciona de extremo a extremo.

En resumen

Un registro DMARC válido es un TXT único puesto en _dmarc.<dominio>, abierto por v=DMARC1, portador de una p correctamente escrita y de una rua en URI mailto:. Los errores que cuentan se cuentan con los dedos de dos manos: etiqueta de versión desplazada, política ausente o defectuosa que se repliega en silencio hacia p=none, mailto: olvidado, punto y coma perdido, comillas pegadas dentro del valor, registro puesto en el lugar equivocado, duplicado que lo anula todo, carácter invisible colado por un copiar y pegar. Enfrente, dos falsos errores que ya no merecen «corrección»: las mayúsculas, que los receptores ignoran, y las etiquetas de DMARCbis (np, t, psd) que solo los validadores envejecidos toman por faltas. Y un ángulo muerto: la autorización del reporting externo, sin la cual unos informes perfectamente configurados no salen jamás.

El camino más corto de la duda a la certeza sigue siendo el utillaje: un pase del dominio por el análisis DMARC gratuito detecta en segundos los errores de este anecdotario — etiqueta desplazada, mailto: ausente, registro duplicado — sin inventar falsos sobre las mayúsculas o las etiquetas modernas. Saneado el registro, la apertura de una cuenta permite seguir el regreso de los informes y hacer subir la política hacia p=reject sobre cimientos por fin sólidos.