Leer informes DMARC

Módulo 4: Entregabilidad: SPF, DKIM y DMARC en la práctica · Tiempo de lectura: 12 minutos

Objetivo de aprendizaje: Después de esta lección podrá abrir y leer un informe agregado de DMARC, determinar por cada fila cuál es la fuente y por qué pasa o falla, y decidir qué debe reparar, qué puede ignorar y cuándo puede endurecer su política.

Conceptos clave: informe agregado (aggregate report, RFC 9990), rua, XML, gzip o zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selector, informe de fallos (ruf, RFC 9991), servicio de informes, privacidad

Qué recibe

Si ha puesto una dirección rua en su registro DMARC (lección 4.4), los grandes receptores como Google, Microsoft y Yahoo le enviarán aproximadamente cada día un informe agregado. Es un correo con un adjunto, normalmente un archivo XML comprimido con un nombre como:

receiver.example!example.com!1793923200!1794009599.xml.gz

Esto significa: del receptor receiver.example, sobre su dominio example.com, sobre el periodo entre las dos marcas de tiempo (segundos desde 1970; aquí el 6 de noviembre de 2026, todo el día en UTC).

Un informe no contiene el contenido del correo, ni asuntos, y normalmente tampoco las direcciones de los destinatarios. Contiene, por cada servidor emisor, el número de mensajes y el resultado de SPF, DKIM y DMARC. Por eso es un resumen fiable de quién envía correo en nombre de su dominio, incluidas fuentes que usted mismo había olvidado, y estafadores.

La estructura de un informe

Un informe tiene tres partes. A continuación, los fragmentos más importantes del archivo de ejemplo de esta lección (dmarc-rapport-1.xml).

1. Quién informa, sobre qué periodo

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Qué política encontró el receptor en su dominio

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Compruebe esto siempre: si aquí no aparece lo que usted cree que tiene en su DNS, es que el receptor leyó otro registro (o uno antiguo).

3. Por fuente: un registro

Cada record corresponde a una dirección IP emisora con una combinación de resultados:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

La diferencia más importante: auth_results frente a policy_evaluated

Aquí está la clave de la lectura. En el ejemplo anterior, en auth_results aparece dos veces pass: DKIM pasó para mailer.example y SPF pasó para bounce.mailer.example. Sin embargo, en policy_evaluated aparece dos veces fail. No es una contradicción: policy_evaluated solo cuenta una comprobación aprobada que esté alineada con header_from. Ninguno de los dos dominios pertenece a example.com, así que DMARC falla.

Así se lee cada fila:

1. Mire policy_evaluated. ¿Hay un pass en dkim o en spf? Entonces DMARC pasa y esta fuente está en orden.
2. ¿Falla todo? Mire los dominios en auth_results. ¿Se trata de un servicio suyo que sí pasa, pero con su propio dominio? Entonces debe activar en ese servicio DKIM con su propio dominio (lección 4.3).
3. ¿Falla también en auth_results, o falta DKIM por completo? Averigüe de quién es la dirección IP (DNS inverso, lección 5.1, o una consulta whois). ¿Es uno de sus propios sistemas? Repárelo. ¿Es desconocido y se trata de cantidades sospechosas? Probablemente sea una suplantación.

Patrones que verá con frecuencia

Preste también atención a IPv6: un servidor propio que a veces envía por IPv6, mientras que su SPF solo menciona la dirección IPv4, da un softfail en esas filas. Con una firma DKIM, DMARC aún así pasa, pero es una señal de que su SPF está incompleto.

Del informe a la decisión

Está listo para endurecer su política (de none a quarantine, después a reject) cuando:

• cada fuente que es suya tiene al menos un pass en policy_evaluated;
• eso lleva así ya unas semanas, en todos los grandes receptores;
• lo que aún falla es solo correo reenviado con una firma DKIM válida (que de todos modos pasa) o claramente una suplantación.

Si falla una fuente propia importante, como en el ejemplo el servicio de newsletter con 1250 mensajes, entonces es demasiado pronto. Con p=reject, el receptor rechazaría esos 1250 boletines.

Hacer los informes legibles

Un informe en un editor de texto es manejable. Veinte al día, no. Hay tres maneras:

• Un servicio de informes (hay muchos, también con una variante gratuita). Usted pone su dirección en rua y ellos generan gráficos y listados. Tenga en cuenta: así le da a ese servicio visibilidad sobre qué servidores envían en su nombre, y la dirección de informes está en su dominio (vea la autorización mediante _report._dmarc en la lección 4.4). Elija un servicio en el que confíe y que cumpla el RGPD.
• Una herramienta propia: existen programas de código abierto que extraen informes de un buzón y los convierten en un resumen.
• Leerlo usted mismo con un visor de XML o un navegador, para casos ocasionales.

Los informes de fallos (ruf, RFC 9991) son distintos: por cada correo fallido, a veces con fragmentos del correo incluidos. Casi ningún gran receptor los envía, precisamente por la privacidad. No los necesita para implantar DMARC correctamente.

En la práctica: así se ve

En WebOké puede introducir la dirección de informes en la ayuda de DMARC de DirectAdmin o Mi WebOké (vea la lección 4.4), y usted mismo elige un buzón donde llegarán los informes; una dirección aparte como dmarc@ con su propia carpeta evita que su correo habitual quede sepultado. La lectura se hace con un servicio de informes o un programa a su elección. Esto funciona igual con cualquier proveedor: el informe es un formato estándar.

Resumen

• Un informe agregado es un archivo XML diario (a menudo comprimido) por receptor, con el número de mensajes y los resultados por cada IP emisora.
• auth_results da el resultado en bruto de SPF y DKIM; policy_evaluated solo lo que pasó alineado. Un pass en auth_results puede ser un fail en DMARC.
• El correo reenviado se reconoce por DKIM pass con SPF fail; la suplantación, por todo fail desde una IP desconocida.
• Endurezca su política solo cuando todas sus fuentes propias lleven varias semanas pasando.
• Los informes de fallos (ruf) son raros y no son necesarios.

Cuestionario

Ejercicio

Ejercicio Z4.5: Leer un informe DMARC. Abra el archivo de ejemplo dmarc-rapport-1.xml (un informe agregado sobre example.com, con datos ficticios). Responda a las preguntas: qué política encontró el receptor, cuántos mensajes hay en total en el informe, cuántos de ellos fallaron DMARC, qué fila es el servicio de newsletter y qué debe hacerse al respecto, qué fila es correo reenviado, qué fila es probablemente suplantación, qué debe cambiar en el registro SPF según la fila 6, qué fila pasa solo gracias a DKIM en un servicio con su propio Return-Path, y ¿puede el dominio pasar ahora a p=quarantine? El programa corrige sus respuestas con una clave fija y explica, en cada pregunta, qué línea del informe da la respuesta.

Para saber más

Los pasos de estos artículos corresponden a los paneles de WebOké; en otros proveedores funciona de forma similar.

• ¿Qué es DMARC? Explicación en lenguaje sencillo
• Manual de DirectAdmin 5.9: Configurar DMARC
• Curso gratuito de DNS 4.5: DMARC: qué deben hacer los destinatarios con el correo falso
• RFC 9990 (DMARC Aggregate Reporting), con el informe de ejemplo en el anexo B; RFC 9991 (Failure Reporting)