El RFC 9989 convirtió DMARC en un estándar de internet de verdad en mayo de 2026 y por el camino borró tres etiquetas: pct, ri y rf. De los 173 registros DMARC vivos que resolvimos desde dominios remitentes reales el 15 de agosto de 2026, 79 siguen publicando al menos una. Casi ninguno de esos dominios lo notará, porque 66 de los 68 registros que llevan pct lo fijan en 100, que no hacía nada antes y no hace nada ahora.
La excepción es el registro que un remitente cuidadoso tiene más probabilidades de haber publicado. Una política quarantine o reject con un pct por debajo de 100 era una rampa deliberada que aplicaba la exigencia a una parte del correo que fallaba. Esa parte desaparece en cualquier receptor que siga el estándar actual, y el registro se endureció sin que nadie editara el DNS.
Esta guía cubre cada cambio del RFC 9989 que llega a un registro publicado, con los números de sección para comprobar cada uno.
El RFC 9989 sustituyó tres documentos, no uno
El RFC 9989 deja obsoletos el RFC 7489 y el RFC 9091, y está en la vía de estándares en lugar de ser informativo. Ese cambio de estado es lo sustancial: DMARC pasó ocho años como documento informativo que describía lo que hacía un despliegue existente, y ahora es una especificación a la que se espera que los receptores se ajusten.
Dos documentos complementarios separaron la mitad de los informes, y ambos dejan obsoleto también el RFC 7489. El RFC 9990 cubre los informes agregados, los que llegan en XML a tu dirección rua. El RFC 9991 cubre los informes de fallo, los de mensaje a mensaje en ruf. El RFC 9091 era la extensión experimental para dominios de sufijo público, y su etiqueta psd sobrevive en la especificación principal.
Una página que en 2026 cite el RFC 7489 para cualquier cosa de DMARC está citando un documento al que han sustituido tres RFC distintos. Eso incluye a casi toda la documentación de proveedores, y también a las guías para remitentes de Google y Microsoft, que siguen describiendo DMARC en términos del RFC 7489.
Tres etiquetas están registradas como historic, que no es lo mismo que desconocidas
El RFC 9989 creó un registro IANA de etiquetas DMARC y registró pct, ri y rf con estado historic. El RFC define ese estado con sus propias palabras: la etiqueta "is considered deprecated and is not expected to be in use in any current implementation".
| Etiqueta | Qué hacía | Estado ahora |
|---|---|---|
pct | Tasa de muestreo, la parte del correo fallido a la que se aplicaba la política | Historic |
ri | Intervalo de informes agregados, en segundos | Historic |
rf | Formato de los informes de fallo | Historic |
Historic es un estado distinto de desconocida, y un verificador tiene que tratarlo como tal. Estas tres tienen nombre, una historia documentada y, en el caso de pct, un motivo declarado para irse. Una etiqueta desconocida es algo que nadie ha definido. Las dos las ignora un receptor conforme, y ninguna puede invalidar un registro, pero solo una merece que se le cuente al que publica por su nombre.
Lo que hace un receptor con cualquiera de ellas queda zanjado en la sección 4.8: "Unknown tags MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values (if any) or ignored outright". Así que pct=abc y pct=50 son igual de inertes en un receptor RFC 9989, y un verificador que ponga en rojo un registro por cualquiera de los dos informa de un fallo sobre el que ningún receptor actúa.
Solo uno de los tres borrados cambia lo que le pasa a tu correo
pct es la etiqueta cuya retirada movió correo vivo, y lo movió hacia el lado estricto. Con el RFC 7489, p=reject; pct=25 pedía a los receptores que rechazaran una cuarta parte de los mensajes fallidos y aplicaran al resto la política de un nivel por debajo. En un receptor RFC 9989 la etiqueta se ignora y p=reject se aplica a todos los mensajes que fallan.
Nadie editó el DNS para que eso pasara. El registro es idéntico y el resultado no, que es lo contrario de lo que suele sentirse una retirada.
Los dos comportamientos están vivos a la vez, y esa es la parte que conviene planificar. Google y Microsoft no se han comprometido con la semántica del RFC 9989 y su documentación para remitentes sigue describiendo el muestreo, así que el mismo registro puede quedar muestreado en un receptor y aplicado por completo en otro el mismo día.
Eso también fija el orden de las operaciones para arreglarlo. Borrar un pct por debajo de 100 sube la exigencia en todos los receptores que todavía lo respetan, así que la secuencia segura es llegar primero al nivel de exigencia que de verdad quieres y borrar la etiqueta después. Hacerlo al revés es un salto de exigencia disfrazado de limpieza.
ri y rf son más silenciosas. ri pedía un intervalo de informes en segundos, y los receptores enviaban informes diarios de forma abrumadora dijera lo que dijera. rf nombraba un formato de informe de fallo, y afrf era el único valor que publicaba alguien. Quitar cualquiera de las dos no cambia nada de tu correo.
La etiqueta p ya no es obligatoria, y con ella se van dos costumbres
El RFC 9989 lista p como "RECOMMENDED for DMARC Policy Records" en lugar de obligatoria, y la gramática formal solo nombra la etiqueta de versión como imprescindible. Un registro sin p no es un error de sintaxis.
Dos reglas que los verificadores antiguos imponen se han ido con ella, y las dos rechazan registros que todos los receptores aceptan:
- El orden de las etiquetas después de
vno está restringido. El RFC 7489 fijabapen segundo lugar, y la documentación de Google para quien publica todavía lo dice. El RFC 9989 no. - Los valores de las etiquetas no distinguen mayúsculas. Son literales ABNF simples, así que
p=Rejectes válido.
Un p ausente sigue mereciendo un aviso, porque un registro sin política es una consecuencia real para el dominio. Simplemente no es un error de sintaxis, y la diferencia decide qué se le dice al lector que haga.
Un registro se descarta por exactamente dos motivos, y son estados distintos
Tres estados de fallo tienen que mantenerse separados, porque juntarlos es como un verificador le dice a un dominio desprotegido que solo tiene una errata. Esta es la parte que casi ninguna explicación cubre, y es la que decide si una herramienta acierta.
La etiqueta de versión está mal. Ausente, no primera, o no exactamente DMARC1 respetando mayúsculas. Sección 4.7: "the entire record MUST be ignored". El descubrimiento de política continúa más allá, así que el nombre todavía puede quedar cubierto por un registro más arriba en el árbol.
La política es inservible. p ausente o no reconocido, o un sp o np presente e inválido. La sección 4.10.1 mete los tres en una sola rama, y el resultado depende de rua: con al menos una URI de informes sintácticamente válida "the Mail Receiver MUST act as if a record containing p=none was retrieved", y sin ella el receptor no aplica ningún procesamiento DMARC al mensaje. Ese segundo resultado es peor que p=none y peor que no publicar nada.
Todo lo demás se repara sobre la marcha. Sección 4.8 otra vez: un fo malo, un t malo, una etiqueta historic, una etiqueta desconocida. Ninguna de ellas puede invalidar un registro.
La cláusula que se pasa por alto está en el segundo punto. Una errata en sp descarta entero un p=reject perfectamente bueno. v=DMARC1; p=reject; sp=quarintine no protege nada, y un verificador que informe del p que sí puede leer le entrega una insignia verde a un dominio abierto. Si publicas sp o np, cargan un peso que p por sí solo no tiene, y la política de subdominios es donde más se nota.
Qué publican de verdad 173 registros DMARC vivos
Mantenemos un corpus de registros DMARC publicados por dominios remitentes reales, resueltos desde dns.google por DoH, como control de falsos positivos de nuestro propio analizador: cada registro que hay ahí lleva correo real, así que cualquier fallo que nuestro analizador levante contra uno está equivocado hasta que se demuestre lo contrario. Así se veían las etiquetas el 15 de agosto de 2026.
| Etiqueta | Registros que la llevan | Porcentaje |
|---|---|---|
| Al menos una etiqueta historic | 79 | 46% |
pct | 68 | 39% |
pct fijado en 100 | 66 | 38% |
pct por debajo de 100 | 2 | 1% |
ri | 16 | 9% |
rf | 11 | 6% |
| Las tres etiquetas historic | 1 | menos del 1% |
Destacan dos cosas, y la segunda explica por qué la primera importa poco. Casi la mitad del corpus lleva una etiqueta borrada, lo que suena alarmante hasta que miras los valores: 66 de las 68 etiquetas pct están fijadas en 100, un valor que aplicaba la política a todo antes del RFC 9989 y la aplica a todo ahora. Los valores de ri son 3600, 14400 y 86400 segundos, y absolutamente todos los valores de rf son afrf.
La exposición es un registro de 173: un p=reject; pct=25 que pedía una cuarta parte y ahora se lleva todo. Ese es el riesgo práctico completo de este borrado, y está concentrado en los remitentes que estaban siendo cuidadosos.
Este corpus es un conjunto de dominios que seguimos, no una muestra aleatoria de internet, así que lee los porcentajes como el aspecto de registros publicados reales y no como una medición de todos los dominios. Para la cifra de población, el 48% publica una política DMARC en el Unspam 2026 Email Deliverability Benchmark.
Los destinos de informes en otro dominio ahora tienen que consentir
La sección 4 del RFC 9990 obliga al receptor a verificar que un destino externo de informes ha aceptado recibir los tuyos, y a descartar cualquier URI que no pueda confirmar. La sección 5 del RFC 9991 lo repite para ruf. El RFC 7489 decía que esas comprobaciones "are to be taken"; el texto nuevo lo convierte en un MUST y elimina la salida que permitía al receptor saltarse la comprobación a favor de una lista propia.
En la práctica esto significa que un rua que apunte al dominio de un proveedor necesita un registro en la zona de ese proveedor que autorice a tu dominio a enviar ahí. La mayoría de los proveedores de informes lo publican automáticamente cuando añades un dominio, así que suele ser un dato sobre una configuración que no hiciste tú y no un cambio en una que sí.
Hay una trampa aparte en la misma etiqueta que es anterior al RFC 9989 y sigue pillando a gente. La gramática del registro usa dos separadores distintos: los punto y coma separan etiquetas, las comas separan URI dentro de una etiqueta. Así que rua=mailto:a@example.com; mailto:b@example.net no es una lista de dos direcciones. Es una etiqueta rua seguida de un término suelto que no es tag=value, y la segunda dirección no recibe nada. Un verificador construido con expresiones regulares por etiqueta no puede ver eso, porque cada expresión solo pregunta si su propia etiqueta aparece en algún sitio.
BIMI sigue citando el RFC 7489, y hace bien
La especificación de BIMI discrepa del RFC 9989 sobre pct a propósito, y las dos afirmaciones están vigentes. El RFC 9989 hizo historic la etiqueta en mayo de 2026. El borrador de BIMI publicado ese mismo mes sigue citando el RFC 7489, y su sección 7.1 sigue bloqueando un logotipo cuando un registro p=quarantine lleva un pct que no es 100.
Así que un dominio puede tener un registro perfectamente moderno bajo el RFC 9989 y aun así fallar la comprobación de BIMI por una etiqueta que DMARC ya no tiene. Cualquier cosa sobre BIMI se cita a una revisión de borrador y nunca a un RFC, porque no hay RFC de BIMI: la revisión actual es draft-brand-indicators-for-message-identification-14, del 1 de mayo de 2026.
Este es el tipo de detalle que se aplana cuando una herramienta comparte un solo analizador DMARC entre funciones. El camino de BIMI necesita su propia comprobación de pct que sobreviva a un analizador con forma de RFC 9989 tirando la etiqueta al suelo.
Qué hacer con tu registro esta semana
Lee tu registro antes de cambiarlo, porque tres de estas comprobaciones dependen de valores que quizá no recuerdes haber publicado. Nuestro verificador de registros DMARC analiza según la gramática del RFC 9989 y ordena las etiquetas en activas, historic y desconocidas, así que una etiqueta borrada se informa como aviso y no como error.
- Busca un
pctpor debajo de 100. Si encuentras uno y tu política esquarantineoreject, tu registro ya es más estricto de lo que crees en algunos receptores. Decide el nivel de exigencia que quieres, llega ahí y borra la etiqueta después. - Revisa
spynpcarácter a carácter. Una errata en cualquiera descarta el registro entero. Si no necesitas una política distinta para subdominios, no publicarlas es más seguro que publicarlas de forma aproximada. - Borra
riyrfcuando te venga bien. Son inertes y siempre estuvieron cerca de serlo. - Confirma que tu
ruausa comas entre direcciones, no punto y coma, si lista más de una. - Deja en paz un
pct=100salvo que ya estés editando. Es ruido, no un fallo.
Si estás construyendo un registro desde cero en lugar de auditar uno, el generador de registros DMARC produce sintaxis actual, y qué hace DMARC cubre el mecanismo que hay detrás de las etiquetas.
Una etiqueta que nadie respeta no es un registro roto
El error más común en los artículos sobre este cambio es tratar una etiqueta historic como un error. No lo es, y la sección 4.8 es inequívoca sobre el porqué: un receptor ignora lo que no reconoce y repara lo que no puede analizar, en lugar de tirar el registro. Una herramienta que pone en rojo un registro por pct manda a su usuario a editar un DNS que funciona, que es peor que no decir nada.
El único sitio donde un aviso se gana su puesto es el caso estrecho de arriba, y se lo gana por ser una afirmación sobre tu correo y no sobre tu sintaxis: un pct por debajo de 100 en exigencia significa que tu política ahora se aplica a mensajes que antes perdonaba. Todo lo demás de este borrado es tarea de mantenimiento.
Pasa tu dominio por el verificador de registros DMARC y luego envía un mensaje de prueba para ver si la política que publicas coincide con el sitio donde acaba tu correo.
