Después de años de trabajo dentro del grupo de trabajo DMARC de la IETF, se ha publicado la esperada actualización del estándar DMARC. Tres nuevos documentos, RFC 9989, RFC 9990 y RFC 9991, ahora reemplazan formalmente el RFC 7489 original de 2015. En conjunto, se conocen comúnmente como DMARCbis.

Las nuevas especificaciones fueron publicadas en mayo de 2026 y movieron DMARC de su estado anterior Informativo a un Estándar Propuesto en la Pista de Estándares de IETF. Esto le da a DMARC un lugar más sólido y formal en la pila de estándares de Internet.

I. Qué Cubre Cada RFC

Tabla comparativa de las funcionalidades de DMARC RFC 7489 frente a las nuevas especificaciones DMARCbis en términos de estructura, estado, método de descubrimiento, pruebas y políticas.

La especificación DMARC se ha dividido en tres documentos enfocados en lugar de un archivo grande:

  • RFC 9989: Define el protocolo DMARC principal, incluyendo la evaluación de políticas, alineación de identificadores, procesamiento de registros y procedimientos de DNS Tree Walk.
  • RFC 9990: Define el reporte agregado de DMARC, también conocido como reporte RUA.
  • RFC 9991: Define el reporte de fallos de DMARC, a veces llamado reporte forense, que puede proporcionar detalles a nivel de mensaje sobre fallos de autenticación cuando los sistemas receptores lo soportan.

Esta división hace que el estándar sea más fácil de implementar, mantener y referenciar.

II. Tu Registro DMARC Existente Aún Funciona

Tarjeta de estadísticas que muestra una compatibilidad retroactiva del 100 % para los registros DMARC existentes con la etiqueta v=DMARC1, sin necesidad de reconstrucción.

Este no es un cambio disruptivo para los propietarios de dominios.

Los registros DMARC todavía comienzan con:

v=DMARC1

No necesitas reconstruir tu implementación de DMARC ni republicar todos los registros inmediatamente. Los registros existentes siguen siendo válidos, pero la actualización es una buena razón para revisar tu configuración, eliminar comportamientos obsoletos y confirmar que tu plataforma de monitoreo soporta las nuevas especificaciones.

III. Cambios Técnicos Clave

Tabla comparativa de las nuevas etiquetas DMARC np, psd y t frente a las etiquetas históricas obsoletas pct, rf y ri, junto con sus respectivos propósitos.

Varios cambios son importantes para equipos de seguridad, administradores de DNS y plataformas de autenticación de correo electrónico.

DNS Tree Walk Reemplaza la Dependencia de la Lista de Sufijos Públicos

DMARCbis reemplaza la dependencia de la Lista de Sufijos Públicos mantenida externamente para el descubrimiento de dominios organizacionales con procedimientos de DNS Tree Walk.

Los receptores ahora pueden recorrer la jerarquía DNS hacia arriba y buscar registros _dmarc relevantes en cada nivel. Esto reduce la dependencia de una lista de terceros y mejora el manejo de estructuras de dominio complejas, dominios delegados y operadores de dominios de sufijo público.

Nuevas Etiquetas: np, psd y t

RFC 9989 actualiza el registro de etiquetas DMARC e introduce soporte activo para:

  • np: política para subdominios inexistentes.
  • psd: manejo de dominios de sufijo público.
  • t: bandera de prueba, con t=y para pruebas y t=n para operación normal.

La etiqueta np es especialmente importante para organizaciones con huellas de dominio grandes o complejas porque ayuda a abordar intentos de suplantación contra subdominios inexistentes.

Etiquetas Históricas: pct, rf y ri

RFC 9989 marca varias etiquetas antiguas como históricas:

  • pct
  • rf
  • ri

La etiqueta pct originalmente estaba destinada a soportar el despliegue parcial de políticas, pero la implementación fue inconsistente entre receptores. DMARCbis reemplaza este enfoque con un comportamiento de prueba más claro a través de la etiqueta t.

Las organizaciones deberían revisar los registros DMARC existentes en busca de etiquetas históricas y planificar la limpieza cuando sea apropiado.

Orientación Más Clara para Reenvío y Listas de Correo

Los flujos de correo indirectos, como el reenvío y las listas de correo, siguen siendo difíciles para DMARC porque la alineación de SPF o DKIM puede fallar incluso cuando el mensaje es legítimo.

DMARCbis proporciona orientación más explícita sobre estos escenarios del mundo real. Esto importa porque muchos fallos de producción no son causados por correo malicioso, sino por correo legítimo que pasa a través de sistemas que alteran el enrutamiento, encabezados o contexto de autenticación.

Conformidad Mejor Definida

Las especificaciones actualizadas proporcionan definiciones más claras para la participación e implementación de DMARC.

