DMARCbis Checker

DMARCbis: qué cambia para su dominio

DMARCbis (también llamado DMARC v2) no es una simple actualización. Es una reestructuración completa del protocolo DMARC, dividida en tres RFC distintos. Un DMARCbis checker permite identificar los ajustes necesarios:

1. Mecanismo principal (draft-ietf-dmarc-dmarcbis): descubrimiento de política, alignment, evaluación
2. Reportes agregados (draft-ietf-dmarc-aggregate-reporting): formato XML, esquema, distribución
3. Reportes de fallo (draft-ietf-dmarc-failure-reporting): reportes ARF, privacidad, rate limiting

Nuevos tags

Tags eliminados

Tree walk DNS

El cambio más significativo de DMARCbis es el reemplazo de la Public Suffix List (PSL) por un algoritmo de recorrido DNS nativo.

¿Por qué? La PSL es una lista comunitaria mantenida por voluntarios de Mozilla. Sufre de retrasos en actualizaciones, inconsistencias entre implementaciones y la ausencia de una especificación IETF sobre qué versión utilizar. El tree walk DNS resuelve estos problemas basándose únicamente en datos DNS reales.

¿Cómo funciona? El receptor consulta _dmarc.<dominio>, luego sube un label en cada paso. Si un registro contiene psd=n, ese es el dominio organizacional. Si se encuentra psd=y, el dominio un nivel más abajo es el dominio organizacional.

¿Quién adopta DMARCbis actualmente?

En marzo de 2026, solo GMX, mail.com y WEB.DE (grupo United Internet) envían reportes en formato DMARCbis. La adopción masiva se espera después de la publicación oficial de los RFC. Los registros DMARCbis son retrocompatibles: los receptores que no entienden los nuevos tags simplemente los ignoran.

Prepárese ahora

Aunque la migración no es urgente, preparar su dominio ahora permite:

• Identificar los tags obsoletos a eliminar antes de que generen advertencias
• Agregar el tag np para proteger los subdominios inexistentes
• Comprender el tree walk y verificar que su dominio organizacional se determina correctamente
• Anticipar los cambios en el reporting en sus herramientas de análisis DMARC

DMARC vs DMARCbis: tabla comparativa

Esta tabla resume las diferencias estructurales entre las dos versiones del protocolo. Si su registro contiene tags de la columna DMARC que ya no existen en DMARCbis, el checker los señala automáticamente.

¿Cómo funciona el tree walk DNS?

El tree walk DNS es la innovación central de DMARCbis. Reemplaza las consultas a la Public Suffix List por un recorrido jerárquico DNS. A continuación, un ejemplo detallado para entender cada paso.

Ejemplo: un correo recibido de user@sub.mail.captaindns.com

El receptor necesita encontrar la política DMARC aplicable. Con DMARCbis, realiza las siguientes consultas en orden:

1. Consulta _dmarc.sub.mail.captaindns.com: el servidor DNS responde NXDOMAIN (sin registro encontrado). El receptor sube un label.
2. Consulta _dmarc.mail.captaindns.com: el servidor DNS responde NXDOMAIN. El receptor sube nuevamente.
3. Consulta _dmarc.captaindns.com: se encuentra un registro TXT, p. ej. v=DMARC1; p=reject; psd=n.

El tag psd=n indica que captaindns.com es un dominio organizacional (no un public suffix). El tree walk se detiene. Resultado: dominio organizacional = captaindns.com, método de descubrimiento = tree walk.

¿Qué sucede con psd=y? Si _dmarc.captaindns.com contuviera psd=y, significaría que captaindns.com es un public suffix (como .co.uk). En ese caso, el dominio organizacional sería mail.captaindns.com, el dominio un nivel por debajo del sufijo.

Límite de seguridad: el tree walk realiza un máximo de 8 consultas DNS para prevenir la amplificación. Si tras 8 niveles no se obtiene resultado, el descubrimiento falla y el dominio se trata como si no tuviera política DMARC publicada.

Ventaja clave: a diferencia de la PSL, que requiere actualizaciones manuales y varía entre implementaciones, el tree walk se basa en datos DNS en tiempo real. Los administradores DNS conservan el control total sobre su frontera organizacional.

Por qué el tag np es esencial

El tag np (non-existent domain policy) cierra una brecha de seguridad que DMARC v1 no podía abordar: la suplantación de subdominios inexistentes.

