DMARC none to reject migration
dmarc reject migration · dmarc enforcement · dmarc rollout
A staged rollout using reports, pct= sampling, and alignment fixes before full spoofing protection.
Por DN01 Network Team
Jumping straight to p=reject without aligned legitimate mail causes false positives that block invoices, password resets, and product notifications. El analizador DMARC de DN01 obtiene el TXT _dmarc, analiza etiquetas y resalta política y alineación antes del enforcement. Los operadores lo usan en migraciones, triage de incidentes e incorporación de proveedores cuando necesitan evidencia repetible en lugar de capturas aisladas.
Healthy rollouts fix envelope and DKIM signing paths, monitor rua for two to four weeks, then raise pct= in steps while watching bounce and spam-folder rates.
Document each policy change in change management, re-run the DMARC Analyzer after every TXT edit, and keep p=none rollback ready until metrics stabilize. Combine la salida DMARC con validadores SPF y DKIM del mismo dominio para corregir la autenticación junta. Guarde el permalink del resultado en el ticket, registre la hora de la comprobación y compare la salida antes y después de cambios de configuración o actualizaciones del cliente.
Repita la comprobación tras cada cambio relevante y conserve el enlace de la guía en el runbook del equipo para que nuevos operadores sigan el mismo orden de diagnóstico.
Etiquetas que resalta DN01
La política p= y el subdominio sp= definen acciones del receptor; pct= limita cuánto correo aplica la política durante el despliegue.
Los modos aspf y adkim controlan si se exige coincidencia relaxed o strict entre dominios autenticados y el From visible.
Errores de despliegue
Publicar reject mientras marketing o ticketing envían con DKIM del proveedor rompe correo legítimo en carpetas de spam.
Ignorar informes agregados hace que descubra fuentes desalineadas solo cuando los clientes reclaman recibos perdidos.
Ruta segura de enforcement
Empiece en p=none con rua, corrija alineación para cada remitente aprobado, luego quarantine antes de reject.
Use pct<100 solo como puente temporal; documente la fecha objetivo de enforcement completo en el runbook de correo.
Documentación y siguientes pasos
Archive la salida del comprobador en tickets de cambio, revisiones de proveedores e incidentes para que el siguiente operador vea la misma evidencia analizada.
Enlace esta guía y la página del instrumento en wikis del equipo y combine resultados con otras utilidades DN01 cuando el problema cruce DNS, correo, TLS o capas de seguridad. Anote quién ejecutó la comprobación, qué entrada se usó y si el permalink del resultado se compartió con el solicitante.
Cuándo escalar o combinar comprobaciones
Si la salida de Analizador DMARC sigue sin coincidir con el informe del usuario tras reiniciar o limpiar caché, capture marcas de tiempo, entradas en bruto y el permalink DN01 antes de cambiar DNS, correo, TLS o auth de producción.
Escale a responsables de plataforma o identidad cuando la política empresarial bloquee la corrección; de lo contrario combine esta guía con utilidades DN01 de DNS, correo, TLS o seguridad para cerrar el ciclo en un ticket.
| Política | Uso típico |
|---|---|
| p=none | Monitorizar y recoger rua |
| p=quarantine | Suavizar fallos hacia spam |
| p=reject | Bloquear spoof tras alineación limpia |
| pct<100 | Solo enforcement gradual |
Preguntas frecuentes
- ¿DMARC sustituye SPF o DKIM?
No. DMARC depende de SPF y DKIM más alineación con el dominio From.
- ¿Todo dominio debe usar p=reject?
Muchos dominios remitentes deberían, pero solo tras informes con correo legítimo alineado y sin fuentes sorpresa.
- ¿Por qué mostrar pct aparte?
reject con pct=20 no es enforcement completo. DN01 muestra pct para no sobreestimar la protección.
- ¿Puedo compartir resultados con el equipo?
Sí. Copie la salida DN01 o el permalink en tickets de cambio para que todos revisen la misma evidencia analizada en lugar de capturas sueltas.