DMARC quarantine vs reject: cómo elegir la política adecuada para tu dominio
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.
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ítica | Gmail | Microsoft 365 | Yahoo |
|---|---|---|---|
quarantine | Spam | Quarantine corporativa o spam | Spam |
reject | 550 reject en SMTP | 550 reject en SMTP | 550 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=rejectpuro 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:
p=reject; pct=25.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=rejectpara el corporativo ysp=quarantinepara 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:
- Reportes RUA del último periodo. Conteo de fails que pasaron a
quarantineorejectdebe estabilizarse. - Cabeceras de mensajes propios. Busca
Authentication-Resultsen correos enviados a Gmail/Outlook personales: debe aparecerdmarc=pass. - Volumen de quejas y bounces. Un pico anómalo tras el cambio es señal de origen no controlado todavía.
- 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.