Descripción general de DMARCbis

Bienvenido a la sección de documentación de DMARCbis. Aquí encontrarás una descripción general de DMARCbis, la actualización más significativa del estándar DMARC desde que se publicó por primera vez.

¿Qué es DMARCbis?

DMARCbis es una revisión de DMARC (Autenticación de Mensajes Basada en Dominio, Informes y Conformidad). La designación "bis" sigue las convenciones de nomenclatura estándar para revisiones de protocolos.

La especificación original de DMARC (RFC 7489) se publicó en 2015 como un documento "Informativo", mientras que DMARCbis se ha publicado como un "Estándar Propuesto". Esto eleva el estatus formal de DMARC al de un protocolo de autenticación de correo electrónico probado y ampliamente adoptado, basándose en más de una década de experiencia de implementación.

DMARCbis refuerza el estándar original de las siguientes maneras:

• Dividiendo la especificación en borradores más claros y detallados con ejemplos adicionales
• Mejorando la forma en que se determinan los límites de dominio organizacional, utilizando búsquedas nativas de DNS en lugar de una lista mantenida manualmente
• Simplificando las etiquetas de política mediante la eliminación de elementos heredados inconsistentes
• Aumentando los requisitos de reporting para una mejor visibilidad y seguridad

Fundamentalmente, DMARCbis mantiene la compatibilidad con versiones anteriores. Continúa utilizando v=DMARC1 como identificador de versión, por lo que los registros DMARC existentes siguen siendo válidos sin necesidad de cambios inmediatos; las organizaciones pueden adoptar las nuevas funciones de manera progresiva.

Cambios clave en DMARCbis

Especificación reestructurada

El estándar actualizado se divide en tres borradores separados:

• Protocolo principal — define los fundamentos de DMARC
• Reporting agregado — describe cómo se generan y formatean los informes diarios
• Reporting forense — detalla cómo se reporta la información de fallos de autenticación

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

Algoritmo de recorrido del árbol DNS

El cambio técnico más significativo reemplaza la Lista de Sufijos Públicos (PSL) por un algoritmo de Recorrido del Árbol DNS para encontrar el límite organizacional de un dominio.

En lugar de depender de una lista pública mantenida manualmente, un receptor consulta niveles sucesivos de la jerarquía del dominio —subiendo una etiqueta a la vez— hasta que encuentra un registro DNS marcado como psd=y (un dominio de sufijo público) o psd=n (un límite organizacional).

• El recorrido está limitado a ocho niveles para evitar consultas DNS excesivas.
• Para dominios con ocho o más etiquetas, se eliminan las etiquetas situadas más a la izquierda hasta que queden siete antes de que comience el recorrido.
• El recorrido se detiene tan pronto como encuentra un registro DMARC válido con un valor psd explícito.

Este enfoque nativo de DNS elimina la dependencia de una lista de terceros, haciendo más probable que los cambios de límites se detecten de manera consistente y mejorando en general la precisión de la detección de límites de dominio.

Nota: Durante la transición, algunos receptores pueden seguir utilizando la PSL mientras que otros utilizan el Recorrido del Árbol, lo que ocasionalmente puede producir resultados diferentes para el mismo dominio. Publicar un registro DMARC explícito en cada dominio y subdominio —incluyendo una etiqueta psd donde sea relevante— evita la ambigüedad.

Nuevas etiquetas de política

DMARCbis introduce tres nuevas etiquetas para un control más preciso:

Etiqueta	Propósito
psd (Dominio de Sufijo Público)	y marca el dominio como un dominio de sufijo público, n lo marca como un dominio organizacional. El valor predeterminado, u, deja que el Recorrido del Árbol lo determine.
np (Política de Subdominio Inexistente)	Establece la política aplicada al correo electrónico que afirma provenir de un subdominio que no existe en DNS, cerrando una brecha de suplantación en la que los atacantes utilizan subdominios fabricados como ceo.example.com.
t (Modo de Prueba)	Indica que una política está siendo probada y aún no se aplica (y), o que se aplica con normalidad (n, el valor predeterminado).