El vector de ataque: un atacante envía un correo desde fake123.captaindns.com. Este subdominio no existe en su zona DNS. Con DMARC v1, el receptor aplica la política sp (si está presente) o recurre a p. Si su configuración es p=reject; sp=none (una configuración común para permitir subdominios legítimos), el atacante elude su protección.

La solución DMARCbis: el tag np=reject se aplica exclusivamente a subdominios para los cuales DNS responde NXDOMAIN. Puede mantener una política flexible en sus subdominios existentes (sp=none o sp=quarantine para subdominios con flujos de correo legítimos) mientras bloquea los subdominios inventados por atacantes.

Configuración recomendada:

• Si p=reject: agregar np=reject para cobertura máxima
• Si p=quarantine: agregar np=reject (los subdominios ficticios merecen bloqueo estricto)
• Si p=none: agregar np=quarantine como primer paso hacia el endurecimiento

El tag np es particularmente eficaz contra ataques de fraude al CEO, donde los atacantes inventan subdominios creíbles como secure-payment.captaindns.com o internal-hr.captaindns.com para engañar a los destinatarios.

Cronología de adopción de DMARCbis

La transición a DMARCbis sigue un cronograma gradual impulsado por la IETF y los principales proveedores de correo electrónico.

Los registros DMARCbis son retrocompatibles: puede agregar los nuevos tags hoy sin esperar la publicación oficial. Los receptores que no entienden np, t o psd los ignoran silenciosamente.

Herramientas complementarias

Recursos útiles

• RFC 7489 - DMARC
• draft-ietf-dmarc-dmarcbis
• RFC 9091 - PSD DMARC
• DMARCbis: todos los cambios y cómo prepararse

FAQ - Preguntas frecuentes

P: ¿Qué es DMARCbis?

R: DMARCbis es la nueva versión del protocolo DMARC, en proceso de finalización en la IETF como Proposed Standard. Reemplaza el RFC 7489 (2015) y el RFC 9091 (PSD DMARC). Los tres documentos (mecanismo principal, reportes agregados, reportes de fallo) están en la cola del editor RFC desde 2025.

P: ¿Cuáles son las diferencias entre DMARC y DMARCbis?

R: DMARCbis agrega tres nuevos tags (np, t, psd), elimina tres tags (pct, rf, ri), reemplaza el descubrimiento vía Public Suffix List por un algoritmo tree walk DNS y restringe la validación SPF únicamente al MAIL FROM.

P: ¿Debo migrar a DMARCbis de inmediato?

R: No hay urgencia. Los registros DMARC actuales siguen funcionando porque la versión se mantiene en v=DMARC1. Sin embargo, se recomienda auditar sus registros ahora para eliminar los tags obsoletos y agregar los nuevos tags np y psd.

P: ¿Se elimina realmente el tag pct?

R: Sí. La experiencia operativa demostró que el tag pct se aplicaba de manera inconsistente por los receptores. Solo los valores 0 y 100 eran confiables. Se reemplaza por el tag binario t (t=y para modo prueba, t=n para aplicación completa).

P: ¿Qué es el tree walk DNS?

R: El tree walk DNS es el algoritmo de descubrimiento de política DMARC en DMARCbis. En lugar de consultar una Public Suffix List externa, el receptor recorre la jerarquía DNS consultando _dmarc en cada nivel hasta encontrar un registro válido. Esto elimina la dependencia de la PSL.

P: ¿Se elimina el tag fo en DMARCbis?

R: No. El tag fo (failure reporting options) se mantiene en DMARCbis. Solo los tags pct, rf y ri se eliminan.

P: ¿Cómo sé si mi dominio está listo para DMARCbis?

R: Ejecute un análisis con nuestro DMARCbis checker. La herramienta realiza un tree walk DNS completo, detecta los tags obsoletos (pct, rf, ri), verifica la presencia del tag np y muestra el dominio organizacional descubierto. El resultado indica un estado claro: conforme, compatible o no conforme con DMARCbis.

P: ¿El tree walk DNS ralentiza la entrega de correo?

R: No. El tree walk realiza un máximo de 8 consultas DNS, y los receptores almacenan los resultados en caché según el TTL de cada registro. En la práctica, para la mayoría de los dominios, el tree walk se resuelve en 2 o 3 consultas. El impacto en el tiempo de entrega es insignificante.