RFC 9989, 9990, 9991: lo que cambia de verdad en DMARC

RFC 9990 — los informes agregados (RUA)

Los informes agregados son los resúmenes diarios que los destinatarios envían a la dirección rua=. La RFC 9990 les dedica ahora un documento entero: formato XML, contenido, frecuencia y buenas prácticas de envío. El contenido sigue siendo familiar —recuentos por fuente de envío, con los resultados de alineación SPF/DKIM—, pero dos detalles evolucionan en el bloque policy_published de los informes: la etiqueta pct ya no figura en él, y la etiqueta np puede aparecer. El aprendizaje de su lectura está en cómo leer los informes agregados.

RFC 9991 — los informes de fallo (RUF)

Los informes de fallo (también llamados forenses) son el otro canal, mucho más raro. Pueden contener muestras, de ahí unas fuertes restricciones de privacidad, que hacen que muchos destinatarios sencillamente no los envíen. La RFC 9991 encuadra este canal por separado, precisamente para que sus asuntos de confidencialidad no contaminen el resto del protocolo. Para la diferencia práctica entre los dos tipos, véase cómo leer los informes agregados.

Las etiquetas: lo que se añade, se retira y se conserva

Esta es la tabla que suele motivar la visita a esta página.

Etiquetas añadidas:

• np — política de los subdominios inexistentes (cf. la etiqueta np).
• psd — marcador de dominio de sufijo público (para los registros).
• t — modo de prueba binario (t=y), que reemplaza al despliegue por porcentaje.

Etiquetas retiradas:

• pct — el despliegue «sobre un porcentaje del correo», considerado poco fiable, se suprime en favor de t (cf. el fin de pct).
• ri y rf — el intervalo y el formato de los informes migran a los documentos de reporte (9990/9991), ya no están en el núcleo del protocolo.

Etiquetas sin cambios:

• v (siempre v=DMARC1), p, sp, adkim, aspf, fo, rua, ruf — mismo sentido que en la 7489.

Lo que implica para el registro

La buena noticia, una vez más: nada urgente. Un registro actual sigue siendo perfectamente válido, y siempre empieza por v=DMARC1. Los únicos retoques útiles:

• retirar pct si todavía figura (ya no lo interpretan las implementaciones actualizadas);
• añadir np=reject para cubrir los subdominios fantasma;
• no preocuparse por ri/rf: su desaparición del núcleo es transparente del lado del emisor.

La hoja de ruta detallada, paso a paso, está en ¿hay que migrar?.

Por qué importa el paso a «Proposed Standard»

Más allá de lo técnico, el cambio de estatus tiene un alcance concreto. Un Proposed Standard es un punto de apoyo mucho más sólido para los auditores y los reguladores: citar «DMARC según la RFC 9989» tiene más peso que citar un documento Informational. Para las organizaciones sometidas a marcos como NIS2 o DORA, donde la autenticación del correo es un control esperado, es un argumento de cumplimiento más. De ello hablamos en los bancos.

¿Y la interoperabilidad durante la transición?

Una pregunta que vuelve a menudo: «si se adoptan las nuevas etiquetas, ¿se romperán los destinatarios antiguos?» No. DMARCbis está diseñado para la retrocompatibilidad: un destinatario que aún no conoce np o t simplemente ignora lo que no entiende, y sigue aplicando p, sp y la alineación como antes. Las nuevas etiquetas pueden, por tanto, publicarse desde ahora sin esperar a que todo el ecosistema esté actualizado: no hay ningún inconveniente en ir por delante, y un beneficio real en cerrar la brecha de los subdominios inexistentes.

Un registro antes / después

Nada como un ejemplo concreto para ver lo que cambian las RFC. He aquí un registro típico tal como se escribía bajo la RFC 7489:

v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s; rua=mailto:informes@ejemplo.es

Y el mismo, modernizado para DMARCbis:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:informes@ejemplo.es

