Los RFC 9989, 9990 y 9991 de DMARC sustituyen al RFC 7489
por
Última actualización: Tiempo de lectura: 7 minutos
Tras años de trabajo en el seno del grupo de trabajo DMARC de la IETF, se ha publicado la tan esperada actualización del estándar DMARC. Tres nuevos documentos, el RFC 9989, el RFC 9990 y el RFC 9991, sustituyen ahora oficialmente al RFC 7489 original de 2015. Aunque no se trata de un término oficial, estos RFC se conocían en la comunidad como «DMARCbis» y ahora se publican como la especificación DMARC actualizada con el mismo número de versión.
Las nuevas especificaciones se publicaron en mayo de 2026 y elevaron a DMARC de su anterior estatus de «Informational» a «Proposed Standard» en la vía de normalización de la IETF. Se trata de un avance significativo, ya que otorga a DMARC un lugar más sólido y formal dentro del conjunto de estándares de Internet.
Qué trata cada RFC
La especificación DMARC se ha dividido en tres documentos específicos, en lugar de un único archivo extenso. El RFC 9989 contiene el protocolo básico, que incluye la evaluación de políticas, las reglas de alineación y el procesamiento de registros. El RFC 9990 define el formato de informe agregado (RUA). El RFC 9991 trata sobre los informes de fallos, a menudo denominados informes forenses.
Tu registro DMARC actual sigue funcionando
Uno de los aspectos más importantes para los propietarios de dominios es que no se trata de un cambio que afecte a la compatibilidad. El identificador del protocolo sigue siendo el mismo, por lo que los registros siguen comenzando por «v=DMARC1». No es necesario que reconfigures tu sistema ni que vuelvas a publicar todos tus registros de la noche a la mañana.
Si quieres repasar cómo se estructuran los registros, nuestra guía sobre las etiquetas DMARC explica cada uno de los campos.
Principales cambios técnicos
Hay algunas novedades que llaman la atención, y vale la pena conocer un par de ellas en detalle antes de modificar tu registro.
La lista de sufijos públicos se ha sustituido por el recorrido del árbol DNS
Los receptores ya no dependen de la Lista de Sufijos Públicos, gestionada externamente, para determinar el dominio organizativo. En su lugar, recorren la jerarquía del DNS y buscan registros _dmarc en cada nivel. En la práctica, un receptor comienza por el dominio en cuestión y consulta etiquetas cada vez más altas, hasta un máximo de ocho búsquedas, hasta que encuentra un registro DMARC publicado. Esto elimina la dependencia de terceros y mejora la precisión en estructuras de dominio complejas.
Hay una implicación práctica que merece la pena señalar. Dado que Tree Walk resuelve el dominio organizativo de forma diferente al antiguo método de la Lista de Sufijos Públicos, un receptor que utilice la RFC 9989 puede, en algunos casos, obtener un dominio organizativo distinto al de un receptor que siga utilizando la RFC 7489. Si gestionas una jerarquía compleja de subdominios o utilizas dominios delegados, lo más seguro es publicar un registro DMARC explícito en cada dominio y subdominio desde el que realmente envíes correo electrónico. De este modo se elimina cualquier ambigüedad sobre qué política se aplica, independientemente de la versión que utilice un receptor concreto.
Nuevas etiquetas: np, psd y t
El RFC 9989 introduce tres nuevas etiquetas. A continuación se explica para qué sirve cada una y cuándo se utilizaría en la práctica.
np (política de subdominios inexistentes)
La etiqueta «sp» ya permite establecer una política para los subdominios, pero «np» va un paso más allá al separar la política para los subdominios que no existen en absoluto, es decir, aquellos para los que el DNS devuelve un error «NXDOMAIN». Esto subsana una brecha real en la suplantación de subdominios, ya que los atacantes suelen falsificar correos procedentes de subdominios que nunca se han registrado. Por ejemplo, un registro de v=DMARC1; p=none; np=reject; no aplicaría ninguna política al dominio raíz ni a sus subdominios auténticos, pero seguiría rechazando el correo procedente de subdominios inexistentes. Si tu dominio ya tiene configurado p=reject o sp=reject, la política estricta se hereda automáticamente, por lo que np=reject no aporta nada y no es necesario realizar ningún cambio. Si tienes una política menos estricta pero deseas una protección específica contra este ataque concreto, merece la pena añadir np=reject.
t (modo de prueba)
Esta es la etiqueta que más probabilidades tiene de interpretarse erróneamente. Establecer t=y no desactiva tu política. En cambio, solicita a los receptores que apliquen la política inmediatamente menos estricta que la que has publicado: una política de rechazo se trata como cuarentena, una política de cuarentena se trata como «ninguna», y la opción «ninguna» no se ve afectada. Esto es mucho más preciso que el antiguo comportamiento de pct al que sustituye efectivamente. Una advertencia importante: aún no todos los receptores son compatibles con el RFC 9989, por lo que algunos simplemente ignorarán «t=y». Durante el periodo de transición, lo más seguro es utilizar tanto «pct» como «t» juntos, para que tanto los receptores más antiguos como los más nuevos comprendan tu intención. Un registro por etapas podría tener el siguiente aspecto: v=DMARC1; p=reject; pct=50; t=y;. Puedes obtener más información sobre este cambio en nuestra nota anterior sobre por qué «t» sustituye a «pct».
psd (dominio de sufijo público)
Esta etiqueta ayuda a los receptores a determinar el dominio organizativo durante el recorrido del árbol DNS. La mayoría de los propietarios de dominios habituales deberían simplemente omitirla. Solo es relevante en dos situaciones: cuando una organización desea establecer deliberadamente un límite del dominio organizativo en un subdominio (en cuyo caso se debe establecer psd=n), o cuando se trata del operador de un dominio de sufijo público, como .bank o .gov (en cuyo caso se debe establecer psd=y). Hay que tener en cuenta que los receptores que aún utilicen el RFC 7489 ignorarán por completo esta etiqueta, por lo que no sustituye a un diseño adecuado de los registros.
Se han eliminado tres etiquetas: pct, rf y ri
La RFC 9989 retira tres etiquetas. Ninguna de estas eliminaciones afectará a ningún registro existente, pero conviene comprender qué función tenía cada etiqueta y qué hay que hacer al respecto. Consulte la sección dedicada a este tema más abajo.
Orientaciones más claras sobre las listas de correo y el reenvío de mensajes
Los flujos de correo indirectos siguen rompiendo la alineación entre SPF y DKIM, y la nueva especificación lo reconoce abiertamente. Desaconseja las políticas agresivas de «p=reject» en los casos en los que es habitual el tráfico de listas de correo, lo que refleja el comportamiento real del correo electrónico en el mundo real.
Conformidad mejor definida
El nuevo texto detalla qué significa la «participación plena en DMARC» tanto para los remitentes como para los destinatarios, lo que debería reducir las implementaciones irregulares que han supuesto un problema durante años.
Se ha eliminado el límite de tamaño de los URI de los informes
Un cambio menor que pasa fácilmente desapercibido: la RFC 9989 ha eliminado la posibilidad de especificar un tamaño máximo para los informes en la URI de informe. Los registros que utilizaban un sufijo de tamaño, como rua=mailto:[email protected]!10m, ya no tienen sentido, y los destinatarios deben ignorar ahora cualquier límite de tamaño asociado a una dirección rua o ruf. Si tus URI de informe incluyen esta sintaxis, puedes eliminar sin problema la parte correspondiente al límite de tamaño.
Explicación de las etiquetas eliminadas
Si tu registro actual utiliza «pct», «rf» o «ri», a continuación te explicamos exactamente qué función tenía cada uno y qué debes hacer ahora.
pct (porcentaje)
Esta etiqueta se diseñó para permitirte implementar una política de forma gradual, aplicándola a un porcentaje determinado del correo. En la práctica, se implementó de forma inconsistente entre los distintos receptores, lo que generó resultados impredecibles, por lo que ha sido sustituida por la etiqueta «t», más clara. Si sigues utilizando «pct», no te bases únicamente en ella de ahora en adelante. Durante la transición, lo más sensato es utilizar «pct» y «t=y» conjuntamente, de modo que tanto los receptores antiguos como los que cumplen con el RFC 9989 entiendan que estás preparando la aplicación de la política.
rf (formato de informe)
Esta etiqueta especificaba el formato de los informes de fallos, pero el único valor válido que se ha utilizado nunca ha sido «afrf», lo que hacía que, en la práctica, la etiqueta resultara redundante. Se puede eliminar sin problema de cualquier registro en el que aparezca.
ri (intervalo de notificación)
Esta etiqueta definía el intervalo solicitado entre informes agregados, en segundos. La mayoría de los receptores la ignoraban y, sencillamente, utilizaban por defecto un informe diario; ahora, el RFC 9989 formaliza esta práctica al exigir a los receptores que envíen informes agregados al menos una vez al día. No supone ningún problema dejar esta etiqueta tal cual, pero cada vez es menos relevante y no se debe confiar en ella.
¿Cómo actualizar el registro DMARC según el RFC 9989?
La publicación del RFC 9989 no afecta a nada de lo que ya tengas. Tu registro sigue estando en el mismo sitio —un registro TXT de DNS en _dmarc.tudominio.com— y la etiqueta de versión sigue siendo v=DMARC1.
Entonces, ¿por qué actualizar? Porque el RFC 9989 refleja cómo funciona realmente el correo electrónico tras una década de implementación en el mundo real, y merece la pena incorporar ahora mismo algunos de sus cambios a tu registro, en lugar de descubrirlo más adelante.
Esto es lo que deben hacer los titulares de dominios
Los propietarios de dominios pueden seguir la lista de comprobación que figura a continuación para actualizar sus registros de forma dinámica:
- Elimina las etiquetas «rf» y «ri». Ambas están obsoletas y se pueden eliminar sin problema.
- Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
- Considera la posibilidad de añadir «np=reject» si deseas bloquear la suplantación de identidad procedente de subdominios inexistentes sin modificar tu política principal.
- Elimina el sufijo de límite de tamaño del URI de informe si tus registros rua o ruf incluyen uno.
- Omite «psd» a menos que necesites declarar expresamente un límite de dominio organizativo o que administres un dominio con sufijo público.
- Publica registros DMARC explícitos para cada dominio y subdominio desde el que envíes correo electrónico, con el fin de evitar cualquier ambigüedad en el recorrido del árbol DNS entre los receptores que siguen las especificaciones de los RFC 9989 y RFC 7489.
Si quieres conocer con más detalle los cambios y saber cómo preparar tus registros, consulta nuestra guía completa sobre DMARCbis.
Un registro actualizado según la norma RFC 9989 tiene el siguiente aspecto:
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s
Fíjate en lo que falta: no aparece el porcentaje. Para implementarlo de forma segura, añade «t=y», deja que se acumulen los informes agregados y, a continuación, elimínalo cuando estés listo para su aplicación plena.
También notarás que en este registro faltan dos etiquetas válidas según la norma RFC 9989 —«t» y «psd»—; esto es intencionado, ya que ambas se utilizan en casos concretos y no son estándar.
La etiqueta «t» indica el modo de prueba temporal: solo se añade durante la fase de transición hacia la aplicación de la política, ya que indica a los receptores que apliquen la política inmediatamente inferior a la que has publicado. Por su parte, la etiqueta «psd» es un indicador que declara que un dominio es un sufijo público. Los operadores de sufijos públicos deben establecer «psd=y», pero para el propietario de un dominio normal, el valor por defecto (u) es el adecuado, por lo que basta con omitir la etiqueta.
Asegúrate de que tu plataforma DMARC esté lista
No todas las herramientas del mercado se han adaptado aún a los nuevos estándares, y esa diferencia es importante. Si tu plataforma no puede leer las nuevas etiquetas ni procesar los informes en el formato actualizado, pierdes visibilidad justo cuando el protocolo está evolucionando.
PowerDMARC ya cumple con las nuevas especificaciones y es compatible con:
- Generación de registros compatibles con RFC 9989, 9990 y 9991
- Análisis sintáctico de las nuevas etiquetas np, psd y t
- Ingesta y generación de informes según el RFC 9990
- Gestión de dominios organizativos basada en el recorrido del árbol DNS
- Comportamiento de procesamiento actualizado que refleja las nuevas normas de conformidad
Si quieres saber cómo se compara tu registro actual con el nuevo estándar, pruébalo con nuestro verificador DMARC gratuito y comprueba qué aspectos hay que corregir.
Palabras finales
Las RFC actualizadas no constituyen un nuevo protocolo. Se trata del mismo DMARC, redactado con mayor claridad y elevado a la categoría de norma. Tras más de una década de implementación en el mundo real, la especificación refleja ahora cómo funciona realmente el correo electrónico, incluidas sus partes más complejas, como el reenvío y las listas de correo.
Para cualquier persona responsable de la seguridad de los dominios, la publicación de los RFC 9989, 9990 y 9991 es un buen motivo para auditar sus registros y asegurarse de que sus herramientas estén preparadas para las nuevas etiquetas y el enfoque «DNS Tree Walk».
Experto en seguridad de dominios y correo electrónico de PowerDMARC
Ahona es la Directora de Marketing de PowerDMARC, con más de 5 años de experiencia escribiendo sobre temas de ciberseguridad, especializada en seguridad de dominios y correo electrónico. Ahona tiene un posgrado en Periodismo y Comunicaciones, consolidando su carrera en el sector de la seguridad desde 2019.
Últimas publicaciones de Ahona Rudra (ver todas)
- Seguridad del correo electrónico y de las nóminas en RR. HH.: buenas prácticas para equipos internacionales - 22 de junio de 2026
- Cómo bloquear agentes de IA de alto riesgo en Microsoft Entra - 15 de junio de 2026
- Política antiphishing de Office 365: cómo configurarla - 3 de junio de 2026
