¿Tu registro TXT _dmarc todavía contiene una etiqueta pct=50? Ya no sirve para nada desde el 20 de mayo de 2026. Ese día, la IETF publicó DMARCbis en forma de tres RFC: la 9989 para la base del protocolo, acompañada de la 9990 y la 9991 para los informes, que sustituyen oficialmente a la RFC 7489 de 2015 (dmarc.org, mayo de 2026). La etiqueta pct desaparece, llegan dos tags nuevos y la forma de descubrir el dominio organizacional cambia de mecanismo. Perder un 30 % de entregas en tres meses sin cambiar el contenido, con un SaaS de email marketing que sigue mostrando un estado en verde, a veces se debe a una configuración DNS que nunca se revisó, no al contenido de las campañas. Para los fundamentos del protocolo, sobre todo lo que no cubre, DMARC: 5 cosas que no puede hacer sigue siendo la referencia. Aquí se trata del cambio en sí y de lo que hay que corregir antes de que los grandes receptores (Google, Microsoft, Yahoo) alineen sus parsers con él.
¿Qué cambia realmente DMARCbis respecto a la RFC 7489?
La RFC 7489 tenía el estatus «Informational» desde su publicación en 2015: DMARC nunca llegó a convertirse en un estándar de Internet en el sentido estricto de la IETF. La RFC 9989 corrige este punto. El protocolo pasa a Proposed Standard, el primer escalón normativo de la IETF, y deja obsoletas tanto la RFC 7489 como la RFC 9091, la extensión PSD DMARC que se quedó en fase experimental. La RFC 9990 regula ahora los informes agregados XML; la RFC 9991 cubre los informes de fallo mensaje por mensaje. Todo esto procede del borrador draft-ietf-dmarc-dmarcbis-41, publicado el 4 de abril de 2025 tras un trabajo iniciado en 2019, poco después de la finalización del protocolo ARC.
Hay un punto que tranquiliza a los administradores con prisa. El valor v=DMARC1 no cambia. Un registro publicado en 2019 sigue respondiendo en 2026, sin interrupción de servicio el día del cambio.
Las etiquetas que DMARCbis elimina
Tres etiquetas salen de la especificación, con pct a la cabeza. Se suponía que aplicaba la política a un porcentaje del tráfico, pero arrastraba un defecto documentado desde hace años: en la práctica, solo los valores 0 y 100 se aplicaban de forma fiable, mientras que los valores intermedios generaban comportamientos incoherentes de un receptor a otro (dmarcian, 2025). Se sustituye por una etiqueta binaria, t, con solo dos valores: t=y para el modo de prueba, equivalente al antiguo pct=0, y t=n para la aplicación completa, equivalente a pct=100. Junto con ella desaparecen rf, el formato de los informes agregados, y ri, el intervalo entre informes, trasladados a los documentos de reporting RFC 9990 y RFC 9991. Un registro que todavía contenga alguna de estas tres etiquetas sigue funcionando; simplemente queda obsoleto.
Las etiquetas que DMARCbis añade
La etiqueta np apunta a un punto ciego real de la RFC 7489: los subdominios que no existen en el DNS. Hasta ahora, un atacante podía enviar desde fake.pago.ejemplo.com sin que se aplicara ninguna política DMARC, porque el subdominio simplemente no tenía ningún registro que consultar (dmarcian, 2025). Con np=reject o np=quarantine, el propietario del dominio cierra esa puerta sin tener que endurecer el resto de su tráfico legítimo. Junto a ella, la etiqueta psd retoma el contenido de la antigua RFC 9091: marca un dominio como sufijo público (psd=y), una información que alimenta el mecanismo de descubrimiento descrito más abajo. Un dominio que busque aparecer con BIMI en Gmail tendrá que pasar de todos modos por p=quarantine o p=reject: la aclaración que aporta np no cambia en nada ese requisito, que ya existía.
El descubrimiento por árbol DNS sustituye a la Public Suffix List
Toma mail.marketing.ejemplo.com. Con la RFC 7489, determinar el dominio organizacional de esa dirección dependía de la Public Suffix List, una lista mantenida manualmente por Mozilla, actualizada fuera de banda y nunca formalmente estandarizada. Un registro olvidado o un nuevo TLD ausente de la lista producía un falso negativo silencioso. La RFC 9989 sustituye este mecanismo por un DNS Tree Walk: el receptor consulta sucesivamente mail.marketing.ejemplo.com, luego marketing.ejemplo.com, luego ejemplo.com, luego el TLD, deteniéndose en cuanto encuentra un registro con psd=n (dominio organizacional) o psd=y (sufijo público). El algoritmo está limitado a 8 consultas DNS, una cifra fijada en la sección 4.10 de la propia RFC. Los informes agregados de la RFC 9990 añaden dos campos que antes no existían: discovery_method y testing, que indican cómo se encontró la política y si el dominio funciona en modo t=y. Un administrador que leía sus informes XML sin revisar nunca estos dos campos tendrá que incorporarlos a su panel de control.
El impacto en la alineación de SPF y DKIM
La alineación sigue funcionando con la misma mecánica: comparar el dominio autenticado por SPF o DKIM con el dominio organizacional del dominio From. Lo que cambia es el cálculo de ese dominio organizacional, que ya no procede de una lista externa sino de una resolución DNS determinista. En un dominio con un esquema clásico, del tipo ejemplo.com sin subniveles exóticos, nada cambia. En una estructura DNS profunda, con varios niveles de subdominios gestionados por entidades distintas, el resultado del tree walk puede diferir de lo que daba la PSL, sobre todo cuando un nivel intermedio publica ahora un registro psd. La RFC 9989 también aclara un punto que ya era cierto en la práctica pero que rara vez se escribía con todas las letras: la alineación SPF solo se aplica a la identidad MAIL FROM del comando SMTP, nunca a la identidad HELO. Un dominio que confiaba en una alineación HELO en realidad nunca estuvo cubierto; la aclaración no hace más que dejarlo explícito. En cuanto a los puntos de fricción estructurales del propio protocolo SPF, el límite de las 10 búsquedas DNS y las consecuencias de un SPF ausente siguen vigentes: DMARCbis no los elimina.
Queda un límite. Pasadas ocho consultas DNS, el tree walk no resuelve nada. La RFC fija este tope para evitar bucles y ataques de amplificación, pero una arquitectura con delegación profunda, un proveedor DNS apilado sobre otro proveedor, puede toparse con él antes incluso de llegar al dominio organizacional real.
¿Qué etiquetas DNS TXT _dmarc corregir antes del cambio?
La documentación de la IETF no precisa en qué plazo los grandes receptores (Google, Microsoft, Yahoo) migrarán sus parsers de recepción a DMARCbis. Las tres RFC ya están publicadas; la adopción por parte de los receptores sigue siendo progresiva y sin calendario fijo por ahora. Corregir el registro ahora evita quedarse rezagado el día en que uno de los tres cambie su lectura por defecto.
- Eliminar cualquier etiqueta pct= del registro TXT _dmarc, sea cual sea su valor actual.
- Eliminar rf= y ri= si están presentes, dos parámetros que un receptor conforme a la RFC 9989 ya no lee.
- Añadir np=quarantine o np=reject en cuanto la política principal, p=, ya esté aplicada, para cerrar la puerta a los subdominios inexistentes.
- Revisar la estructura de los subdominios gestionados por proveedores externos, registro, filial, marca secundaria, y evaluar si hay que publicar una etiqueta psd=y o psd=n en un nivel intermedio.
- Documentar el modo t= elegido, t=y en prueba o t=n en aplicación, en lugar de dejar que un valor pct heredado sirva de referencia.
Ninguna de estas correcciones exige anular ni reconfigurar un registro SPF o DKIM existente. El trabajo se limita al campo DMARC, aunque toque la misma zona DNS que los registros CNAME ya presentes para otros usos.
«Los cambios y mejoras conocidos como DMARCbis ya son oficiales: el protocolo pasa a la vía normativa de la IETF» (dmarc.org, mayo de 2026).
Lo que el cambio supone para la reputación de envío
Limpiar el registro DMARC solo resuelve una parte del problema. Un dominio perfectamente alineado que envía a una lista deteriorada sigue generando rechazos, pero por otro motivo: la tasa de hard bounce sube, la reputación del remitente se deteriora ante el postmaster de Gmail, y un DMARC reject en un dominio por lo demás limpio acaba interpretándose como señal de spam en vez de como una anomalía puntual. Es la objeción habitual: verificar una lista antes del envío tiene un coste, así que mejor filtrar después. Pero un rechazo DMARC posterior a la autenticación no se recupera en el filtrado como un soft bounce normal: daña la reputación de la IP antes incluso de que ese filtrado tenga lugar. Los feedback loops de los ISP y la tasa de quejas suelen dispararse antes de que el SNDS de Microsoft señale nada anormal. Un cambio a DMARCbis mal preparado, combinado con una lista que nunca se ha limpiado, acumula las dos causas de rechazo en lugar de aislar una sola. Para saber por qué aumentan los rechazos SMTP y cómo reducirlos, el tema conecta directamente con el del registro DNS tratado aquí. La única forma de saber cuál de las dos causas pesa más es pasar la lista por un filtro antes de la próxima campaña, por separado del trabajo sobre el registro DNS.
Los protocolos se actualizan solos. Los registros DNS, nunca.
