INTENCIÓN: Informacional / Comercial · CLUSTER: madurez de política
DMARC p=none, quarantine y reject: diferencias y cuándo usar cada política
Esta guía forma parte del Centro de Conocimiento de ProtectionDMARC. Está orientada a equipos de TI, administradores de dominios y responsables de seguridad que necesitan convertir la autenticación del correo en un proceso controlable y medible.
p=none: visibilidad
La política p=none permite recopilar información sin pedir al receptor que aplique una acción de cuarentena o rechazo basada en DMARC. Es una etapa útil para descubrir fuentes legítimas, errores de autenticación y servicios que todavía deben corregirse.
Qué revisar en la práctica
Antes de cambiar una política, documenta el dominio, los servicios que envían correo y los responsables técnicos. " Comprueba el resultado en DNS y utiliza los informes de autenticación para contrastar la configuración con el tráfico real.
Decisión recomendada
Prioriza primero la visibilidad y la corrección de fuentes legítimas. Después mide los resultados y endurece la política de forma progresiva.
Señal de alerta
Una fuente desconocida, un dominio desalineado o un cambio inesperado de volumen merece investigación antes de aplicar una política más estricta.
p=quarantine: una etapa intermedia
Quarantine indica que los mensajes que no cumplen las condiciones pueden ser tratados como sospechosos. Es una etapa de transición que requiere seguimiento para evitar impactos inesperados en comunicaciones legítimas.
Qué revisar en la práctica
Antes de cambiar una política, documenta el dominio, los servicios que envían correo y los responsables técnicos. " Comprueba el resultado en DNS y utiliza los informes de autenticación para contrastar la configuración con el tráfico real.
Decisión recomendada
Prioriza primero la visibilidad y la corrección de fuentes legítimas. Después mide los resultados y endurece la política de forma progresiva.
Señal de alerta
Una fuente desconocida, un dominio desalineado o un cambio inesperado de volumen merece investigación antes de aplicar una política más estricta.
p=reject: máxima exigencia de política
Reject solicita que los mensajes que no superen los criterios de DMARC sean rechazados. Debe utilizarse cuando el inventario de fuentes esté controlado y la autenticación esté correctamente alineada.
Qué revisar en la práctica
Antes de cambiar una política, documenta el dominio, los servicios que envían correo y los responsables técnicos. " Comprueba el resultado en DNS y utiliza los informes de autenticación para contrastar la configuración con el tráfico real.
Decisión recomendada
Prioriza primero la visibilidad y la corrección de fuentes legítimas. Después mide los resultados y endurece la política de forma progresiva.
Señal de alerta
Una fuente desconocida, un dominio desalineado o un cambio inesperado de volumen merece investigación antes de aplicar una política más estricta.
Aplicación local en Chile
La metodología puede adaptarse a empresas con operación en distintas ciudades. Este artículo se conecta con DMARC en Valparaíso y DMARC en Talca, donde se aborda el contexto local.
- DMARC en Valparaíso — Región de Valparaíso.
- DMARC en Temuco — Región de La Araucanía.
- DMARC en Puerto Montt — Región de Los Lagos.
- DMARC en Coquimbo — Región de Coquimbo.
Preguntas frecuentes
¿Este artículo reemplaza una auditoría DMARC?
No. Una guía sirve como referencia; una auditoría debe revisar el dominio, DNS, proveedores y tráfico real de la organización.
¿Debo cambiar mi política DMARC inmediatamente?
No necesariamente. La política debe corresponder al nivel de conocimiento y control que exista sobre las fuentes legítimas.
¿Se puede aplicar a Microsoft 365 o Google Workspace?
Sí, pero cada plataforma y proveedor externo puede requerir una configuración específica. Valida siempre la documentación del servicio antes de cambiar DNS.
Fuentes técnicas
¿Quieres revisar tu dominio?
ProtectionDMARC puede analizar SPF, DKIM, DMARC, fuentes de envío y reportes para ayudarte a definir un plan de implementación.
Solicitar evaluación DMARC →