DMARC: pasar de p=none a p=reject sin bloquear el correo legítimo

Un dominio puede mostrar SPF, DKIM y DMARC perfectamente configurados y seguir siendo, en la práctica, tan suplantable como uno sin ninguna autenticación. La razón cabe en tres caracteres: p=none. Mientras la política conserve ese valor, los servidores receptores señalan el fraude sin llegar a bloquearlo nunca. Endurecer hacia quarantine y después reject es el único paso que protege de verdad, y los informes agregados son lo que permite darlo sin enviar por error los propios mensajes a la carpeta de spam.

#Qué protege p=none y qué no protege

DMARC (RFC 7489) añade dos garantías sobre SPF y DKIM. La primera es el alineamiento: el dominio visible en la cabecera From: debe coincidir con el dominio validado por SPF o por DKIM. La segunda es una política publicada que indica al servidor receptor qué hacer con un mensaje no alineado. Esa política la lleva la etiqueta p.

Con p=none, la instrucción enviada a los receptores es explícita: observa, pero no bloquees. Un mensaje que suplanta el dominio pasa por tanto exactamente igual que antes de instalar DMARC. La única ganancia en esta fase es la visibilidad: el dominio empieza a recibir informes que describen quién envía en su nombre. Ese paso de recolección es imprescindible, pero confundirlo con protección es el error más extendido en entregabilidad.

#Anatomía de un informe agregado

Un informe agregado (la etiqueta rua) es un archivo XML que un servidor receptor genera, por defecto una vez al día, para un dominio dado. No contiene ningún contenido de los mensajes: solo direcciones IP de origen, volúmenes y el resultado de la evaluación de SPF, DKIM y DMARC. Este es un extracto reducido a lo esencial.

<record>
  <row>
    <source_ip>203.0.113.24</source_ip>
    <count>148</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>exemple.fr</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>mailer.prestataire.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Este bloque describe 148 mensajes enviados desde una misma IP, que se presentan como exemple.fr. SPF pasa, pero sobre el dominio mailer.prestataire.com: hay autenticación, no alineamiento. DKIM falla. Resultado DMARC: no alineado. Con p=none la disposición sigue siendo none y el mensaje se entrega igualmente. Con p=reject, esos 148 mensajes se rechazarían. Toda la cuestión es saber si son legítimos.

Un informe agregado no dice si un correo llegó: dice quién tiene derecho a escribir en nombre del dominio, y quién se aparta de ello.

#Leer los informes para hallar los remitentes legítimos que fallan

A mano, los informes se vuelven ilegibles en cuanto hay unos pocos proveedores. El reflejo útil no es inspeccionarlo todo, sino aislar una sola categoría: las fuentes no alineadas de alto volumen. Son las que se romperán al endurecer si son legítimas, o las que prueban el fraude si no lo son. Un script de pocas líneas basta para extraer esa lista de un informe descomprimido.

import xml.etree.ElementTree as ET

tree = ET.parse("rapport_agrege.xml")
for rec in tree.findall(".//record"):
    dkim = rec.findtext("row/policy_evaluated/dkim")
    spf = rec.findtext("row/policy_evaluated/spf")
    if dkim != "pass" and spf != "pass":          # non aligné sur les deux
        ip = rec.findtext("row/source_ip")
        count = rec.findtext("row/count")
        frm = rec.findtext("identifiers/header_from")
        print(f"{count:>6}  {ip:

Cada línea de salida es una decisión que tomar: ¿esta IP pertenece a un servicio usado legítimamente (enrutador de marketing, facturación, CRM, formulario del sitio) o a un tercero que suplanta el dominio? Para los primeros, la respuesta es corregir su SPF o activar su firma DKIM antes de endurecer. Para los segundos, endurecer es precisamente el objetivo: quedarán bloqueados.

#La subida de nivel: de none a reject

El paso nunca se da de golpe. Sigue una rampa, en la que cada peldaño se mantiene el tiempo suficiente para que un informe agregado confirme la ausencia de remitentes legítimos en fallo. La etiqueta pct permite históricamente aplicar la política solo a una fracción de los mensajes, para observar el efecto antes de generalizarlo.

; palier intermédiaire : quarantine sur un quart du trafic
_dmarc.exemple.fr.  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; adkim=s; aspf=s"

Un ritmo realista mantiene cada peldaño una o dos semanas: p=none, luego p=quarantine; pct=25, luego pct=100, luego p=reject. La revisión en curso de la especificación tiende a desaconsejar pct en favor de un despliegue progresivo por subdominios y una política distinta mediante la etiqueta sp; el principio sigue siendo el mismo, solo cambia la mecánica del peldaño.

#Informes de fallo (ruf) y bucles de retroalimentación

Junto a los informes agregados, la etiqueta ruf solicita informes de fallo, mensaje a mensaje, en formato ARF (RFC 5965). Son más precisos, pero se envían rara vez: la mayoría de los grandes receptores los suprimen para no transmitir datos personales. Contar con ellos equivale a renunciar a la visibilidad.

#Lo que hay que recordar

DMARC solo protege a partir de quarantine. El camino hacia reject es cuestión de lectura, no de configuración: cada peldaño espera a que un informe agregado confirme que ninguna fuente legítima cae. La secuencia es siempre la misma: recolectar en none, alinear los remitentes reales detectados en los informes, endurecer por peldaños, verificar, rechazar. Un dominio que lleva meses en p=none no se está asegurando: está en espera.

#Para profundizar

Especificación DMARC y esquema de los informes agregados: RFC 7489 (IETF).