Esto debería ayudar a reducir la interpretación inconsistente entre remitentes, receptores y proveedores. Para las organizaciones, también facilita preguntar si una herramienta o proveedor está realmente alineado con el estándar DMARC actual.

IV. RFC 9989: Protocolo DMARC Principal

RFC 9989 reemplaza a RFC 7489 como la especificación DMARC principal.

Define el protocolo principal, incluyendo:

  • Descubrimiento de políticas DMARC.
  • Procesamiento de registros.
  • Alineación de identificadores.
  • Evaluación de políticas.
  • Comportamiento de DNS Tree Walk.
  • Manejo actualizado de etiquetas.
  • Expectativas de conformidad.

Descubrimiento y Herencia de Políticas

RFC 9989 aclara cómo funciona el descubrimiento de políticas DMARC a través de jerarquías de dominio.

Esto importa para organizaciones con muchos subdominios, dominios delegados o dominios regionales. Sin un descubrimiento claro de políticas, los equipos pueden creer que un dominio está protegido cuando un receptor no descubre o aplica la política esperada.

Alineación de Identificadores

DMARC todavía depende de la alineación de identificadores.

Un mensaje pasa DMARC solo cuando al menos una de las siguientes condiciones es verdadera:

  • SPF pasa y el dominio autenticado por SPF se alinea con el dominio From visible.
  • DKIM pasa y el dominio de firma DKIM se alinea con el dominio From visible.

Pasar SPF solo no significa que DMARC pase. Pasar DKIM solo no significa que DMARC pase. La alineación es lo que vincula la autenticación con el dominio que ve el destinatario.

DNS Tree Walk

DNS Tree Walk es uno de los cambios operacionales más importantes en RFC 9989.

En lugar de depender de la Lista de Sufijos Públicos para determinar el dominio organizacional, los receptores usan búsquedas DNS a través de la jerarquía de dominio para descubrir la política DMARC aplicable.

Esto mejora la capacidad del estándar para manejar modelos de delegación complejos y escenarios de dominios de sufijo público.

V. RFC 9990: Reportes Agregados

RFC 9990 define el formato de reportes agregados de DMARC.

Los reportes agregados dan a los propietarios de dominios visibilidad sobre cómo se está usando su dominio en todo el ecosistema de correo electrónico. Estos reportes típicamente incluyen:

  • Direcciones IP de origen.
  • Resultados de autenticación.
  • Resultados de alineación.
  • Disposición de política.
  • Volumen de envío.
  • Organización que reporta.

El RFC dedicado a reportes agregados debería mejorar la consistencia entre implementaciones y facilitar la interpretación del comportamiento de reportes para proveedores y propietarios de dominios.

Para los equipos de seguridad, los reportes agregados siguen siendo una de las formas más útiles de descubrir remitentes legítimos, identificar fuentes no autorizadas y monitorear el progreso de la aplicación de DMARC.

VI. RFC 9991: Reportes de Fallos

RFC 9991 define los reportes de fallos de DMARC como una especificación dedicada de Pista de Estándares.

Los reportes de fallos pueden proporcionar detalles a nivel de mensaje sobre fallos de autenticación, dependiendo de la implementación del receptor y los controles de privacidad.

Estos reportes pueden ser útiles para solución de problemas e investigación de amenazas, pero deben manejarse con cuidado. Los reportes de fallos pueden contener metadatos sensibles y, dependiendo de la implementación, pueden incluir encabezados de mensaje o elementos de contenido. Las organizaciones deben considerar privacidad, volumen, retención y controles de acceso antes de habilitar o depender de reportes de fallos.

No todos los receptores envían reportes de fallos. Los equipos de seguridad deberían tratarlos como una señal complementaria, no como una fuente completa de monitoreo.

VII. Qué Deben Hacer los Propietarios de Dominios

Los propietarios de dominios no necesitan editar registros DNS con pánico, pero deberían revisar su postura DMARC contra las especificaciones actualizadas.

Una revisión práctica debería incluir:

  • Confirmar que todos los registros DMARC todavía usan v=DMARC1.
  • Identificar y planificar la limpieza de etiquetas históricas como pct, rf y ri.
  • Revisar si la etiqueta np es relevante para la protección de subdominios inexistentes.
  • Confirmar cómo están protegidos los subdominios.
  • Verificar si los remitentes de terceros están correctamente alineados.
  • Revisar la visibilidad de reportes agregados.
  • Confirmar que tu plataforma DMARC soporta RFC 9989, RFC 9990 y RFC 9991.
  • Preguntar a los proveedores cómo manejan el descubrimiento de políticas DNS Tree Walk.
  • Revisar si los reportes de fallos son útiles, apropiados y seguros en términos de privacidad para tu organización.

El objetivo no es la migración urgente. El objetivo es la alineación controlada con el estándar DMARC actual.

