Publicar DMARC no es suficiente si te quedás en p=none para siempre. El objetivo es llegar a p=reject, que es el único modo que impide a un atacante suplantar tu dominio. La transición se hace en tres fases y toma típicamente 4 a 8 semanas dependiendo de la complejidad de tu email saliente.

Fase 1 — p=none (observación)

Duración típica: 2 semanas mínimo, 4 recomendadas.

Objetivo: identificar todos los sources legítimos que envían email a tu nombre.

Qué mirar:

• ¿Qué IPs pasan DMARC hoy?
• ¿Qué IPs fallan y por qué (SPF, DKIM, ambos)?
• ¿Hay sources que reconocés (Salesforce, HubSpot, HR system) pero no autorizaste?

Cuándo pasar a la fase 2:

• ≥95% de compliance en los sources que ya identificaste como legítimos.
• Cero surprises: no aparece un source nuevo desconocido cada semana.
• Los sources marginales (fallos < 1% del volumen) documentados como aceptables.

Fase 2 — p=quarantine (cuarentena)

Duración típica: 2-4 semanas.

Qué hace: los correos que fallan DMARC caen en la carpeta de spam del destinatario en vez de rechazarse. Todavía llegan — pero con visibilidad reducida.

Configuración:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; ...

El parámetro pct=25 aplica quarantine a solo el 25% del tráfico al principio. Esto te da una válvula de seguridad si algo falla — solo un cuarto del tráfico se ve afectado. Escalá progresivamente:

Semana	pct
1-2	25
3-4	50
5+	100

Señales de que estás listo para pasar a p=reject:

• Después de 2 semanas con pct=100, ningún reporte de usuarios de “no me llega el email de X”.
• ≥99% compliance en sources legítimos.
• Failures restantes son 100% mail spoofing / phishing (los ves en el detalle del reporte RUF).

Fase 3 — p=reject

Configuración final:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Cambios respecto a la fase anterior:

• p=reject — los receivers directamente descartan el correo suplantado.
• pct=100 (implícito).
• adkim=s y aspf=s — alineación estricta (opcional). Rechaza si el From: visible no coincide exactamente con el dominio autenticado. Más seguro pero más frágil — solo si estás seguro de que todos los sources legítimos usan alineación exacta.

Sub-dominios

Un truco poderoso: DMARC permite políticas separadas para el dominio organizacional vs los sub-dominios. Si publicás:

v=DMARC1; p=reject; sp=reject; ...

sp=reject fuerza que todos los sub-dominios que no tengan su propio DMARC también rechacen. Esto tapa un vector común: el atacante crea secure-billing.tuempresa.com (subdominio no publicado) y lo usa para phishing. Con sp=reject en el root, ese subdominio hereda la política aunque no exista un _dmarc.secure-billing.tuempresa.com.

Errores comunes

1. Ir directo a p=reject sin observar 2-4 semanas primero. Rompe tu email transaccional.
2. No monitorear los reports después de llegar a p=reject. Los reports siguen llegando y son la única forma de detectar drift (un nuevo vendor no autorizado, un DKIM key rotado sin actualizar el TXT).
3. Publicar múltiples registros DMARC en el mismo dominio. La spec exige uno solo — los receivers ignoran el TXT entero si ven duplicados.
4. Confiar en SPF sin DKIM. SPF se rompe cuando el email se reenvía (mailing lists). Sin DKIM, esos reenvíos fallan DMARC.

Rollback

Si activás enforcement y algo se rompe, el rollback es simple: cambiá el TXT a p=none y esperá el TTL. Los receivers levantan el cambio al siguiente lookup (típicamente segundos-minutos, no horas).