El Dominio Organizacional en DMARC: del Public Suffix List al DNS Tree Walk

Uno de los conceptos fundamentales dentro del protocolo DMARC (Domain-based Message Authentication, Reporting and Conformance) es el Dominio Organizacional. Este concepto cumple dos funciones clave:

1. Define el dominio de respaldo que se utiliza para buscar una política DMARC cuando no se encuentra un registro en el dominio exacto especificado en el encabezado “From”.
2. Proporciona la referencia contra la cual se evalúa la alineación relajada de autenticación mediante SPF y DKIM.

Por lo tanto, identificar correctamente el Dominio Organizacional es crucial tanto para descubrir políticas como para determinar si un correo pasa las verificaciones de alineación DMARC.

Limitaciones del método tradicional: Public Suffix List (PSL)

Según el estándar actual de DMARC (RFC 7489), cuando se recibe un correo electrónico desde, por ejemplo, user@sub.mail.example.com, el proceso de verificación sigue estos pasos:

1. Se consulta el DNS buscando un registro DMARC en _dmarc.sub.mail.example.com.
2. Si no se encuentra un registro válido, se busca el dominio organizacional, que se determina utilizando la Public Suffix List. En este caso, como .com es un sufijo público, el dominio organizacional es example.com.

Importante:

• No se revisan dominios intermedios como mail.example.com o sub.mail.example.com a menos que sean el dominio exacto o el dominio organizacional.
• Este método depende de la Public Suffix List, la cual:
  • Se mantiene fuera del sistema DNS.
  • Es compleja y, a veces, inconsistente.
  • Puede dificultar implementaciones mínimas o integradas.

DMARCbis y el nuevo enfoque: DNS Tree Walk

Para solucionar estas limitaciones, el nuevo borrador DMARCbis reemplaza el enfoque basado en PSL por un mecanismo más robusto, nativo de DNS: el DNS Tree Walk.

Este método consiste en recorrer la jerarquía del dominio desde el más específico al más general, buscando registros DMARC en cada nivel:

Ejemplo con user@a.mail.example.com:

1. Se consulta _dmarc.a.mail.example.com
2. Luego _dmarc.mail.example.com
3. Después _dmarc.example.com
4. Finalmente _dmarc.com

Este proceso se limita a dominios con menos de 8 etiquetas. Si el dominio tiene 8 o más etiquetas, se eliminan las etiquetas de la izquierda hasta que queden solo 7, y luego se aplica el recorrido.

Reglas para determinar el Dominio Organizacional

Una vez que se encuentran registros DMARC válidos, se sigue este orden para definir el dominio organizacional:

1. Si un registro DMARC contiene psd=n, ese dominio es el dominio organizacional.
2. Si un registro superior contiene psd=y, el dominio organizacional es el nivel inmediatamente inferior.
3. Si no se aplican las anteriores, el dominio con menos etiquetas (más alto en la jerarquía) con un registro DMARC válido se considera el dominio organizacional.

Ejemplos:

• Si _dmarc.mail.example.com tiene psd=n, entonces mail.example.com es el dominio organizacional.
• Si solo _dmarc.example.com tiene un registro con psd=y, entonces el dominio organizacional es mail.example.com.
• Si solo _dmarc.com tiene un registro con psd=y, entonces el dominio organizacional es example.com.

¿Por qué es importante este cambio?

El nuevo enfoque tiene múltiples beneficios:

• Mayor consistencia: El DNS se convierte en la única fuente de verdad, sin depender de listas externas.
• Implementación más simple: Ya no es necesario analizar ni actualizar la PSL.
• Más flexibilidad: Los subdominios pueden definir sus propios límites de política DMARC.
• Depuración más clara: Las búsquedas DNS son visibles y trazables.

¿Los propietarios de dominios deben hacer algo?

En la mayoría de los casos, no se requieren cambios inmediatos, especialmente si ya existe un registro DMARC válido en el dominio base (por ejemplo, example.com). Sin embargo, es recomendable:

• Revisar los registros DMARC existentes: Verifique que el dominio organizacional cuente con una política DMARC válida.
• Auditar subdominios: Si utiliza políticas por subdominios o tiene estructuras complejas como mail.example.com, asegúrese de que el comportamiento esperado de respaldo se mantenga con la lógica del Tree Walk.
• Considerar el uso del tag psd: Este puede ayudarle a definir explícitamente los límites de política durante el recorrido del árbol DNS. Por ejemplo, psd=n para evitar que dominios más altos hereden políticas.

---

El cambio del uso de Public Suffix List al DNS Tree Walk en el protocolo DMARCbis representa una mejora importante en la seguridad, transparencia y eficiencia del correo electrónico autenticado. Aunque la mayoría de los dominios ya configurados no necesitan modificaciones urgentes, este nuevo modelo abre la puerta a una gestión más flexible y controlada para organizaciones con estructuras de dominio más sofisticadas. ¡Es momento de revisar tus registros y prepararte para esta evolución en la autenticación de correos!