Solo dos diferencias: pct=100 ha desaparecido (la etiqueta se retira, y pct=100 no servía para nada de todos modos), y np=reject ha aparecido para cubrir los subdominios inexistentes. Todo lo demás —v=DMARC1, p, sp, la alineación estricta, el rua— es idéntico. Por eso precisamente se habla de revisión y no de reescritura: el 90 % del registro no se mueve.

Quién está afectado por cada RFC

Los tres documentos no se dirigen al mismo público, y saber cuál concierne a quién evita leer 80 páginas para nada:

• Publicar DMARC para un dominio. Solo la RFC 9989 concierne de verdad, y aun así: solo la parte sobre las etiquetas. Ahí nunca se escribe código de informes, se consume.
• Recibir y analizar informes (directamente o a través de un proveedor). La RFC 9990 describe lo que llega y cómo interpretarlo.
• Desarrollar una solución DMARC u operar un servicio de mensajería. Las tres RFC conciernen, además de las secciones sobre el Tree Walk y la interoperabilidad.

Para la gran mayoría de las organizaciones, el trabajo real cabe en dos líneas de DNS (ver el ejemplo de arriba). Las RFC son la referencia; no hace falta leerlas para estar conforme, solo publicar el registro correcto.

Una cuestión de vocabulario: ¿existe de verdad «DMARC V2»?

«DMARC V2» o «DMARC 2.0» circulan por todas partes. Son apodos cómodos, no términos oficiales: el IETF habla de «DMARCbis» (el sufijo -bis significa «la versión revisada»). Y sobre todo, no existe ningún v=DMARC2 en la sintaxis: el identificador sigue siendo v=DMARC1. Así que cuando una herramienta o un artículo asegura que hay que «pasar a DMARC2» en el registro, conviene desconfiar: es falso, y delata una mala comprensión del estándar.

Cómo comprobar que está «al día»

No hace falta leer las tres RFC para saber si un registro es moderno. Bastan tres comprobaciones:

• v=DMARC1 al principio — siempre presente (si no, no es un registro DMARC válido).
• Nada de pct — si queda alguno, hay que retirarlo; lo ignoran las implementaciones recientes.
• np presente — sin esta etiqueta, los subdominios inexistentes no están cubiertos.

Un analizador hace estas verificaciones en unos segundos: basta pasar el dominio por nuestro analizador DMARC gratuito, que señala las etiquetas obsoletas y las carencias. La postura de un dominio también puede situarse respecto a todo un sector en el Observatorio DMARC, donde se ve, con cifras en la mano, cuántos dominios ni siquiera han alcanzado p=reject.

Las RFC en sí son públicas y gratuitas en el sitio del IETF, para quien quiera la fuente de verdad. Pero para la práctica totalidad de los casos, el registro cuenta más que el texto: es lo que ven los destinatarios, y es él quien protege —o no— el dominio. Leer 80 páginas de RFC no cambia nada mientras el registro publicado no esté al día.

En resumen

DMARCbis no es un solo documento sino tres RFC: 9989 (el protocolo y sus etiquetas), 9990 (los informes agregados) y 9991 (los informes de fallo), que juntas reemplazan a la RFC 7489. En la práctica, lo esencial cabe en dos gestos —añadir np, retirar pct— sobre un registro que siempre empieza por v=DMARC1. El paso a Proposed Standard refuerza sobre todo el valor de DMARC como control auditable.

Thomas traduce las RFC a DNS

Leer tres RFC para sacar de ellas dos líneas de DNS no es la mejor asignación del tiempo de nadie. Thomas, el CISO virtual, conoce DMARCbis: genera el registro exacto a publicar —etiquetas np y t incluidas— a partir del estado real del dominio, nombra cada fuente de envío desde los informes, y guía hasta p=reject.

Análisis gratuito del dominio o crear una cuenta para empezar. ¿Primer contacto con el tema? El punto de partida es este nuevo estándar explicado de forma sencilla.