Subir DMARC hasta reject sin romper nada

Se sube a p=reject por subdominios y por tiempo, no por porcentajes, porque desde mayo de 2026 los porcentajes ya no existen. La revisión de DMARC eliminó el tag pct, así que el manual que circula por internet (publicar pct=10, después pct=25, después pct=50) describe un mecanismo que hoy no está en la norma. La política se aplica entera o no se aplica.

Lo que sí funciona es esto: observar con p=none hasta tener cerrado el inventario de quién envía en tu nombre, empezar el enforcement por el flujo que controlas al cien por cien, blindar los subdominios con sp y np mientras el dominio raíz sigue tolerante, y dejar el raíz para el final. Entre seis y doce semanas, según lo desordenada que esté la casa.

Lo que cambió en mayo de 2026

DMARC dejó de ser un documento informativo y pasó a la vía de estándar. El RFC 7489 queda obsoleto y lo sustituyen tres documentos: el RFC 9989 (protocolo y política), el RFC 9990 (informes agregados) y el RFC 9991 (informes de fallo). Estos son los cambios que tocan al trabajo diario:

Regla práctica de transición: publica registros que se lean bien con la norma vieja y con la nueva. Ni uses pct para nada, ni des por hecho que t= te está protegiendo.

Antes de tocar la política: los cuatro cubos

Subir a reject es prometer al mundo que todo lo que sale con tu dominio en el From está autenticado y alineado. Si esa promesa es falsa para un solo emisor con volumen, el día del cambio dejan de llegar sus mensajes: normalmente el ERP que manda las facturas, el CRM, el formulario de la web o la agencia de marketing. Por eso el trabajo de verdad no es publicar el registro, es cerrar el inventario. Cada IP que aparece en los informes agregados va a uno de estos cuatro cubos:

1. Cubo 1 · Legítima y alineadaEs tuya, autentica y alinea. No hay nada que hacer. Solo se anota para no volver a investigarla el mes que viene.
2. Cubo 2 · Legítima y no alineadaEs tuya y autentica, pero con el dominio de otro: firma con d= del proveedor, o su Return-Path. Se arregla firmando con tu dominio o cambiando el Return-Path. Este cubo es el que decide el calendario: mientras tenga volumen material, no se sube de escalón.
3. Cubo 3 · ReenvíosVolumen bajo repartido entre muchas IP distintas, con SPF fail y DKIM pass. Es el comportamiento normal de un reenvío y no se arregla desde tu lado: lo mitiga ARC, que pone el intermediario. No es motivo para no subir.
4. Cubo 4 · SuplantaciónVolumen variable, ninguna autenticación, orígenes que no reconoces. Es exactamente la razón por la que existe DMARC y por la que merece la pena llegar a reject.

El criterio numérico para pasar de fase es uno solo: al menos el 98 por ciento del volumen legítimo pasando DMARC durante siete días seguidos. No sirve un día bueno, porque hay emisores que solo envían a fin de mes.

Semana 0: observar sin cambiar nada

_dmarc.empresa.es. IN TXT "v=DMARC1; p=none; rua=mailto:rua@rep.empresa.es; ruf=mailto:ruf@rep.empresa.es; fo=1; adkim=r; aspf=r"

Duración mínima: dos semanas. Duración realista: entre cuatro y seis si la empresa tiene facturación, ERP, CRM, formularios web y una agencia por medio. Siempre hay un emisor olvidado, y aparece tarde. Dos avisos sobre este registro: el buzón del rua tiene que ser uno que alguien procese de verdad, porque publicar un rua que nadie lee es no tener DMARC; y no cuentes con los informes de fallo (ruf), que hoy casi nadie envía por protección de datos, Google entre ellos.

Semanas 2 a 6: inventario y saneamiento

Con los informes en la mano, la lista de fuentes emisoras tiene que quedar cerrada: cada IP y cada dominio que envía en tu nombre, o se autentica alineado o se apaga. El patrón que más vas a ver en los XML es este, y conviene saber leerlo antes de discutirlo con un proveedor:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>fail</dkim>     <!-- resultado de ALINEACIÓN -->
  <spf>pass</spf>
</policy_evaluated>
...
<auth_results>
  <dkim><domain>proveedor.com</domain><result>pass</result></dkim>   <!-- firma correcta -->
  <spf><domain>empresa.es</domain><result>pass</result></spf>
</auth_results>

Semanas 6 a 8: enforcement por el flujo más controlado

Se empieza por el subdominio de menor riesgo, que casi siempre es el transaccional: lo genera un sistema, sale por un solo proveedor y nadie lo reenvía a mano.

_dmarc.mail.empresa.es. IN TXT "v=DMARC1; p=reject; rua=mailto:rua@rep.empresa.es"

Semanas 8 a 10: el raíz a quarantine, los subdominios a reject

_dmarc.empresa.es. IN TXT "v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:rua@rep.empresa.es; fo=1"

Aquí conviene entender el tree walk, porque cambia a quién se aplica tu sp. Antes, para saber cuál era el dominio organizacional de un subdominio, los receptores consultaban la Public Suffix List. Ahora suben el árbol con hasta ocho consultas DNS hasta encontrar un registro DMARC. Consecuencia práctica: un subdominio sin política propia hereda la del padre por el camino corto, y los dominios bajo sufijos raros dejan de dar sorpresas.

Semanas 10 a 12: el dominio raíz a reject

_dmarc.empresa.es. IN TXT "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=r; rua=mailto:rua@rep.empresa.es; fo=1"

Los dominios que no envían correo

Los dominios defensivos, las marcas antiguas y los dominios comprados por parecido no necesitan escalera: no envían, así que no hay nada que romper. Van directos a reject, con SPF y DKIM nulos, y es de las cosas más rentables que se pueden hacer en una tarde.

parked.es.                  IN TXT "v=spf1 -all"
*._domainkey.parked.es.     IN TXT "v=DKIM1; p="
_dmarc.parked.es.           IN TXT "v=DMARC1; p=reject; adkim=s; aspf=s;"

Los tres errores que rompen correo de verdad

Y un cuarto que no rompe correo pero cuesta dinero: creer que reject arregla la entregabilidad. No la arregla. DMARC impide que otros usen tu dominio y es un requisito de los grandes proveedores, pero no mejora por sí solo tu reputación ni te saca de la carpeta de correo no deseado. Eso depende de las quejas, de la higiene de la lista y del contenido.

Si al leer esto te has dado cuenta de que el problema está un paso antes, en que los flujos no alinean, la guía de SPF, DKIM y DMARC explica de dónde sale esa alineación y cómo se comprueba en un mensaje real. Y si lo que quieres saber es qué te exigen exactamente Gmail, Outlook y Yahoo para no rechazarte, está en la guía de requisitos, con la tabla comparada de los tres.