VIII. Qué Necesitan Soportar las Plataformas DMARC

La preparación para DMARCbis no es solo un problema de propietarios de dominios. Las plataformas que gestionan o monitorean DMARC también deben adaptarse.

Una plataforma lista para DMARCbis debería soportar:

  • Comportamiento del protocolo principal RFC 9989.
  • Descubrimiento de políticas basado en DNS Tree Walk.
  • Análisis e interpretación de np, psd y t.
  • Reconocimiento de etiquetas históricas como pct, rf y ri.
  • Ingesta y análisis de reportes agregados RFC 9990.
  • Manejo de reportes de fallos RFC 9991 cuando estén habilitados.
  • Distinción clara entre autenticación y alineación.
  • Visibilidad a través de subdominios y dominios delegados.
  • Comportamiento de conformidad actualizado a medida que evolucionan las implementaciones de receptores.

Si una plataforma no puede interpretar las etiquetas actualizadas o el comportamiento de reportes, los equipos de seguridad pueden perder visibilidad sobre cambios importantes de autenticación.

IX. Cómo Ayuda Skysnag Protect

Skysnag Protect ayuda a las organizaciones a prepararse para DMARCbis soportando análisis actualizado de registros, visibilidad de reportes y monitoreo de políticas a medida que evolucionan las implementaciones de receptores.

La plataforma está diseñada para ayudar a las organizaciones a:

  • Monitorear la postura de aplicación de DMARC.
  • Rastrear la alineación de SPF y DKIM.
  • Identificar fuentes de envío legítimas y no autorizadas.
  • Mantener visibilidad a través de dominios y subdominios.
  • Interpretar el comportamiento de reportes agregados.
  • Soportar manejo actualizado de etiquetas DMARC.
  • Prepararse para el descubrimiento de políticas basado en DNS Tree Walk.
  • Reducir la complejidad manual en la gestión continua de DMARC.

A medida que la industria adopta RFC 9989, RFC 9990 y RFC 9991, las organizaciones necesitan herramientas que se mantengan al ritmo del estándar sin forzar interrupciones operacionales innecesarias.

X. Consideraciones de Migración y Conformidad

DMARCbis no es un protocolo nuevo. Es una versión más clara, de pista de estándares de DMARC basada en más de una década de experiencia operacional.

Las organizaciones deberían tratar la actualización como un punto de revisión estructurado:

Revisar Registros

Verificar etiquetas históricas, políticas de subdominios inconsistentes, direcciones de reportes faltantes y suposiciones obsoletas sobre el despliegue de políticas.

Revisar Remitentes

Confirmar que cada remitente legítimo puede pasar SPF alineado o DKIM alineado. Esto es especialmente importante para plataformas de marketing, CRMs, sistemas de tickets, herramientas de helpdesk y otros servicios de terceros.

Revisar Reportes

Asegurarse de que los reportes agregados se estén procesando correctamente y que cualquier reporte de fallos se maneje con controles adecuados de privacidad y acceso.

Revisar Proveedores

Preguntar a los proveedores de seguridad de correo electrónico si soportan RFC 9989, RFC 9990 y RFC 9991, incluyendo el descubrimiento de políticas DNS Tree Walk y la interpretación actualizada de etiquetas.

XI. Palabras Finales

DMARCbis es el mismo DMARC, pero más claro, más formal y mejor alineado con cómo se comporta realmente el correo electrónico.

La publicación de RFC 9989, RFC 9990 y RFC 9991 es un buen incentivo para que los propietarios de dominios revisen sus registros, validen la alineación de remitentes, verifiquen la cobertura de subdominios y confirmen que sus herramientas están listas para el estándar actual.

Para las organizaciones responsables de la protección de marca, prevención de phishing y confianza en el correo electrónico, el cambio no es disruptivo. Es una oportunidad para mejorar la calidad de implementación.

XII. Conclusiones Clave

  • RFC 9989 reemplaza a RFC 7489 como la especificación central del protocolo DMARC.
  • RFC 9990 define los informes agregados de DMARC.
  • RFC 9991 define los informes de fallos de DMARC.
  • Los registros DMARC existentes todavía utilizan v=DMARC1.
  • DNS Tree Walk reemplaza la dependencia de la Lista de Sufijos Públicos para el descubrimiento de políticas.
  • RFC 9989 introduce soporte activo para np, psd y t.
  • pct, rf y ri ahora son etiquetas históricas.
  • DMARCbis mejora la claridad y consistencia de implementación en lugar de cambiar el propósito básico de DMARC.
  • Las organizaciones deben revisar registros, subdominios, remitentes, informes y preparación de proveedores.

¿Listo para alinear tu programa de autenticación de correo electrónico con DMARCbis? Explora Skysnag Protect.