Email Collaboration Threat Protection

DMARC ya es un estándar propuesto por la IETF: ¿está preparada su organización?

A continuación le explicamos qué ha cambiado, qué implicaciones tiene para los requisitos de cumplimiento normativo y de seguros, y por qué la opción «p=none» ya no es una opción segura.

by Alexander Decarne

jun. 02, 2026

Key Points

DMARC ha pasado de ser un documento informativo a convertirse en una norma propuesta (RFC 9989) en el proceso de normalización de la IETF. Sus requisitos cuentan ahora con el respaldo de un consenso oficial.
Los registros v=DMARC1 existentes siguen siendo plenamente válidos. El RFC 9989 introduce cambios estructurales que las organizaciones pueden adoptar a su propio ritmo; sin embargo, la presión derivada del cumplimiento normativo y de los seguros para avanzar hacia la aplicación de estas medidas se está acelerando.
Las aseguradoras cibernéticas se interesan cada vez más por la aplicación de DMARC durante el proceso de suscripción. Cada vez son más las empresas de transporte que consideran que una postura de «p=ninguna» —es decir, la mera supervisión— constituye una señal menos contundente que la aplicación de una política.

Tras once años como una convención de la comunidad ampliamente adoptada, pero sin estatus oficial en el IETF, DMARC es ahora un documento de la vía de normalización del IETF. El RFC 9989, publicado en mayo de 2026, deja obsoleto el RFC 7489 y sitúa a DMARC en la misma vía de estandarización que protocolos fundamentales como SMTP e IMAP. Para la mayoría de las organizaciones, esto podría parecer una nota al pie de carácter técnico. No lo es.

Por qué es importante el cambio de estatus

El RFC 7489 original se publicó en 2015 a través del «Independent Submission Stream» de la IETF, lo que significa que no tenía el peso de un consenso formal de la IETF; por ello, las implementaciones divergieron y las deficiencias quedaron sin resolver durante años. La RFC 9989 modifica esto: los requisitos de DMARC reflejan ahora el consenso formal de la IETF, revisados por la comunidad y aprobados por el IESG.

La consecuencia práctica es que los sectores regulados y los marcos de contratación pública disponen ahora de una referencia estable y citable para exigir la adopción de DMARC. Una norma propuesta por el IETF es el tipo de documento que acaba formando parte de las directrices de seguridad de las administraciones públicas, las recomendaciones del sector financiero y los marcos de gestión de riesgos de los proveedores empresariales. La Directiva NIS2 de la UE y la DORA ya exigen a las organizaciones que apliquen controles de seguridad del correo electrónico; el RFC 9989 proporciona a dichos marcos una base técnica precisa.

El RFC 9989 va acompañado de dos normas complementarias. La RFC 9990 trata sobre la presentación de informes agregados y la RFC 9991 sobre la notificación de fallos; ambas son ahora normas propuestas independientes. Al separar la generación de informes del protocolo principal, se aclaran las expectativas de implementación tanto para los remitentes como para los destinatarios y los proveedores de herramientas.

El aspecto del seguro cibernético que no debe pasar por alto

Más allá del cumplimiento técnico, las aseguradoras cibernéticas están teniendo en cuenta el estado de cumplimiento de DMARC a la hora de tomar decisiones de suscripción, y es probable que la RFC 9989 intensifique ese escrutinio. El informe «Perspectivas sobre las condiciones del mercado de los seguros cibernéticos para 2025», elaborado por Gallagher, pone de manifiesto que las aseguradoras están evaluando la situación de seguridad de las organizaciones de forma más detallada, y que la autenticación del correo electrónico se menciona explícitamente, junto con la autenticación multifactorial (MFA), la detección y respuesta a amenazas (EDR) y las prácticas de copias de seguridad, como factores que influyen en la fijación de las primas y en la disponibilidad de la cobertura.

En las solicitudes de suscripción de las principales aseguradoras se pregunta ahora de forma habitual si las organizaciones han implementado SPF, DKIM y DMARC. Sin embargo, la cuestión que subyace a la casilla de selección es, cada vez más, si se aplica realmente la política. Una configuración «p=none», que supervisa los flujos de correo electrónico pero no toma ninguna medida ante los mensajes fallidos, constituye una señal menos clara para las entidades aseguradoras que las configuraciones «p=quarantine» o «p=reject». Las organizaciones que mantengan la postura «p=none» de forma permanente podrían verse sometidas a un escrutinio adicional en el momento de la renovación, a condiciones menos favorables o a una reducción de los límites de cobertura.

Cinco cambios que los equipos de TI deben comprender

Los registros existentes que comienzan por «v=DMARC1» siguen siendo plenamente válidos, sin que exista ningún plazo de migración. Sin embargo, varios cambios estructurales afectarán al comportamiento de las consultas de DNS, a la gestión de informes y a la estrategia de implantación.

1. Se eliminan tres etiquetas: pct=, rf= y ri=

