DMARC: de p=none a p=reject en 4 semanas, paso a paso

Introducción

Has publicado un registro DMARC con p=none. Los informes agregados ya llegan. Ahora alguien hace la pregunta evidente: ¿cuándo aplicamos la política?

La mayoría de las guías responden a otra pregunta. Explican qué significan none, quarantine y reject. Si necesitas eso antes, lee Políticas DMARC explicadas. Este artículo da por hecho que conoces las tres políticas y necesitas un plan para avanzar.

El plan dura cuatro semanas para un dominio con pocos remitentes. Cada semana termina con un control: unas cifras que los informes deben mostrar antes del siguiente paso. Si las cifras no están, esperas. El calendario orienta. Los informes deciden.

La cifra que vigilas: tasa de aprobación por origen

Una única tasa de aprobación global oculta problemas. Un dominio al 97 % puede tener una herramienta de nóminas al 0 % que envía cuarenta correos al mes. Esos cuarenta correos son los que importan el día que rechazas.

Vigila la tasa de aprobación DMARC por origen de envío: por rango de IP, agrupado por el servicio al que pertenece.

Cada registro de un informe agregado te da lo necesario:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
    <envelope_from>example.com</envelope_from>
  </identifiers>
  <auth_results>
    <dkim><domain>esp-mail.net</domain><result>pass</result></dkim>
    <spf><domain>example.com</domain><result>pass</result></spf>
  </auth_results>
</record>

Léelo en este orden:

1. policy_evaluated da el veredicto DMARC. Sus valores dkim y spf ya incluyen la alineación. Basta con un pass para que DMARC pase.
2. auth_results da las comprobaciones en bruto y los dominios usados. Aquí DKIM pasó, pero para esp-mail.net, no para example.com. Es un aprobado sin alineación.
3. disposition dice qué hizo el receptor. Con p=none siempre es none. Desde la semana 3 te dice a quién mandaron a spam.

Los informes DMARC son XML, un fichero por receptor y día. Leerlos a mano sirve una semana, no una migración. Pega uno en el conversor de XML DMARC a lenguaje humano para ver la estructura, o deja que una herramienta de monitorización los agrupe por origen.

Semana 1: p=none, informes e inventario de remitentes

El registro:

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

Si rua apunta a un buzón de otro dominio, ese dominio debe publicar un registro de autorización (example.com._report._dmarc.otrodominio.com). Los servicios de monitorización lo hacen por ti. Sin él, los receptores descartan los informes sin avisar.

Deja ruf fuera por ahora. Pocos receptores grandes envían informes de fallo, y los que lo hacen pueden incluir contenido del mensaje. No los necesitas para este plan.

Baja ya el TTL del registro _dmarc a 300 segundos. Quieres que cada cambio posterior, marcha atrás incluida, se aplique en minutos.

El trabajo: construye el inventario de remitentes a partir de los informes, no de memoria. Agrupa cada IP de origen por propietario y mete cada grupo en uno de estos cuatro cajones:

Cajón	Ejemplo	Acción
Tuyo, aprueba alineado	Google Workspace, Microsoft 365	Ninguna. Sigue vigilando.
Tuyo, falla	CRM, facturación, soporte, una impresora que envía escaneos	Arreglar en la semana 2
Reenvíos y listas	Alias de universidad, Google Groups, una regla de reenvío de un socio	Explicar, no «arreglar»
No es tuyo	IP desconocidas en rangos de hosting, botnets	Esto es lo que parará p=reject

Pregunta a cada departamento con qué envía correo. Los informes muestran los orígenes que enviaron esta semana. No pueden mostrar la newsletter trimestral ni las renovaciones anuales.

Control para pasar a la semana 2:

• Al menos siete días de informes de Google, Microsoft y Yahoo
• Cada origen con volumen relevante está en un cajón
• Sabes qué ciclos de negocio aún no se han ejecutado (facturación de fin de mes, nóminas)

Semana 2: arreglar la alineación SPF y DKIM, origen a origen

Es la semana con más trabajo real. Recorre el cajón «tuyo, falla» de origen en origen.

Prioriza la alineación DKIM. Una firma DKIM sobrevive al reenvío. SPF no, porque la IP del reenviador no está en tu registro SPF. Si un origen puede firmar con d=example.com, configura eso primero.

Usa la alineación SPF como segunda vía. La mayoría de los proveedores de envío admiten un return-path propio (dominio de rebote), como bounces.example.com. Con alineación relajada (aspf=r, el valor por defecto), un subdominio de tu dominio alinea.

Arreglos típicos por origen:

Qué muestra el informe	Causa	Arreglo
SPF pasa sin alinear; DKIM pasa con el dominio del proveedor	El proveedor firma y gestiona rebotes con su propio dominio	Activa DKIM propio para tu dominio y un return-path propio
SPF falla para un rango de IP	Falta el servicio en tu registro SPF	Añade su include: y vigila el límite de 10 consultas
SPF permerror en todo	Dos registros SPF o más de 10 consultas	Fusiónalos en uno
DKIM falla para tu propio dominio	Selector erróneo o rotado, o cuerpo modificado en tránsito	Comprueba el selector con el verificador DKIM

El detalle de cada caso está en Fallos de alineamiento DMARC.

Tras cada arreglo, espera entre 24 y 48 horas. Los informes cubren el día anterior, así que no verás el resultado esa misma tarde.

Control para pasar a la semana 3:

• Cada origen legítimo pasa DMARC por encima del 98 % en Google, Microsoft y Yahoo
• Los fallos que quedan tienen explicación: reenvíos, listas de correo o suplantación
• Ningún origen con volumen real sigue como «desconocido»

Semana 3: p=quarantine, con rampa

El registro, el primer día:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

