Un registro DMARC sin dirección rua protege un dominio a ciegas: bloquea o deja pasar correo sin decir nunca quién lo envió. Los informes agregados DMARC (RUA) cubren ese vacío al listar, cada día, las direcciones IP que enviaron correo en nombre del dominio y el resultado de su autenticación SPF y DKIM. Desde mayo de 2026, su marco técnico ha cambiado: las RFC 9989, 9990 y 9991 sustituyen a la RFC 7489 de 2015 y hacen que DMARC pase del estado Informational al de Proposed Standard en el IETF.
Por qué los informes RUA siguen siendo imprescindibles
Un dominio que pasa a p=reject sin haber leído antes sus informes agregados corre el riesgo de bloquear sus propias campañas de marketing, sus herramientas de soporte o un proveedor olvidado. Los informes RUA ofrecen la lista completa de las fuentes de envío observadas por los grandes receptores (Gmail, Outlook, Yahoo) en un periodo dado, con el volumen de mensajes y el veredicto de alineación SPF y DKIM de cada una. Es la única fuente de datos que no depende de una declaración del propio dominio.
La guía sobre SPF, DKIM y DMARC detalla la implantación de estos tres mecanismos; esta guía se centra en el paso siguiente, demasiado a menudo ignorado: la explotación efectiva de los informes una vez configurada la dirección rua.
La estructura de un informe agregado
Un informe RUA es un documento XML enviado una vez al día por cada receptor que ha recibido correo del dominio. La RFC 9990 fija su estructura: una cabecera report_metadata que identifica a la organización emisora y el periodo cubierto, un bloque policy_published que recuerda la política DMARC leída en el DNS en el momento de la evaluación, y una serie de elementos record, uno por cada par fuente/resultado.
| Elemento | Contenido | Utilidad práctica |
|---|---|---|
report_metadata | Organización emisora, identificador de informe, periodo (date_range) | Deduplicar y fechar los informes recibidos |
policy_published | Política p, sp, np, modo de alineación | Verificar que el receptor leyó la política esperada |
row / source_ip | Dirección IP de origen y número de mensajes | Detectar remitentes desconocidos o no autorizados |
policy_evaluated | Disposición aplicada (none, quarantine, reject) y resultados SPF/DKIM | Medir el impacto real de una política más estricta |
identifiers / header_from | Dominio visible para el destinatario | Confirmar la alineación con el dominio evaluado |
Este es un extracto simplificado de lo que contiene un informe, para un único remitente:
<record>
<row>
<source_ip>203.0.113.45</source_ip>
<count>412</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>mail-studio.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>mail-studio.com</domain>
<selector>s1</selector>
<result>pass</result>
</dkim>
<spf>
<domain>sendgrid.net</domain>
<result>fail</result>
</spf>
</auth_results>
</record>
Este registro muestra un caso frecuente: el mensaje pasa DKIM (la firma del dominio es válida) pero falla SPF, porque el sobre de envío lleva el dominio del proveedor de envío en lugar del propio sitio. Como DMARC solo exige que al menos uno de los dos mecanismos pase y esté alineado, este mensaje sigue siendo conforme pese al fallo de SPF.
Qué cambia DMARCbis (RFC 9989 a 9991)
Los tres documentos publicados en mayo de 2026 reparten el protocolo en tres textos distintos: la RFC 9989 para el núcleo del protocolo (política, alineación, tratamiento de los registros), la RFC 9990 para los informes agregados, y la RFC 9991 para los informes de fallo. El cambio más visible para la lectura de los informes afecta al campo discovery_method del bloque policy_published: indica ahora si el dominio organizacional se determinó mediante la lista de sufijos públicos (PSL) o mediante un recorrido DNS ascendente, el «Tree Walk», que ya no depende de una lista externa mantenida manualmente.
La etiqueta pct, señalada como implementada de forma inconsistente entre receptores, desaparece de la RFC 9989 (véase su anexo dedicado a esa retirada). Dos etiquetas toman el relevo para usos más precisos:
| Etiqueta | Función | Estado |
|---|---|---|
pct | Porcentaje de mensajes sometidos a la política | Retirada de la RFC 9989 |
np | Política aplicada a subdominios inexistentes | Definida en la RFC 9989 |
psd | Señala un dominio de sufijo público | Definida en la RFC 9989 |
t | Modo de prueba de la política (y o n) | Definida en la RFC 9989 |
No es necesaria ninguna migración urgente: un registro DMARC existente sigue siendo válido, y la sintaxis conserva v=DMARC1. La acción concreta consiste en retirar pct de los registros que aún lo usen y verificar que la plataforma o el proveedor que procesa los informes agregados entiende las RFC 9989 a 9991.
Leer los informes sin plataforma de pago
Los receptores envían los informes comprimidos (gzip o zip) a la dirección declarada en rua. Para un dominio de tamaño modesto, un script que descomprime, analiza el XML y agrega por source_ip es más que suficiente: la mayoría de los lenguajes incluyen un analizador XML nativo, y la estructura descrita antes se presta bien a convertirse en una tabla. Lo esencial es agrupar por remitente en lugar de leer cada informe por separado, ya que el volumen diario puede alcanzar fácilmente varias decenas de archivos en un dominio activo.
Los informes RUA solo cubren lo que los receptores deciden declarar: no dicen nada sobre la ubicación final de un mensaje (bandeja de entrada, pestaña de promociones o carpeta de spam). Para ese nivel de detalle, hay que cruzar los informes agregados con una herramienta de reputación propia de cada receptor, como Google Postmaster Tools en el caso de Gmail, que expone un indicador de reputación de dominio e IP independiente del contenido de los informes DMARC. Las dos fuentes se complementan: DMARC dice quién envía y con qué resultado de autenticación, Postmaster Tools dice cómo se percibe ese correo ya autenticado.
Errores habituales de interpretación
Un fallo de SPF no siempre es un problema: en cuanto un mensaje pasa por una plataforma de envío externa (herramienta de marketing, herramienta de soporte), el sobre lleva el dominio del proveedor y SPF falla mecánicamente, sin que DKIM se vea afectado. También existe la trampa inversa: una fuente legítima que falla a la vez SPF y DKIM durante un periodo prolongado casi siempre indica una configuración incompleta por parte del proveedor, que conviene corregir antes de plantearse una política más estricta. La guía sobre el renderizado de correos HTML aborda otras diferencias entre lo que un remitente envía y lo que un cliente de correo muestra, con el mismo espíritu de verificar antes de diagnosticar.
Otro error habitual es confundir el volumen de mensajes con la gravedad de un problema. Una fuente desconocida que solo envía unos pocos mensajes al día merece ser identificada, pero no justifica retrasar el paso a p=quarantine si las fuentes mayoritarias están limpias. Por el contrario, una fuente que representa una parte importante del volumen total y falla sistemáticamente la alineación debe corregirse antes de cualquier cambio de política, bajo riesgo de bloquear una proporción significativa del correo legítimo del dominio. Los informes de fallo (RUF, ahora definidos por la RFC 9991) añaden detalle a nivel de mensaje a este diagnóstico, pero no todos los receptores los envían, y su contenido puede incluir partes del mensaje original: deben tratarse con las mismas precauciones de privacidad que cualquier otro dato de cabecera de correo.
Lo que hay que recordar
Los informes agregados DMARC siguen siendo la fuente de datos más fiable para saber quién envía correo en nombre de un dominio. DMARCbis no cambia radicalmente su lectura, pero aclara cómo se determina el dominio organizacional y retira una etiqueta ambigua en favor de ajustes más explícitos. Antes de cualquier paso hacia una política más estricta, el único método robusto sigue siendo observar los informes durante varias semanas, fuente por fuente.
He visto a más de un cliente pasar a p=reject solo por seguir un tutorial, sin haber abierto nunca un solo informe agregado, y perder por el camino los correos transaccionales de un proveedor olvidado desde hacía meses. Los informes RUA no son ni complicados ni costosos de explotar: la dificultad es casi siempre organizativa, no técnica — Simon Janvier.
Para saber más: el texto íntegro de la RFC 9990 detalla el esquema XML completo de los informes agregados DMARC.
