Inicio / Guías / DMARC quarantine vs reject: cuál elegir y cómo migrar entre políticas

DMARC quarantine vs reject: cómo elegir la política adecuada para tu dominio

4,2 · 94 valoraciones
· Actualizado el 24 de agosto de 2025

Comparativa práctica entre DMARC p=quarantine y p=reject: cuándo usar cada política, cómo migrar con pct, riesgos típicos y cómo validar la transición.

DMARC quarantine vs reject: cuál elegir y cómo migrar entre políticas

Una vez tu dominio tiene SPF y DKIM correctos y has pasado un periodo razonable en p=none revisando los reportes RUA, llega el momento de aplicar enforcement. La política DMARC ofrece dos niveles reales de protección: p=quarantine y p=reject. La duda no suele ser cuál es “más segura” (ambas funcionan), sino cuál encaja con tu realidad operativa y cómo migrar entre ellas sin romper la entrega de mensajes legítimos.

Qué hace cada política

p=quarantine indica al receptor que los mensajes que fallen DMARC deben tratarse como sospechosos. Lo habitual es que se entreguen, pero a la carpeta de spam o a una cuarentena específica. El usuario sigue pudiendo recuperarlos manualmente.

p=reject indica al receptor que rechace en SMTP los mensajes que fallen DMARC. El emisor recibe un bounce 550 y el mensaje no se entrega ni siquiera al spam.

En la práctica, los principales receptores aplican estas políticas con bastante consistencia:

PolíticaGmailMicrosoft 365Yahoo
quarantineSpamQuarantine corporativa o spamSpam
reject550 reject en SMTP550 reject en SMTP550 reject en SMTP

Cuándo elegir quarantine

p=quarantine es la elección razonable cuando:

  • Tienes un inventario de orígenes de envío grande y poco controlado.
  • Los reportes muestran fallos esporádicos que aún no entiendes del todo.
  • Tu organización tiene reenvíos automáticos a listas, alias, etc., que pueden romper SPF.
  • Te preocupa más limitar el daño que el bloqueo absoluto: prefieres que un email mal autenticado vaya a spam antes que se rechace.

Una opción intermedia muy útil es publicar p=quarantine con un porcentaje bajo:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]; ruf=mailto:[email protected]

Esto aplica la política solo al 10 % del tráfico fallido, y el 90 % restante se sigue tratando como p=none. Es la forma más conservadora de empezar a hacer enforcement.

Cuándo elegir reject

p=reject es la política correcta cuando:

  • El inventario de orígenes de envío está completo y todos firman DKIM o pasan SPF alineado.
  • Los reportes RUA muestran tráfico fallido residual claramente atribuible a abuso.
  • Tu marca está siendo activamente suplantada y necesitas cortar al primer salto.
  • Cumples requerimientos sectoriales (banca, sector público) que exigen política estricta.
  • Tu dominio no se usa para envío y quieres declararlo nulo (p=reject puro sobre un parking domain).

Para dominios que no envían correo nunca, es buena práctica publicar:

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

Junto a un SPF de tipo v=spf1 -all y un MX nulo. Así declaras de forma técnica que ese dominio no debería emitir correo bajo ningún concepto.

El parámetro pct y la transición progresiva

pct es el control fino para subir la temperatura sin sobresaltos. Acepta un valor entre 0 y 100 (por defecto 100) y solo afecta a quarantine y reject.

Una secuencia recomendable cuando el inventario está limpio:

  1. p=reject; pct=25.
  2. p=reject; pct=100.

En cada paso, comprueba en los reportes que el conteo de mensajes legítimos rechazados o cuarentenados sigue siendo cero.

Política de subdominios: sp= y los casos límite

DMARC distingue entre la política del dominio organizativo (p=) y la de los subdominios (sp=). Si no se especifica sp=, los subdominios heredan p=. Esto suele ser deseable cuando:

  • No usas subdominios activos y quieres bloquear cualquier suplantación de info.tudominio.com.
  • Todos tus subdominios envían con el mismo nivel de control.

Pero hay casos en los que conviene desacoplarlas:

  • Tu dominio principal (tudominio.com) está limpio, pero tienes un subdominio (marketing.tudominio.com) gestionado por una herramienta externa con peor autenticación.
  • Quieres p=reject para el corporativo y sp=quarantine para los demás.

Ejemplo:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

Adkim y aspf: alineamiento estricto vs relaxed

Por defecto, DMARC aplica alineamiento “relaxed”, lo que significa que news.tudominio.com se considera alineado con tudominio.com. En modo “strict”, el dominio debe coincidir literalmente.

adkim=s   # alineamiento DKIM strict
aspf=s    # alineamiento SPF strict