Después sube pct a 50 y a 100 a lo largo de la semana, si los informes siguen limpios.

Tienes que conocer la situación de pct. El RFC 9989, publicado en mayo de 2026, sustituye al RFC 7489 y elimina la etiqueta pct. En su lugar añade t=y (modo de prueba), que pide a los receptores aplicar un nivel de política menos. Los receptores que ya implementan el RFC 9989 solo conocen t. Muchos receptores aún respetan pct, pero no puedes contar con un valor parcial en todas partes.

La regla práctica: la rampa es un colchón, no una red de seguridad. No empieces la semana 3 si no aceptarías pct=100 el primer día.

Qué vigilar en los informes:

• Filas con disposition=quarantine de tus propios orígenes. Es la primera señal real. Un origen legítimo aquí significa que un arreglo de la semana 2 no ha aguantado.
• El elemento reason dentro de policy_evaluated. Valores como forwarded, mailing_list, trusted_forwarder o local_policy indican dónde un receptor no aplicó tu política. sampled_out significa que el mensaje quedó fuera de la muestra de pct.
• El soporte interno. Los usuarios ven el correo en spam antes de que leas el siguiente informe.

Control para pasar a la semana 4:

• Al menos cinco días con pct=100 (o sin pct)
• Ningún origen legítimo con mensajes en cuarentena
• Ninguna queja por correo perdido o en spam
• Los ciclos de negocio que apuntaste en la semana 1 se han ejecutado al menos una vez con quarantine

Semana 4: p=reject, subdominios incluidos

El registro:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@example.com

Revisa los subdominios antes de escribir sp=reject. Filtra los informes por header_from. Cada subdominio que aparezca (news.example.com, billing.example.com) debe aprobar igual que el dominio principal. Un subdominio con su propio registro _dmarc usa ese registro en vez de sp. Los subdominios que no existen nunca deberían enviar correo. El RFC 9989 añade np para ellos. Los receptores que no la conocen la ignoran, así que añadir np=reject es seguro.

Las listas de correo son el caso que hay que pensar. El RFC 9989 es claro en dos puntos:

• Los receptores no deben rechazar un mensaje solo por p=reject. Sin más pruebas, lo tratan como quarantine.
• Los dominios cuyos usuarios escriben en listas de correo no deberían publicar p=reject.

La mayoría de los servidores de listas grandes reescriben ya la dirección From de los dominios con política estricta, y así evitan el problema. Si tus usuarios escriben en listas que no lo hacen, tienes dos opciones. Quédate en quarantine en el dominio principal, o mantén reject y pasa a otro dominio a quienes escriben en listas.

Cambia el registro un día tranquilo, a principio de semana. No lo cambies un viernes por la tarde.

Criterios para dar marcha atrás

Decide las reglas de marcha atrás antes de necesitarlas, y apunta quién cambia el registro DNS.

Disparador	Acción
Un origen legítimo muestra disposiciones quarantine o reject	Retrocede un paso, arregla el origen, espera 48 horas
La tasa de aprobación de un origen conocido cae más de 2 puntos de un día a otro	Investiga antes de avanzar
Falla un flujo crítico (recuperación de contraseñas, facturas, pedidos)	Retrocede un paso de inmediato y luego investiga
Aparece un origen nuevo y desconocido con mucho volumen	Mantén la política: suele ser suplantación, que es justo para lo que sirve

Retrocede un paso, no hasta p=none. Volver de reject a quarantine conserva casi toda la protección mientras arreglas el origen.

Trampas habituales

• Una única tasa global. Oculta el origen de poco volumen que importa. Vigila por origen.
• Juzgar por un solo receptor. Los informes de Google son los más grandes, pero Microsoft y Yahoo pueden ver otros caminos. Revisa los tres.
• Contar el reenvío como fallo. El correo reenviado falla SPF y es lo esperado. No metas al reenviador en tu SPF. Asegúrate de que el mensaje original va alineado por DKIM.
• Tomar un aprobado SPF por un aprobado DMARC. Si envelope_from es el dominio del proveedor, SPF aprobó para él, no para ti.
• Subdominios y dominios aparcados olvidados. Los dominios que nunca envían correo deberían publicar v=DMARC1; p=reject; y un registro SPF con -all.
• rua externo sin autorización. No llega ningún informe, y el panel vacío parece una buena noticia.
• Parar en p=reject. Cada trimestre aparecen remitentes nuevos. Con reject, una herramienta nueva sin autenticar es correo que nunca llega. Sigue vigilando los informes y configura alertas para orígenes nuevos que fallan.

Las cuatro semanas de un vistazo

Semana	Registro	Control de salida
1	p=none; rua=…	Siete días de informes, cada origen en un cajón
2	p=none; rua=…	Cada origen legítimo por encima del 98 % de aprobación alineada
3	p=quarantine; pct=25 → 100	Cinco días limpios al 100 %, sin correo legítimo en cuarentena
4	p=reject; sp=reject	Monitorización y alertas continuas

Siguientes pasos

1. Construye el registro de cada paso: Generador de registros DMARC →
2. Lee un informe a mano: XML DMARC a lenguaje humano →
3. Comprueba SPF, DKIM y DMARC a la vez: Puntuación del dominio →
4. Monitoriza la semana 1 desde el primer día: Empieza gratis → — DMARC Examiner agrupa tus informes agregados por origen de envío, así ves la tasa de aprobación de cada origen y cada remitente desconocido. El plan gratuito cubre un dominio.

---

Artículos relacionados:

• Políticas DMARC explicadas: None vs Quarantine vs Reject
• Cómo leer informes DMARC en XML (con ejemplos)
• Fallos de alineamiento DMARC: diagnóstico y soluciones
• ¿Tus correos van a spam aunque DMARC esté en None?