Etiquetas heredadas obsoletas

Se han descontinuado tres etiquetas porque producían resultados inconsistentes entre receptores:

• pct (porcentaje) — sustituida por la etiqueta más clara t (Modo de Prueba)
• rf (formato de informe)
• ri (intervalo de informe) — la cadencia de reporting ahora está definida de manera uniforme en lugar de ser configurable

Estas etiquetas todavía se publican donde están configuradas, por motivos de compatibilidad con versiones anteriores, pero los receptores compatibles con DMARCbis dependerán cada vez más de sus reemplazos.

Reporting mejorado

El reporting agregado y forense ahora tienen cada uno su propio borrador de especificación, con requisitos más estrictos de consistencia y seguridad:

• Validación obligatoria de las direcciones de reporting externas (el destinatario de rua=/ruf= debe autorizar los informes enviados fuera del dominio remitente)
• Formato de adjuntos y convenciones de nomenclatura estandarizados
• Aplicación más estricta de la estructura XML y la compresión gzip

Orientación sobre listas de correo

DMARCbis proporciona orientación explícita sobre listas de correo y correo reenviado. Desaconseja publicar una política p=reject cuando las listas de correo forman parte del flujo normal de correo, ya que el software de listas frecuentemente rompe tanto el alignment de SPF como el de DKIM, lo que puede provocar que se rechacen mensajes legítimos.

Al mismo tiempo, DMARCbis continúa alentando a los propietarios de dominios a avanzar hacia una política p=reject siempre que sea factible, ya que es la única política que protege completamente a un dominio contra el uso no autorizado. La recomendación es evaluar su ecosistema de correo —incluyendo cualquier lista de correo— antes de pasar a la aplicación estricta.

Beneficios clave

• Detección más precisa del dominio organizacional mediante el algoritmo de Recorrido del Árbol DNS
• Etiquetas de política más simples y claras con señales de prueba inequívocas
• Protección más fuerte contra la suplantación de subdominios inexistentes
• Mejor soporte para estructuras de dominio complejas y dominios de sufijo público
• Mayor consistencia y seguridad en el reporting
• Sin migración forzada: los registros existentes siguen siendo válidos mientras adopta las nuevas funciones a su propio ritmo

Preguntas frecuentes

¿Necesito cambiar mi registro DMARC actual para DMARCbis?

No se requieren cambios inmediatos. DMARCbis mantiene el mismo identificador de versión (v=DMARC1), por lo que los registros existentes siguen siendo válidos. Puede adoptar las nuevas etiquetas de manera progresiva para reforzar su autenticación de correo electrónico con el tiempo.

¿Cómo mejora el Recorrido del Árbol DNS a la Lista de Sufijos Públicos?

En lugar de depender de una lista mantenida manualmente de sufijos públicos, el Recorrido del Árbol consulta el DNS directamente, subiendo por la jerarquía del dominio para identificar el límite organizacional correcto. Esto es más consistente, ya que no depende de que un tercero mantenga una lista actualizada.

¿Debería establecer una política p=reject ahora que DMARCbis la desaconseja para las listas de correo?

DMARCbis no desaconseja p=reject de manera absoluta; aconseja precaución específicamente cuando las listas de correo forman parte de su flujo de correo, ya que pueden romper el alignment de SPF/DKIM. Revise cómo se envía y reenvía realmente el correo de su dominio antes de pasar a la aplicación estricta.

Temas relacionados

• Descripción general de DMARC — Introducción a DMARC y su propósito
• Sintaxis de DMARC — Información detallada sobre los campos de registro DNS de DMARC
• Configuración de DMARC — Configure etiquetas de DMARCbis como el Modo de Prueba y la Política de Subdominio Inexistente