DMARC tiene su primer estándar formal en 11 años: qué cambia con el RFC 9989

El DMARC que usas para proteger tu cold email acaba de cambiar de estatus: el IETF ha publicado el RFC 9989, su primera revisión formal en once años, y sustituye al RFC 7489 de 2015. Si envías correo B2B en volumen, hay tags que conviene retirar de tu registro DNS y un nuevo requisito de verificación que puede dejar sin entregar tus reportes agregados.

Qué ha pasado

El grupo de trabajo DMARC del IETF publicó en mayo de 2026 tres RFC que en conjunto se conocen como DMARCbis: el RFC 9989 recoge el protocolo central, el RFC 9990 cubre los informes agregados y el RFC 9991 los informes de fallo. Entre los tres sustituyen al RFC 7489, el documento que había definido DMARC desde 2015, y absorben también el RFC 9091, centrado en dominios PSD.

El cambio más relevante es de categoría: DMARC pasa de ser un RFC Informational a un Proposed Standard, es decir, entra de lleno en el Standards Track del IETF. La documentación del propio RFC lo explica así: "las implementaciones ya pueden declarar conformidad con un RFC de la vía de estándares en lugar de uno informativo". Ese respaldo formal es nuevo.

A nivel técnico, el RFC 9989 aclara varios puntos que durante una década generaron interpretaciones distintas entre proveedores de buzón: cómo se hereda la política DMARC entre un dominio organizativo y sus subdominios, cómo determinar exactamente cuál es ese dominio organizativo, y cómo evaluar la alineación con SPF y DKIM en escenarios de reenvío o listas de correo. El RFC 9990, por su parte, introduce un cambio operativo concreto: cualquier dominio externo que vaya a recibir tus informes agregados (la dirección que pones en el tag rua=) debe publicar ahora un registro TXT de verificación, algo que antes no era obligatorio.

El documento también retira tags que llevaban tiempo en desuso, como pct=, rf= o ri=, y añade tres nuevos: np=, psd= y t=, pensados para casos de uso más específicos como dominios "no postales" o de tipo PSD.

Por qué importa

DMARC lleva años siendo, junto a SPF y DKIM, uno de los tres pilares que Gmail, Yahoo y Microsoft revisan antes de decidir si un correo entra en la bandeja o se queda fuera. Cuando una especificación que lleva once años sin tocarse cambia de estatus y aclara sus zonas grises, los proveedores de buzón y las herramientas de auditoría suelen alinear sus comprobaciones con esa letra nueva en pocos meses.

Esto importa especialmente para quien envía cold email B2B desde varios subdominios o desde proveedores de envío externos, porque la herencia de políticas entre dominio organizativo y subdominios era justo uno de los puntos donde el RFC 7489 dejaba más margen de interpretación. El propio análisis del cambio lo resume con una frase que conviene tomarse en serio: configuraciones que "funcionaban" por una aplicación inconsistente del estándar antiguo pueden empezar a fallar bajo las reglas más estrictas del nuevo.

Qué significa para tu agencia o equipo de ventas

Si gestionas dominios de envío para cold email, repasa el registro DMARC de cada dominio y subdominio que uses para outbound. Confirma tres cosas: que no quedan tags obsoletos como pct= colgando del registro, que la dirección de rua= apunta a un dominio que ya publica el TXT de verificación que exige el RFC 9990, y cómo se hereda tu política hacia los subdominios que usas para warm-up o para separar marcas.

Esto conecta directamente con dos cambios que ya cubrimos antes en este espacio: la nueva guía de seguridad DNS de NIST, que recordaba que SPF, DKIM y DMARC viven en el DNS y dependen de su seguridad, y los requisitos de autenticación que Microsoft ya aplica en Outlook y Hotmail a partir de cierto volumen de envío, descritos en qué cambia para tu envío B2B en Outlook. El RFC 9989 no añade un requisito nuevo de volumen, pero sí formaliza las reglas que esos proveedores ya vienen aplicando de facto.

"Implementations can now declare compliance with a Standards-Track RFC rather than an Informational one", según el análisis del cambio de estatus de DMARC publicado por DMARCguard.

En resumen

DMARC deja de ser, en la práctica, un estándar de facto sostenido por el consenso de la industria y pasa a tener el respaldo formal que le faltaba desde 2015. Para quien hace cold email B2B, el RFC 9989 no obliga a reescribir nada de cero, pero sí marca un buen momento para auditar el registro DMARC de cada dominio de envío antes de que un proveedor de buzón empiece a aplicar la letra nueva del estándar con más rigor que la antigua. Si quieres que alguien revise esto por ti mientras te concentras en vender, agenda una llamada.

Fuentes

• Next generation DMARC: what's changing and why it matters (Proofpoint)
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (RFC Editor)
• DMARCbis Is Published: RFC 9989, 9990, 9991 Replace 7489 (DMARCguard)