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 te envían a tu 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. Si quieres aprender a leer estos informes, mira 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, mira cómo leer los informes agregados.

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

Esta es la tabla que probablemente buscabas al llegar aquí.

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 tu registro

La buena noticia, una vez más: nada urgente. Tu 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 tus subdominios fantasma;
• no preocuparte 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 adopto 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. Puedes, por tanto, publicar las nuevas etiquetas 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. Aquí tienes 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:rapports@ton-domaine.fr

Y el mismo, modernizado para DMARCbis:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@ton-domaine.fr

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 % de tu 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 te concierne te evita leer 80 páginas para nada:

• ¿Publicas DMARC para tu dominio? Solo la RFC 9989 te concierne de verdad, y aun así: solo la parte sobre las etiquetas. Nunca escribes código de informes, lo consumes.
• ¿Recibes y analizas informes (o lo hace tu proveedor)? La RFC 9990 describe lo que recibes y cómo interpretarlo.
• ¿Desarrollas una solución DMARC u operas un servicio de mensajería? Las tres RFC te 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 tienes que leerlas para estar conforme, solo publicar el registro correcto.

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

Verás «DMARC V2» o «DMARC 2.0» 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 si una herramienta o un artículo te dice que hay que «pasar a DMARC2» en tu registro, desconfía: es falso, y delata una mala comprensión del estándar.

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

No necesitas leer las tres RFC para saber si tu 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, retíralo; lo ignoran las implementaciones recientes.
• np presente — sin esta etiqueta, tus subdominios inexistentes no están cubiertos.

Un analizador hace estas verificaciones en unos segundos: pasa tu dominio por nuestro analizador DMARC gratuito, que señala las etiquetas obsoletas y las carencias. También puedes situar tu postura 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, si quieres 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— tu 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. Para ti, 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.

Deja que Thomas traduzca las RFC a DNS

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

Analiza tu dominio gratis → o crea una cuenta para empezar. ¿Nuevo en el tema? Empieza por este nuevo estándar explicado de forma sencilla.