DMARC quarantine vs reject: qué política usar (y cuándo cambiar)

Un registro DMARC sin una política que se aplique es como una cámara de seguridad que no graba. La etiqueta p= es donde DMARC empieza de verdad a proteger tu dominio, y la elección entre quarantine y reject importa más de lo que la mayoría de los remitentes cree.

Esta guía explica qué hace cada política, cuándo usar cuál y el camino más seguro de p=none a la aplicación.

Las tres políticas DMARC

DMARC admite tres valores para la etiqueta p=:

Política	Qué pasa con el correo que falla DMARC	Cuándo usarla
p=none	Se entrega normalmente; se te reporta	Día 1 (solo visibilidad)
p=quarantine	Se entrega en la carpeta de spam	Fase de transición
p=reject	Se rebota (no se entrega)	Estado final: protección completa

La etiqueta pct= de RFC 7489 puede aplicar la política a un porcentaje del correo. Por ejemplo, p=quarantine; pct=25 les pide a los receptores que pongan en cuarentena el 25% del correo que falla y dejen pasar el resto. El estándar actual, RFC 9989 (mayo de 2026), elimina pct y conserva solo su uso de prueba como t=y, así que trata los porcentajes como una petición que muchos receptores aplican de forma flexible.

Qué hace realmente p=quarantine

El correo que falla DMARC se entrega en la carpeta de spam del destinatario. El destinatario todavía puede encontrar y recuperar el mensaje, lo que sirve mientras sigues descubriendo remitentes legítimos que aún no están alineados.

Ventajas:

• Impide que la mayor parte del correo suplantado llegue a la bandeja de entrada.
• Saca a la luz los fallos de alineación sin rebotar correo real.
• Poco riesgo de dañar correo legítimo durante la transición.

Desventajas:

• Algunos proveedores de correo manejan la cuarentena de forma inconsistente (Microsoft es más estricto que Gmail).
• No impide que el destinatario rescate a mano el correo suplantado.
• Solo da una protección parcial de la marca.

Qué hace realmente p=reject

El servidor del destinatario rechaza directamente el correo que falla DMARC. Nunca llega a ningún lado. El remitente recibe un rebote.

Ventajas:

• La protección más fuerte posible contra la suplantación.
• Te hace elegible para BIMI (logo visible en los clientes de correo compatibles).
• Te alinea con las recomendaciones de Gmail/Yahoo para remitentes masivos.

Desventajas:

• Cualquier remitente legítimo que no esté bien alineado desaparece sin aviso.
• Los errores de configuración hacen rebotar correo real de clientes.
• Exige descubrir y alinear primero a cada remitente de shadow IT.

Cuándo elegir cuál

Usa este árbol de decisión:

• Acabas de publicar DMARC → p=none con reportes rua. Quédate aquí hasta que tus informes agregados muestren que el 99% o más del correo legítimo se alinea.
• Los informes agregados muestran >99% de alineación de los remitentes legítimos, con algunos desconocidos → p=quarantine; pct=10. Revisa cada semana y sube el pct de forma gradual.
• Los informes agregados muestran 100% de alineación del correo legítimo, sin preocupaciones de suplantación → p=quarantine; pct=100.
• Quieres la máxima protección Y cada remitente legítimo está verificado y alineado → p=reject; pct=100.
• Eres un banco, una empresa de salud, un organismo de gobierno o cualquier marca que suplantan con frecuencia → pasa a p=reject sin demora. El riesgo del daño por suplantación supera el riesgo de un error de configuración.

El camino seguro de p=none a p=reject

El calendario estándar que evita desastres:

Semana	Política	Qué hacer
1-4	p=none	Publica el registro, analiza los informes agregados, identifica a todos los remitentes
5-6	p=none	Alinea a los remitentes sin alinear (dominios propios, CNAME del ESP)
7-8	p=quarantine; pct=10	Monitorea, corrige cualquier fallo nuevo
9-10	p=quarantine; pct=50	Lo mismo
11-12	p=quarantine; pct=100	Lo mismo
13-16	p=reject; pct=10, luego 50, luego 100	Rampa final

