DMARCbis (DMARC V2): qué cambia realmente, explicado de forma sencilla

Las tres RFC de DMARCbis

DMARCbis no es un solo documento, sino tres, lo que aclara una organización antes confusa:

• RFC 9989 — el núcleo del protocolo (políticas, alineación, etiquetas). Es el sucesor directo de la 7489.
• RFC 9990 — los informes agregados (RUA), el canal de retorno diario.
• RFC 9991 — los informes de fallo (RUF), más raros y sujetos a restricciones de privacidad.

Juntas, estas tres RFC dejan obsoleta la RFC 7489. Detallamos su contenido en RFC 9989/9990/9991: qué cambia en DMARC.

Qué cambia en concreto

Tres cambios merecen atención. Ninguno es una ruptura, pero cada uno tiene un efecto práctico.

1. La etiqueta pct desaparece, reemplazada por t

La antigua etiqueta pct permitía aplicar la política a un porcentaje del correo (pct=25, luego 50, luego 100) para un despliegue progresivo. En la práctica, se comportaba de forma imprevisible según los destinatarios. DMARCbis la retira e introduce un modo de prueba binario, la etiqueta t (t=y significa «estoy experimentando, no endurezca aún de forma estricta»). La subida de nivel se apoya ahora en la observación de los informes en lugar de en un porcentaje. Profundizamos en el tema en un artículo dedicado a la etiqueta t.

2. Dos nuevas etiquetas de subdominio: np y psd

La etiqueta np fija la política de los subdominios inexistentes — un objetivo de suplantación clásico, porque un atacante puede forjar factura.ejemplo.es aunque ese subdominio no exista. Poner un np=reject cierra esa puerta sin ningún riesgo para el correo legítimo. La etiqueta psd sirve a los operadores de dominios de sufijo público (registros). Para la mayoría de las organizaciones, lo que cuenta sobre todo es np: un artículo dedicado a la etiqueta np estará disponible próximamente.

3. El DNS Tree Walk reemplaza la Public Suffix List

Para determinar el «dominio organizativo» (por ejemplo, que mail.mi-banco.es pertenece a mi-banco.es), DMARC se apoyaba en la Public Suffix List, una lista externa mantenida a mano. DMARCbis la reemplaza por el DNS Tree Walk: una serie de consultas DNS paso a paso (ocho como máximo), sin dependencia de una lista de terceros. Más robusto, más predecible. Detalles en un artículo dedicado al DNS Tree Walk.

Lo que no cambia (y eso tranquiliza)

Este es el punto tranquilizador: DMARCbis no es una ruptura.

• Los registros siguen empezando por v=DMARC1. Ni v=DMARC2, ni un nuevo formato que aprender.
• Las etiquetas p, sp, rua, ruf, adkim, aspf, fo conservan exactamente el mismo significado.
• El principio de alineación — el núcleo de DMARC — no cambia.
• Un registro actual sigue siendo válido: ningún destinatario lo va a rechazar porque «date» de la 7489.

Dicho de otro modo, no hay nada que cambiar para seguir protegido. Las novedades son mejoras que adoptar cuando convenga, no correcciones urgentes.

¿Hay que actuar?

Un dominio ya en p=reject con una alineación limpia no corre ningún riesgo. Tres pequeños gestos, fáciles y sin consecuencias, valen aun así la pena:

1. Añadir np=reject para bloquear los subdominios fantasma.
2. Retirar un pct que ya no sirve si aún anda por el registro.
3. Comprobar que los informes siguen llegando (el canal RUA está ahora regulado por la RFC 9990).

Para un dominio aún bloqueado en p=none, la prioridad no es DMARCbis: es alcanzar la aplicación. El método es el mismo que antes — está en llegar a p=reject sin romper el correo legítimo. La hoja de ruta completa de migración se detallará en un artículo dedicado.

¿En qué punto está el mercado?

La adopción de DMARCbis es progresiva: los destinatarios actualizan sus implementaciones a su ritmo, y las nuevas etiquetas (np, t) irán apareciendo poco a poco en los informes. La postura real de sectores enteros — cuántos dominios están solo en p=none, por ejemplo — se observa en el Observatorio DMARC. La constatación sigue siendo tajante: la mayoría de los dominios, en numerosos sectores, aún no aplica ninguna política. DMARCbis no va a cambiar eso por sí solo; la disciplina de alineación, sí.

De 2015 a 2026: por qué ahora