Strict tiene sentido cuando:

  • Quieres bloquear cualquier subdominio no controlado.
  • Tu marca tiene un valor especial y quieres minimizar la zona gris.

Para la mayoría de organizaciones, mantener relaxed (el valor por defecto) es lo razonable.

Riesgos y rollbacks

Los problemas más habituales al endurecer DMARC:

Reenvíos automáticos rotos

Cuando un usuario reenvía un correo desde tudominio.com hacia una lista de distribución, SPF se rompe (porque la IP de salida ya no es la tuya). Si DKIM tampoco se mantiene, el mensaje fallará DMARC en el destino final. ARC ayuda parcialmente, pero no lo soluciona del todo. Es uno de los motivos para no saltar directamente a reject.

Servicios olvidados

Una factura mensual emitida desde un sistema legacy que nadie autenticó puede empezar a rebotar tras pasar a reject. Solución: catalogar todo en la fase de monitorización.

Errores en SPF tras añadir un nuevo proveedor

Olvidar incluir un nuevo proveedor en el SPF (o superar el límite de 10 lookups) provoca fallos masivos cuando la política está en reject. Por eso es prudente nunca tocar SPF sin antes bajar pct temporalmente o mover la política a quarantine.

Rollback rápido

Si detectas un incidente, el cambio más rápido es publicar de nuevo p=quarantine; pct=10 o p=none. La propagación DNS depende de tu TTL: para registros DMARC, un TTL bajo (300-600 segundos) durante la fase de transición es razonable; cuando el dominio esté estable, puedes subirlo a 3600 o más.

Cómo validar el cambio

Tras cada paso de pct, verifica:

  1. Reportes RUA del último periodo. Conteo de fails que pasaron a quarantine o reject debe estabilizarse.
  2. Cabeceras de mensajes propios. Busca Authentication-Results en correos enviados a Gmail/Outlook personales: debe aparecer dmarc=pass.
  3. Volumen de quejas y bounces. Un pico anómalo tras el cambio es señal de origen no controlado todavía.
  4. Reglas internas. Si tu organización tiene reglas en el MX corporativo, asegúrate de que no marcan duplicadamente.

Cuándo conviene contratar un parser de reportes

Mientras estés en p=none o p=quarantine; pct=10 con un dominio mediano, puedes vivir con scripts caseros que extraigan los XML, los descompriman y agreguen por IP. Cuando el volumen mensual de reportes sube de unos pocos megas a cientos, conviene una herramienta dedicada por:

  • Normalización de formatos.
  • Resolución inversa automática de IPs.
  • Visualización temporal de fallos.
  • Alertas ante nuevas IPs no inventariadas.

No hay un punto de corte universal: depende de cuántos servicios envían en tu nombre y de tu tolerancia al ruido.

Recursos relacionados

Si quieres profundizar, prueba estas herramientas gratuitas: Domain Health, mail tester, validador SPF y validador DMARC.

¿Necesitas que alguien lleve tu canal de email entero? Abalola Mail es la agencia de email marketing en España de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.

Preguntas frecuentes

¿Cuándo conviene usar p=quarantine?
Cuando todavía existe riesgo de fallos esporádicos en algún flujo legítimo y prefieres que esos mensajes vayan a spam y no se rechacen. Es la política recomendada como paso intermedio antes de reject.
¿Cuándo pasar a p=reject?
Cuando llevas semanas en quarantine pct=100 con cero fallos legítimos en los reportes y todos tus orígenes de envío están alineados con SPF o DKIM.
¿Qué papel juega pct en la transición?
El parámetro pct aplica la política a un porcentaje de mensajes que fallan. Permite migrar gradualmente: pct=10, 25, 50 y 100 antes de subir a la siguiente política.
¿Reject es siempre mejor que quarantine?
Reject ofrece máxima protección frente a spoofing pero también máxima exposición a errores propios. Si la operación es compleja con muchos remitentes, quarantine puede ser un equilibrio sano permanente.
¿Qué pasa con los mailing lists si paso a reject?
Los mailing lists que reescriben From y rompen DKIM dejan de entregar tus mensajes. Para mitigarlo, usa subdominios separados y considera el soporte de ARC en los receptores grandes.
¿Puedo pasar directamente a p=reject si mi dominio nunca ha enviado correo?
Sí. Para dominios "parking" sin envío, `p=reject` desde el primer día es lo recomendable y no rompe nada.
¿Cuánto tiempo conviene estar en quarantine antes de pasar a reject?
Lo razonable son entre 2 y 6 semanas con `pct=100` y reportes limpios. Si encuentras incidencias, vuelve a bajar `pct` antes de avanzar.