Total: unos 4 meses desde la publicación de DMARC hasta la aplicación completa de p=reject. Se puede ir más rápido, pero aumenta el riesgo de perder correo legítimo.

Lo que te dicen los informes agregados

Los informes agregados rua de DMARC llegan a diario como archivos XML adjuntos, de cada proveedor receptor. Muestran:

• Qué IP enviaron correo diciendo ser de tu dominio.
• Cuántos mensajes se alinearon con SPF, con DKIM, con los dos o con ninguno.
• Qué disposición aplicó el receptor (none/quarantine/reject).

Convierte esto en un panel, porque el XML en bruto es ilegible a escala. El analizador de informes DMARC gratuito lee los informes que abres, en tu navegador.

Errores comunes que rompen el correo real

• Pasar directo a p=reject sin analizar los informes agregados. Las rondas de descubrimiento siempre encuentran remitentes legítimos que habías olvidado.
• Olvidar los subdominios. Un p=reject en el dominio raíz también cubre sus subdominios, salvo que una etiqueta sp= diga otra cosa, así que un sp=none olvidado exime en silencio a todos los subdominios.
• Configuración del ESP sin alinear. Tu ESP firma DKIM con su propio dominio por defecto; tienes que configurar un dominio DKIM propio para la alineación.
• Herramientas de automatización de marketing. Muchas herramientas SaaS envían "desde" tu dominio a través de SendGrid/Postmark/etc. Cada una se tiene que alinear por separado.

p=quarantine vs la cuarentena del filtro de spam

Un punto que confunde: p=quarantine le dice al servidor receptor que trate el correo que falla como sospechoso. El receptor aplica además su propio filtrado de spam. Así que el correo que falla DMARC con p=quarantine puede terminar en spam o ser castigado todavía más. Los dos filtros se suman.

Preguntas frecuentes

¿Es seguro usar p=reject? Sí, una vez que verificaste que cada remitente legítimo está alineado. El riesgo es aplicarla antes de conocer a todos los remitentes.

¿Qué hace pct=0? En la práctica equivale a p=none para el correo nuevo. Un truco de la vieja escuela para probar cambios de política sin afectar la entrega. RFC 9989 lo reemplaza con t=y y señala que los valores de pct distintos de 0 y 100 se aplicaban de forma inconsistente de un receptor a otro.

¿p=reject afecta al correo de las listas de distribución? Sí. Es la causa más común de pérdida de correo legítimo después de aplicar la política. ARC (Authenticated Received Chain) ayuda a las listas de distribución a conservar la alineación. La mayoría de las listas grandes ya admiten ARC; revisa la tuya.

¿La política de subdominios debe coincidir con la del raíz? Normalmente sí. Define sp=reject de forma explícita. Si tienes subdominios sin autenticar, ponlos temporalmente en sp=quarantine y corrígelos.

¿Necesito DMARC si tengo SPF y DKIM? Sí. SPF y DKIM verifican mecanismos individuales; solo DMARC aplica la alineación y te da reportes. Gmail y Yahoo exigen DMARC a los remitentes masivos.

En resumen

p=none es para aprender. p=quarantine es para la transición. p=reject es para proteger. Saltar directo a p=reject es la forma más común de perder correo real de clientes. Dedícale los cuatro meses. La protección vale la pena hacerla bien.

👉 Sigue con: Cómo corregir SPF, DKIM y DMARC · Requisitos de remitentes de Gmail y Yahoo · Prueba el generador de DMARC

Fuentes

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), el estándar DMARC actual: las políticas p, sp y np, la marca de prueba t y por qué se eliminó pct.
• RFC 7489: DMARC (2015 informational version), la versión de 2015 que definió pct y la regla de que p aplica a los subdominios cuando falta sp.
• RFC 8617: The Authenticated Received Chain (ARC) Protocol, cómo los intermediarios, como las listas de distribución, transmiten los resultados de autenticación que de otro modo harían fallar DMARC.
• Set up DMARC (Ayuda de Google Workspace), la recomendación de Google de empezar con p=none y pasar a la aplicación de forma gradual mientras lees los informes.