DMARCbis: todo lo que cambia (y cómo prepararte)

Estado a 29 de octubre de 2025. El corpus DMARCbis está prácticamente cerrado: el documento principal dmarcbis-41 y aggregate-reporting-32 están en la RFC Editor Queue (MISSREF), a la espera de que se finalice failure-reporting. Los registros DMARC existentes siguen utilizando v=DMARC1.

TL;DR

• Descubrimiento de políticas y dominio organizativo: la Public Suffix List (PSL) se sustituye por un DNS Tree Walk y por el nuevo marcador psd (y/n).
• Nuevos tags: psd, np (política para non-existent domains), t (testing, reemplaza el uso habitual de pct=0).
• Tags eliminados: pct, ri, rf.
• Reporting: dividido en dos documentos normativos (agrupados y fallos); desaparece el límite de longitud en la URI; cada URI listada DEBE recibir un reporte.
• Interoperabilidad: DMARCbis desaconseja p=reject en dominios de uso general (listas, alias, redirecciones) y recomienda p=quarantine hasta que controles toda la cadena de autenticación; reserva p=reject para los casos en los que gestionas todos los intermediarios. Los MTA no deben rechazar solo porque exista p=reject.
• Compatibilidad: los registros DMARC actuales siguen funcionando; prepara la transición hacia los nuevos tags y prácticas.

👉 Al final del artículo encontrarás un glosario con los conceptos clave: Public Suffix Domain, Organizational Domain y DNS Tree Walk.

1) Calendario y estado

• 17 de marzo de 2025: Aggregate Reporting v**–32** → RFC Editor Queue (MISSREF).
• 4 de abril de 2025: DMARCbis v**–41** → RFC Editor Queue (MISSREF).
• 9 de octubre de 2025: Failure Reporting v**–17** entra en WG Last Call.
• Publicación prevista en 2025 si se resuelven las referencias pendientes.
• Impacto inmediato: no cambia la versión (v=DMARC1); aun así, operadores e implementadores deben prepararse para los nuevos algoritmos y tags.

2) Descubrimiento de políticas y Organizational Domain: el DNS Tree Walk

DMARCbis reemplaza la dependencia de la PSL por un recorrido ascendente del árbol DNS que

1. descubre la política aplicable (Policy Discovery), y
2. determina el dominio organizativo (Organizational Domain) para el Alignment.

Principios clave:

• Primero se consulta "_dmarc." + AuthorDomain. Si no existe, se asciende etiqueta por etiqueta (máximo 8 consultas) hasta encontrar un Organizational Domain o un PSD.
• El tag psd guía la interpretación:
  • psd=n ⇒ el dominio que publica el registro es un Organizational Domain.
  • psd=y (en un nivel superior) ⇒ el Organizational Domain está un nivel por debajo.
• Si la política se hereda de un dominio padre (Org o PSD), se aplica sp cuando el subdominio existe y np cuando el subdominio no existe.
• Si no se encuentra ningún registro, DMARC no se aplica al mensaje.

3) Tags: añadidos, eliminados, sin cambios

Añadidos

• psd: marca un dominio como Public Suffix Domain (y/n) para orientar el Tree Walk.
• np: política para dominios inexistentes (derivada de la experiencia PSD).
• t: modo prueba (y/n) — sustituye el patrón útil de pct=0 (ver más abajo).

Eliminados

• pct: los despliegues parciales eran incoherentes entre implementaciones; se mantiene el enfoque 0/100 mediante t.
• ri: intervalo de los reportes agregados (pasa al documento Aggregate Reporting y a la práctica operativa).
• rf: formato de los reportes de fallos (detallado en el documento Failure Reporting).

Sin cambios (ejemplos)

v, p, sp, adkim, aspf, fo, rua, ruf, pct (eliminado: retirar).

4) psd: marcador de Public Suffix Domain

El tag psd indica si el dominio que publica el registro DMARC debe tratarse como un Public Suffix Domain por el algoritmo de Tree Walk:

• psd=y: el dominio se considera un PSD. La política publicada cubre el sufijo que administras, pero deja que los dominios registrables por debajo gestionen su propio DMARC.
• psd=n: el dominio es un Organizational Domain y sirve de ancla para el descubrimiento de políticas de sus subdominios.

Reserva psd=y para operadores de sufijos (TLD, registros sectoriales, organizaciones grandes con subdominios delegados). En otros casos, omite el tag o establece explícitamente psd=n para señalar que se trata de un dominio emisor «normal».

5) np: política para dominios inexistentes

El tag np extiende DMARC a subdominios inexistentes detectados durante el Tree Walk:

• Solo aplica cuando no se encuentra un registro _dmarc específico para el subdominio (NXDOMAIN).
• Los valores permitidos (none, quarantine, reject) siguen la misma semántica que p/sp.
• Si np no está presente, se reutiliza el valor de p (o el sp heredado).

Publica np=reject en tu dominio organizativo (o en el PSD) para bloquear intentos de spoofing sobre subdominios «vacíos» sin tener que crear registros DMARC individuales.

6) t = testing: el sucesor práctico de pct=0

El tag t=y no desactiva el reporting, pero pide que la aplicación de la política sea más suave:

• p=reject + t=y ⇒ tratar los fallos como quarantine.
• p=quarantine + t=y ⇒ tratar los fallos como none.
• p=none ⇒ sin cambios.

Objetivo: permitir una escalada controlada sin los problemas de interoperabilidad que provocaba pct.

7) Reporting: separación, entregabilidad y seguridad

• Dividido en dos RFC: reportes agregados (XML) y reportes de fallos (mensaje por mensaje).
• Se elimina el límite de longitud en la URI.
• Múltiples URIs en rua/ruf: cada URI DEBE recibir su propio reporte.
• Destinos externos (rua/ruf que apuntan a otro dominio): el mecanismo de autorización se mantiene (registros publicados por quien recibe los reportes).
• Privacidad: activa los reportes de fallos con cautela; la mayoría de operadores sigue priorizando los reportes agregados.

8) Interoperabilidad y políticas

• DMARCbis deja claro que los dominios de uso general (listas de distribución, alias, redirecciones) no deberían publicar p=reject; opta por p=quarantine hasta que la cadena de autenticación de extremo a extremo esté bajo control y conserva p=reject solo donde controlas cada salto.
• Los receptores no deberían rechazar un mensaje únicamente porque exista una política reject; deben correlacionar otras señales (comportamiento de listas, reescrituras de encabezados, ARC, reputación, etc.).
• Para evitar eludir el modo relaxed, publica registros DMARC lo más cerca posible de los dominios que envían realmente (y considera adkim=s/aspf=s donde sea razonable).

9) Compatibilidad y transición

• v=DMARC1 se mantiene: los registros existentes siguen siendo válidos.
• A retirar: pct, ri, rf.
• A introducir: psd donde sea pertinente (PSO / TLD o dominios registrables especiales), np para controlar los non-existent domains y t para pilotar el despliegue.

Ejemplos de registros

Política organizativa + escalada controlada

_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; sp=reject; adkim=s; aspf=r; 
  rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; t=y"

Marcado PSD por parte de un operador de sufijo

_dmarc.bank.example. 3600 IN TXT "v=DMARC1; p=reject; psd=y; rua=mailto:psd-agg@pso.example"

Política para dominios inexistentes

_dmarc.example.net. 3600 IN TXT "v=DMARC1; p=quarantine; np=reject; rua=mailto:agg@example.net"

10) Playbook de CaptainDNS (lista práctica)

1. Inventario: enumera las Author Domains reales y los subdominios activos; detecta las zonas sin DMARC.
2. Árboles DNS: verifica el resultado del Tree Walk (¿dónde se detiene el Organizational Domain?) y publica registros lo más cerca posible de los emisores reales.
3. Políticas: empieza con p=quarantine + t=y; monitoriza los reportes agregados durante 2–4 semanas; pasa a t=n y endurece si los falsos positivos están controlados.
4. Alignment: apunta primero a adkim=s (DKIM firmando el From); mantén aspf=r salvo que necesites SPF estricto.
5. PSD / np: si operas un dominio raíz o “de familia”, usa np para bloquear los non-existent domains; solo publica psd si eres PSO/PSD.
6. Reporting: utiliza buzones rua/ruf dedicados, cifrados en tránsito; valida las autorizaciones externas si un tercero recibe los reportes.
7. Listas / intermediarios: anticipa las reescrituras de From:; ARC ayuda a preservar la reputación y a evitar rechazos innecesarios.
8. Limpieza: retira pct, ri, rf; vigila los reportes agregados para detectar anomalías de interoperabilidad.

11) FAQ

• ¿Debemos cambiar v=DMARC1 por v=DMARC2? No — el valor sigue siendo DMARC1.
• ¿pct sigue teniendo efecto? Se ha eliminado del estándar; algunos receptores pueden ignorarlo. Utiliza t.
• ¿La PSL desaparece por completo? Sí, para DMARCbis: el descubrimiento ahora se basa en el DNS Tree Walk.
• ¿Puedo publicar p=reject en todas partes? Solo si controlas totalmente la cadena de autenticación; para mensajería general (listas, alias, redirecciones) DMARCbis recomienda permanecer en p=quarantine.

12) Glosario

• Public Suffix List (PSL): lista de sufijos públicos mantenida históricamente por Mozilla; DMARCbis sustituye su uso por el DNS Tree Walk.
• Public Suffix Domain (PSD): sufijo de dominio operado por una entidad que delega subdominios a terceros (p. ej., TLD, registros sectoriales) y que puede publicar una política DMARC que cubra todo el sufijo.
• Public Suffix Operator (PSO): entidad que gestiona un sufijo público (PSD) y puede publicar una política DMARC de referencia para los dominios asociados.
• DNS Tree Walk: procedimiento de DMARCbis que recorre el árbol DNS etiqueta por etiqueta para encontrar un registro _dmarc, detectar un PSD y, si procede, aplicar una política heredada (p, sp, np).
• Organizational Domain: dominio principal de una organización, identificado mediante el Tree Walk, que rige la política DMARC de sus subdominios alineados.
• Author Domain: dominio presente en el encabezado visible From:; es la base del cálculo de alineamiento DMARC.

---

Ilustraciones: diagramas SVG elaborados en casa para CaptainDNS.