Cómo leer un informe agregado DMARC (rua) y qué hacer con él

Un informe agregado DMARC es un resumen diario que los grandes proveedores de correo envían a la dirección indicada en la etiqueta rua de su registro DMARC. Enumera cada dirección IP que envió correo usando su dominio en el campo From, cuántos mensajes envió cada una y si SPF y DKIM se superaron y estaban alineados con su dominio. No incluye el contenido de los mensajes, los asuntos ni las direcciones de los destinatarios.

Leer estos informes es la forma de averiguar quién envía realmente en su nombre: sus propios servidores de correo, el CRM, la herramienta de facturación, la plataforma de newsletters y cualquier otro que simplemente ponga su dominio en el campo From. Esa lista es lo que necesita antes de pasar su política de p=none a una política de aplicación.

Desde mayo de 2026 el formato se define en el RFC 9990, que junto con el RFC 9989 (el propio mecanismo DMARC) sustituyó al antiguo RFC 7489. Si necesita repasar los 3 registros, empiece por SPF, DKIM y DMARC explicados.

Cómo le llegan los informes

Los informes se solicitan con la etiqueta rua de su registro DMARC:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Cada proveedor participante le envía entonces por correo un archivo XML, normalmente comprimido. El RFC 9990 indica que el XML SHOULD be GZIP compressed (debería comprimirse con GZIP), con la extensión .xml.gz, y el nombre del archivo sigue un patrón fijo:

mail.receiver.example!example.com!1013662812!1013749130.xml.gz

Es decir: la organización que informa, su dominio, y el inicio y el fin del periodo como marcas de tiempo Unix. El periodo del informe suele abarcar un único día UTC.

Si los informes deben llegar a un buzón de otro dominio (por ejemplo, un servicio de informes en reports.example.net), ese dominio tiene que confirmar que los acepta. Los receptores buscan un registro TXT como example.com._report._dmarc.reports.example.net que contenga v=DMARC1 y, si no existe, ignoran la dirección rua. La falta de este registro de confirmación es un motivo habitual por el que los informes nunca llegan.

La estructura de un informe

Todos los informes tienen las mismas 3 partes. Este es un ejemplo abreviado basado en la muestra del RFC 9990:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <report_metadata>
    <org_name>Sample Reporter</org_name>
    <date_range><begin>302832000</begin><end>302918399</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>quarantine</p>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>pass</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result><selector>abc123</selector></dkim>
      <spf><domain>example.com</domain><result>fail</result></spf>
    </auth_results>
  </record>
</feedback>

• report_metadata: quién envió el informe y qué periodo cubre.
• policy_published: el registro DMARC que vio el receptor. Compárelo con lo que cree haber publicado.
• record: un bloque por cada combinación de IP de envío y resultados. Un dominio con mucho tráfico recibe muchos.

Cómo leer un registro, campo por campo

source_ip y count. El servidor que se conectó al receptor y cuántos mensajes entregó en ese periodo. Aquí es donde se identifica a los remitentes: una consulta de DNS inversa (dig -x 192.0.2.123 +short) o el titular de la IP suelen indicar si pertenece a su proveedor de correo, a su CRM o a alguien desconocido.

policy_evaluated. El veredicto DMARC. Aquí dkim y spf no son los resultados en bruto, sino los resultados de alineación: si la comprobación se superó para un dominio que coincide con su dominio From. DMARC se supera si al menos uno de ellos es pass. disposition muestra qué hizo el receptor: none, pass, quarantine o reject. Si difiere de su política, un elemento reason explica el motivo, por ejemplo una excepción por reenvío o por lista de correo.

identifiers. header_from es el dominio que vieron sus destinatarios. envelope_from es el dominio que utilizó la comprobación SPF, que a menudo es un subdominio de su servicio de envío y no el suyo.

auth_results. Los resultados en bruto de SPF y DKIM con los dominios para los que se comprobaron. El RFC 9990 ahora exige el selector DKIM, lo que le ayuda a saber qué servicio firmó el mensaje.

En el ejemplo anterior, DKIM se superó y estaba alineado, SPF falló y, aun así, el mensaje superó DMARC. Es la situación típica de un servicio que firma con su dominio pero envía desde su propio dominio de sobre.

Clasificar a los remitentes en 3 grupos

Tras unas semanas de informes, cada IP de origen encaja en uno de estos grupos:

1. Conocidos y que superan la comprobación. Su proveedor de correo y los servicios bien configurados. No hay nada que hacer.
2. Conocidos pero que fallan. Una herramienta legítima (soporte, facturación, newsletter) que envía sin DKIM alineado o que no figura en SPF. Active DKIM con su dominio en esa herramienta, o añádala a SPF vigilando el límite de 10 consultas.
3. Desconocidos y que fallan. Servidores que no puede atribuir a nada de lo que usa. Algunos son reenviadores y listas de correo; otros son alguien que pone su dominio en el campo From. Son justo los mensajes que detendría una política p=quarantine o p=reject, el mismo tipo de correo que se usa en los fraudes de facturas falsas.

El grupo 2 es el que importa antes de aplicar la política. Si cambia a p=quarantine mientras una herramienta legítima sigue fallando, su correo acabará en spam.

Consejos prácticos

• Use un buzón dedicado o una herramienta de procesamiento de informes. El XML en bruto de varios proveedores cada día es difícil de leer a mano.
• Fíjese en el valor testing. El RFC 9989 sustituyó la antigua etiqueta pct por una etiqueta de modo de prueba t; t=y pide a los receptores que apliquen una acción más suave que su política.
• Observe el volumen, no solo los fallos. Una fuente nueva y repentina con un count alto merece atención aunque supere la comprobación.
• Conserve los informes durante unos meses para poder comparar antes y después de un cambio.
• Recuerde que los proveedores de correo exigen cada vez más DMARC a los remitentes masivos, como explicamos en los requisitos de Gmail y Yahoo para remitentes.

Una lista de comprobación breve

• Registro DMARC con una dirección rua que alguien lea de verdad.
• Destinos de informes externos confirmados con un registro _report._dmarc.
• Cada IP de origen atribuida a un servicio que usted conoce.
• DKIM alineado activado para cada remitente legítimo.
• Fuentes desconocidas que fallan revisadas y, después, la política pasada a p=quarantine y más adelante a p=reject.

Dónde encaja Guarding

Los informes DMARC muestran lo que vieron los receptores. Nosotros vigilamos el otro lado desde fuera cada día: sus registros SPF, DKIM y DMARC, los dominios similares y el resto de su exposición externa. Cuando un registro se debilita o desaparece un selector, una persona lo revisa y usted recibe el cambio exacto que debe hacer, tal como describimos en qué ocurre cuando encontramos algo. Puede ver cómo se presenta en el panel de ejemplo.