Cómo leer los informes agregados de DMARC y pasar a p=reject con seguridad

Los informes agregados de DMARC son archivos XML que le envían los proveedores de buzones, normalmente una vez al día, y que listan todas las fuentes que enviaron correo afirmando ser su dominio y si pasaron SPF, DKIM y la alineación. Leerlos es la forma de encontrar a todos los remitentes legítimos, corregir los que fallan y descubrir quién le está suplantando, para poder pasar de p=none a p=reject sin bloquear correo real.

La versión corta

1. Pida informes. Añada una dirección rua a su registro DMARC mientras la política sea p=none.
2. Espere y recopile. Reúna de dos a cuatro semanas de informes, incluido cualquier envío mensual.
3. Clasifique las fuentes. Marque cada IP de origen como legítima y alineada, legítima pero con fallos, o desconocida.
4. Corrija lo que falla. Dé a cada servicio legítimo una firma DKIM o un Return-Path alineados.
5. Aplique por etapas. Quarantine con un porcentaje bajo, auméntelo y luego pase a reject.

El registro DMARC que solicita informes

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

Enviar informes a otro dominio

Si la dirección rua está en un dominio distinto del que se informa, ese otro dominio debe publicar un registro que lo permita. De lo contrario, los proveedores no enviarán informes. Para los informes sobre example.com que van a reports.example.net:

example.com._report._dmarc.reports.example.net.  3600  IN  TXT  "v=DMARC1"

Qué contiene un informe

Los informes llegan como archivo adjunto, normalmente comprimido en gzip o zip. Al abrir uno encontrará tres partes: información sobre quien envía el informe, la política que encontró el proveedor y una lista de filas, una por cada combinación de IP de origen y resultado.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <report_id>1234567890</report_id>
    <date_range><begin>1759708800</begin><end>1759795199</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain><adkim>r</adkim><aspf>r</aspf><p>none</p><pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>1250</count>
      <policy_evaluated><disposition>none</disposition><dkim>pass</dkim><spf>pass</spf></policy_evaluated>
    </row>
    <identifiers><header_from>example.com</header_from></identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><selector>mail1</selector><result>pass</result></dkim>
      <spf><domain>bounce.example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Clasifique cada fuente en uno de tres grupos

Cómo identificar una fuente

• DNS inverso: dig -x 203.0.113.10 +short suele nombrar al proveedor.
• Dominios de autenticación: los dominios SPF y DKIM de auth_results suelen revelar el servicio.
• Su propio inventario: liste todas las herramientas que envían con su dominio: plataforma de marketing, helpdesk, CRM, sistema de facturación, formularios web, herramientas de RR. HH. y servidores.
• Volumen y patrón: un recuento pequeño y constante de un servicio conocido es normal; una ráfaga repentina desde una IP desconocida es sospechosa.

Resuma los informes con un script breve

Para una primera mirada a una carpeta de informes descomprimidos, este script totaliza los mensajes por IP de origen y resultado DMARC:

import glob
import xml.etree.ElementTree as ET
from collections import defaultdict

totals = defaultdict(int)
for path in glob.glob("reports/*.xml"):
    for rec in ET.parse(path).getroot().iter("record"):
        row = rec.find("row")
        ip = row.findtext("source_ip")
        ev = row.find("policy_evaluated")
        key = (ip, ev.findtext("dkim"), ev.findtext("spf"))
        totals[key] += int(row.findtext("count"))

for (ip, dkim, spf), n in sorted(totals.items(), key=lambda x: -x[1]):
    print(f"{ip:18} dkim={dkim:5} spf={spf:5} messages={n}")

Corregir los fallos de alineación

Pase a la aplicación de la política por etapas

Una vez que las fuentes legítimas estén alineadas y solo fallen las desconocidas, aumente la política gradualmente. Espere al menos una semana en cada etapa y lea los informes antes de avanzar.

Siga monitoreando después de p=reject

• Revise semanalmente al principio y luego cada mes. Las herramientas nuevas que envíen con su dominio aparecerán como fallos.
• Añada un paso al proceso de incorporación: cualquier sistema nuevo que envíe correo con su dominio se autentica antes de entrar en producción.
• Proteja los dominios aparcados: publique p=reject y un registro SPF vacío en los dominios desde los que no envía.
• Vigile la preparación para BIMI: una política DMARC aplicada es un requisito previo si más adelante quiere que su logotipo aparezca en la bandeja de entrada.

Lecturas adicionales y fuentes

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• dmarc.org: Descripción general de DMARC
• Google: Configurar DMARC
• RFC 8617: The Authenticated Received Chain (ARC)
• Guías relacionadas: Autentique un dominio de envío y Requisitos para remitentes masivos.