La etiqueta «pct=» (implementación basada en porcentajes) ha desaparecido; en la práctica, rara vez se utilizaba con matices. También se ha eliminado la etiqueta «rf=» (formato de informe), ya que en realidad solo se utilizó un formato. Y se elimina ri= (intervalo de informe solicitado); el RFC 9989 recomienda que los receptores envíen informes a diario. Si sus registros aún contienen estas etiquetas, no se produce ningún error —las etiquetas desconocidas se ignoran de forma silenciosa, según lo establecido en el apartado 4.7 del RFC 9989—, pero pueden eliminarse.

2. La etiqueta «t=» sustituye a «pct=» por un comportamiento predecible y gradual

La etiqueta «t=» tiene dos valores. El modo de prueba de señales «t=y»: la combinación de «p=cuarentena» con «t=y» trata los mensajes que no superan la comprobación como si se aplicara «p=ninguna»; la combinación de «p=rechazo» con «t=y» los trata como si se aplicara «p=cuarentena», lo que supone un enfoque un paso menos estricto que la política establecida. t=n (valor predeterminado) aplica la política de forma habitual. Esto subsana la ambigüedad que provocaba que pct= presentara inconsistencias entre las distintas implementaciones.

3. Nueva etiqueta: «np=» para subdominios inexistentes

El RFC 9989 introduce el parámetro «np=», que define la política DMARC específicamente para subdominios inexistentes, es decir, aquellos que carecen de registro DNS. Anteriormente, estos se incluían en «sp=» o se establecían por defecto con el valor «p=» del dominio de la organización. En ocasiones, los atacantes envían mensajes desde subdominios que no existen en el DNS, aprovechando esa ambigüedad. La etiqueta «np=» otorga a los propietarios de los dominios un control explícito.

4. El recorrido por el árbol DNS sustituye a la Lista de sufijos públicos

Anteriormente, la identificación de dominios organizativos se basaba en la Lista de Sufijos Públicos (PSL), una base de datos externa estática que se actualizaba manualmente. La RFC 9989 sustituye este método por el algoritmo «DNS Tree Walk», que recorre dinámicamente la jerarquía del DNS desde el dominio del encabezado «From:» hasta localizar el registro TXT _dmarc correspondiente, eliminando así una fuente conocida de atribución errónea de políticas en estructuras de dominios complejas.

5. La compatibilidad con PSD y la etiqueta «psd=» ahora forman parte del núcleo

La compatibilidad con los dominios de sufijo público era anteriormente experimental (RFC 9091). El RFC 9989 deja obsoleto el RFC 9091 e integra la gestión de PSD en la especificación principal. La etiqueta «psd=» ya es estándar, y no experimental, lo cual resulta especialmente relevante para las organizaciones que operan bajo dominios de segundo nivel con código de país, como .co.uk.

Qué implica esto para el sector

Para las organizaciones que aún se encuentran en el nivel p=none, el RFC 9989 endurece los requisitos en dos frentes a la vez. Los marcos de auditoría y los requisitos de contratación pública cuentan ahora con una norma formal y citable a la que remitirse, y las disposiciones específicas de cada sector se basarán cada vez más en la RFC 9989, en lugar de en su predecesora de carácter informativo. Al mismo tiempo, la presión por parte de las aseguradoras para que se adopten medidas coercitivas está aumentando, independientemente de los factores que impulsan el cumplimiento normativo.

El proceso para garantizar el cumplimiento no ha cambiado: la visibilidad es lo primero; se debe identificar cada fuente de envío y resolver todos los fallos de SPF y DKIM antes de que se endurezcan las políticas. Cabe destacar un cambio técnico significativo: el RFC 9989 desaconseja explícitamente el uso de «p=reject» para los flujos de correo indirectos, incluidas las listas de distribución y el reenvío; se recomienda a los destinatarios que traten esos casos como «p=quarantine» en lugar de rechazarlos directamente.

Ninguna de las aplicaciones actualmente en funcionamiento presenta fallos. Sin embargo, las organizaciones que mantienen «p=none» como postura permanente se encuentran expuestas en tres frentes: el riesgo de suplantación de identidad al que ya estaban sometidas, una norma con suficiente peso formal como para aparecer en los criterios regulatorios y en las evaluaciones de riesgo de los proveedores, y un mercado de seguros cibernéticos que distingue cada vez más entre la autenticación supervisada y la autenticación obligatoria.

Manténgase a la vanguardia con Mimecast

Mimecast está realizando un seguimiento minucioso de la adopción de la norma RFC 9989 y de las normas complementarias. Para las organizaciones que utilizan Mimecast DMARC Analyzer, la transición debería ser fluida. La plataforma ofrece una visibilidad continua que permite gestionar el estado de la autenticación de dominios a medida que evolucionan las normas y las expectativas en materia de cumplimiento. Como parte de una plataforma más amplia que presta servicio a más de 42 000 organizaciones en todo el mundo, Mimecast ayuda a los equipos de seguridad a adelantarse a los requisitos de cumplimiento normativo y de seguros que, en la actualidad, convergen en torno a la aplicación de DMARC.

¿Desea comprender qué implica la RFC 9989 para su implementación de DMARC y cómo podemos ayudarle? Concierte una demostración y hable con uno de nuestros expertos.

Fuentes: