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 tu 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 endurezcas 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.tu-dominio.es aunque ese subdominio no exista. Poner un np=reject cierra esa puerta sin ningún riesgo para tu 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 que debe relajarte: 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.
• Tu registro actual sigue siendo válido: ningún destinatario lo va a rechazar porque «date» de la 7489.

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

¿Tienes que actuar?

Si tu dominio ya está en p=reject con una alineación limpia, estás tranquilo. Tres pequeños gestos, fáciles y sin riesgo, valen aun así la pena:

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

Si aún estás bloqueado en p=none, la prioridad no es DMARCbis: es alcanzar la aplicación. El método es el mismo que antes — consulta llegar a p=reject sin romper tus emails. 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. Puedes observar la postura real de sectores enteros — cuántos dominios están solo en p=none, por ejemplo — 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, para ti, eso quiere decir que apoyarte en DMARC ya no es una apuesta por una «buena práctica», sino por una norma establecida — un argumento de peso cuando tienes que justificar tus decisiones ante una dirección o un auditor.

Actualiza tus referencias, no tu DNS

La consecuencia más concreta para ti es quizá documental. Si tus políticas de seguridad internas, tus procedimientos de explotación o tus respuestas a los cuestionarios de auditoría citan la RFC 7489, esas referencias apuntan ahora a un texto obsoleto. Aprovecha para refrescarlas: es una corrección de unos minutos que te evita una observación fácil de un auditor puntilloso. Lo mismo del lado de los proveedores — si un proveedor te presenta una conformidad «RFC 7489», no es descalificador (el protocolo sigue siendo compatible), pero es un indicio de que su documentación no ha seguido el estándar. Al contrario, no tienes que tocar nada del lado del DNS: esta actualización es sobre el papel, no sobre tus 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 tus servidores, DKIM firma tus mensajes, DMARC(bis) impone que uno de los dos se alinee con tu From:. Los tres siguen funcionando juntos — consulta cómo funcionan juntos SPF, DKIM y DMARC.

¿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 tu proveedor: sigues 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. Puedes editar tu registro a mano. Una herramienta ayuda sobre todo a saber qué publicar (qué etiquetas, qué política) en función del estado real de tu 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: tus claves en el sitio adecuado

DMARC, SPF y DKIM descansan sobre secretos — en primer lugar tus 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), echa un vistazo a Hucency Vault. Una buena higiene de claves es el complemento natural de una buena política DMARC.

Deja que Thomas se ocupe de DMARCbis por ti

Seguir la evolución de un estándar mientras diriges una empresa no es tu trabajo. Thomas, tu CISO virtual, genera el DNS exacto que publicar (etiquetas DMARCbis incluidas: np, t), nombra cada fuente de envío a partir de tus informes, evalúa tu preparación sobre datos deslizantes y te dice el momento preciso para endurecer sin riesgo — de p=none hasta p=reject.

Analiza tu dominio gratis → o crea una cuenta y deja que Thomas haga el trabajo pesado.