DMARC se publicó como RFC 7489 en 2015, con estatus Informational. En una década, se convirtió en un estándar de facto: Google, Microsoft y Yahoo lo exigen a los remitentes en masa, y regulaciones como NIS2 o DORA lo convierten en un control esperado. Ese desfase — un uso crítico que descansa sobre un documento solo «informativo» — había que corregirlo. DMARCbis es el fruto de varios años de trabajo dentro del IETF para transformar la experiencia sobre el terreno en una verdadera norma: promover el protocolo a la vía de los estándares, retirar lo que funcionaba mal (pct) y cubrir los puntos ciegos (np para los subdominios inexistentes, Tree Walk en lugar de la PSL). El calendario de mayo de 2026 no tiene nada de arbitrario: consagra la madurez de un protocolo que se ha vuelto ineludible. En concreto, eso quiere decir que apoyarse en DMARC ya no es una apuesta por una «buena práctica», sino por una norma establecida — un argumento de peso a la hora de justificar una decisión ante una dirección o un auditor.

Actualizar las referencias, no el DNS

La consecuencia más concreta es quizá documental. Cuando las políticas de seguridad internas, los procedimientos de explotación o las respuestas a los cuestionarios de auditoría citan la RFC 7489, esas referencias apuntan ahora a un texto obsoleto. Refrescarlas es una corrección de unos minutos que evita una observación fácil de un auditor puntilloso. Lo mismo del lado de los proveedores — un proveedor que presente una conformidad «RFC 7489» no queda descalificado (el protocolo sigue siendo compatible), pero es un indicio de que su documentación no ha seguido el estándar. Al contrario, no hay nada que tocar del lado del DNS: esta actualización es sobre el papel, no sobre los registros, que siguen siendo válidos tal cual.

Preguntas frecuentes sobre DMARCbis

¿DMARCbis reemplaza a SPF y DKIM? No. DMARCbis no toca ni SPF ni DKIM: sigue siendo la capa que los vincula al dominio visible mediante la alineación. SPF declara los servidores autorizados, DKIM firma los mensajes, DMARC(bis) impone que uno de los dos se alinee con el From:. Los tres siguen funcionando juntos — cómo funcionan juntos SPF, DKIM y DMARC lo detalla.

¿Mi registro v=DMARC1 sigue siendo válido? Sí, totalmente. DMARCbis conservó deliberadamente el identificador v=DMARC1 para no romper nada. Un registro escrito para la RFC 7489 sigue siendo un registro DMARCbis perfectamente válido; ningún destinatario lo rechazará.

¿Debo esperar a que mi proveedor de DNS «soporte» DMARCbis? No. DMARCbis no le pide nada especial a un proveedor: se sigue publicando un simple registro TXT. Las novedades (np, t) no son más que nuevas etiquetas dentro de ese TXT, y cualquier DNS sabe alojar un TXT.

¿Hace falta una nueva herramienta para «pasar» a DMARCbis? Tampoco. El registro se edita a mano. Una herramienta ayuda sobre todo a saber qué publicar (qué etiquetas, qué política) en función del estado real del dominio — es el papel de Thomas, más abajo.

¿Afecta a los dominios pequeños? Sí, pero sin urgencia. Un dominio pequeño gana sobre todo poniendo np=reject (gratuito, sin riesgo) y, si aún no está protegido, apuntando a p=reject — con DMARCbis o sin él. El tamaño no cambia la lógica, solo el número de fuentes que alinear.

Una nota de seguridad: las claves en el sitio adecuado

DMARC, SPF y DKIM descansan sobre secretos — en primer lugar las claves privadas DKIM. Dejarlas tiradas en un archivo de configuración o en un correo es exactamente el tipo de descuido que un atacante adora. DMARC.com está editado por Hucency, especialista en ciberseguridad; para centralizar y cifrar este tipo de secretos (claves DKIM, credenciales DNS, tokens de API), existe Hucency Vault. Una buena higiene de claves es el complemento natural de una buena política DMARC.

Thomas se ocupa de DMARCbis

Seguir la evolución de un estándar mientras se dirige una empresa no forma parte del trabajo. Thomas, el CISO virtual, genera el DNS exacto que publicar (etiquetas DMARCbis incluidas: np, t), nombra cada fuente de envío a partir de los informes, evalúa la preparación del dominio sobre datos deslizantes e indica el momento preciso para endurecer sin riesgo — de p=none hasta p=reject.

Analizar un dominio gratis o crear una cuenta y dejar que Thomas haga el trabajo pesado.