Elija la política DMARC correcta
para su dominio
La política DMARC (etiqueta p=) indica a los servidores de correo receptores qué hacer con los mensajes que fallan la autenticación DMARC. Hay tres opciones — none, quarantine y reject — y cada dominio debe seguir el mismo camino desde la supervisión hasta la aplicación completa.
Según RFC 7489, la política se aplica solo cuando AMBAS alineaciones SPF y DKIM fallan. Si cualquiera pasa y se alinea, el mensaje pasa DMARC independientemente de la política.
none, quarantine, reject
Cada política es un paso en el viaje de aplicación. Comience con visibilidad, construya confianza, luego aplique.
p=none Solo supervisar Vea todo. No bloquee nada.
Los servidores de correo receptores no toman ninguna acción de aplicación sobre los mensajes que fallan DMARC. Aún envían informes agregados al propietario del dominio, proporcionando visibilidad completa de cada fuente que envía correo desde el dominio.
v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com - Cero riesgo para la entrega de correo legítimo
- Visibilidad completa de todas las fuentes de envío vía informes agregados
- Primer paso requerido — debe supervisar antes de aplicar
- Satisface el requisito mínimo de Google/Yahoo para remitentes masivos
- No proporciona protección contra suplantación o phishing
- Los atacantes aún pueden enviar correo como su dominio y será entregado
- No mejora la reputación del dominio con los receptores
Siempre comience aquí. Despliegue p=none con informes rua= y supervise durante al menos 90 días. Use esta fase para identificar cada remitente legítimo, corregir su configuración SPF/DKIM y confirmar la alineación antes de pasar a la aplicación.
El correo falla la alineación SPF + DKIM
El receptor verifica la política DMARC: p=none
Correo entregado normalmente a la bandeja de entrada
Informe agregado enviado al propietario del dominio
p=quarantine Enviar a spam El correo sospechoso va a spam. El correo legítimo sigue fluyendo.
Los mensajes que fallan DMARC se envían a la carpeta de spam o correo no deseado del destinatario. El mensaje aún existe — los destinatarios pueden encontrarlo si lo buscan — pero se marca claramente como sospechoso. Este es el paso de aplicación con red de seguridad.
v=DMARC1; p=quarantine; rua=mailto:dmarc@ejemplo.com - Protección activa — los mensajes suplantados salen de la bandeja de entrada
- Red de seguridad para remitentes mal configurados (los mensajes no se pierden)
- Señala a los receptores que toma la seguridad del correo en serio
- Buen punto intermedio durante la transición de aplicación
- Los remitentes legítimos con autenticación rota van a spam
- Los destinatarios pueden no revisar carpetas de spam, causando correos perdidos
- Algunos receptores tratan quarantine como reject en la práctica
Después de más de 90 días en p=none con todos los remitentes legítimos identificados y pasando la autenticación. Pase aquí solo cuando sus informes agregados muestren alineación SPF/DKIM consistente para cada fuente autorizada.
El correo falla la alineación SPF + DKIM
El receptor verifica la política DMARC: p=quarantine
Correo enviado a la carpeta de spam/correo no deseado
Informe agregado enviado al propietario del dominio
p=reject Bloquear completamente Aplicación completa. El correo suplantado nunca llega.
Los mensajes que fallan DMARC se rechazan a nivel SMTP — el destinatario nunca los ve y el servidor de envío recibe un rebote. Esta es la protección más fuerte y el objetivo final para cada dominio.
v=DMARC1; p=reject; rua=mailto:dmarc@ejemplo.com - Máxima protección contra suplantación de dominio y phishing
- Los atacantes no pueden entregar correo suplantando su dominio
- Señal de reputación de dominio más alta para servidores receptores
- Califica para BIMI (Brand Indicators for Message Identification)
- Los remitentes legítimos mal configurados se bloquean completamente — ni siquiera spam
- Las cadenas de reenvío de correo que rompen la alineación fallarán
- Requiere supervisión exhaustiva antes del despliegue
Después de más de 90 días en p=quarantine con informes agregados limpios. Todos los remitentes legítimos deben pasar consistentemente la alineación SPF o DKIM. El viaje completo de p=none a p=reject típicamente toma de 9 a 18 meses.
El correo falla la alineación SPF + DKIM
El receptor verifica la política DMARC: p=reject
Correo rechazado a nivel SMTP — nunca entregado
Informe agregado enviado al propietario del dominio
El camino hacia la aplicación completa
Cada dominio sigue la misma progresión. La línea temporal depende de la complejidad — más remitentes significa más tiempo para configurar. Planifique de 9 a 18 meses desde el primer registro hasta p=reject completo.
p=none Fase 1: Supervisar
Mínimo 90+ díasPublique el registro DMARC con p=none e informes rua=. Analice los informes agregados para identificar cada fuente que envía correo desde su dominio. Corrija SPF y DKIM para todos los remitentes legítimos.
p=quarantine Fase 2: Cuarentena
Mínimo 90+ díasPase a p=quarantine. Comience con pct=10 y aumente gradualmente. Supervise los informes para cualquier remitente recién afectado. Corrija los problemas de autenticación restantes.
p=reject Fase 3: Rechazar
ContinuoAvance a p=reject con plena confianza de que todo el correo legítimo pasa. Continúe supervisando — nuevos remitentes, cambios de IP y actualizaciones de proveedores pueden romper la autenticación en cualquier momento.
Plazo total: 9-18 meses
Las organizaciones con pocos remitentes pueden alcanzar p=reject más rápido. Los entornos complejos con docenas de servicios externos toman más tiempo. La clave son decisiones basadas en datos — nunca omita las fases de supervisión.
La etiqueta pct=:
aplicación con red de seguridad
La etiqueta pct= controla qué porcentaje de mensajes fallidos reciben la acción de aplicación. Los mensajes fuera del porcentaje se tratan como si la política fuera p=none. Esto le permite desplegar gradualmente la aplicación mientras supervisa problemas.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@ejemplo.com El 25% de los mensajes fallidos se ponen en cuarentena. El 75% restante se entrega normalmente.
pct=10 Aplicar la política al 10% de los mensajes fallidos. El 90% restante se trata como p=none. Bueno para pruebas iniciales.
2-4 semanaspct=25 Aumentar al 25%. Supervise los informes agregados para cualquier remitente legítimo recién afectado.
2-4 semanaspct=50 La mitad de los mensajes fallidos ahora reciben la acción de aplicación. La mayoría de los problemas se detectan en esta etapa.
2-4 semanaspct=100 Aplicación completa. Todos los mensajes que fallan la alineación DMARC reciben la acción de la política publicada. Este es el valor predeterminado cuando no se especifica pct=.
Permanentev=DMARC1; p=reject; sp=quarantine; rua=... El dominio principal está completamente aplicado. Los subdominios están en cuarentena mientras se configuran.
La etiqueta sp=: control de subdominios
La etiqueta sp= establece una política DMARC separada para subdominios. Sin ella, los subdominios heredan la política p= del dominio principal. Esto es útil cuando su dominio principal está listo para la aplicación pero los subdominios necesitan más tiempo.
- sp=none — los subdominios se supervisan mientras se configuran
- sp=quarantine — los subdominios reciben aplicación intermedia
- sp=reject — los subdominios tienen aplicación completa (igual que no tener sp= cuando p=reject)
- Omitir sp= — los subdominios heredan la política p=
Errores comunes de política DMARC
Estos son los errores que vemos con más frecuencia en los despliegues DMARC. Cada uno de ellos es prevenible con supervisión adecuada y un enfoque por fases.
Aplicar demasiado rápido
Saltar a p=reject sin al menos 90 días en p=none causa que el correo legítimo sea bloqueado. Las plataformas de marketing, herramientas CRM y sistemas de tickets a menudo fallan DMARC si no se configuran correctamente.
Sin supervisión después de la aplicación
DMARC no es configurar y olvidar. Nuevas fuentes de envío, cambios de IP y actualizaciones de proveedores pueden romper la autenticación en cualquier momento. La supervisión continua detecta problemas antes de que afecten la entrega.
Ignorar remitentes externos
Cada servicio que envía correo en su nombre — Mailchimp, HubSpot, Salesforce, Zendesk — debe tener includes SPF o firma DKIM configurados. Faltar incluso uno causa fallos en la aplicación.
Olvidar subdominios
Sin una etiqueta sp=, los subdominios heredan la política del dominio principal. Pero si aplica p=reject sin verificar los remitentes de subdominios, puede bloquear correo legítimo de subdominios. Establezca sp= explícitamente.
Publicar sin rua=
Un registro DMARC sin informes rua= es volar a ciegas. No tiene visibilidad de los resultados de autenticación, no puede detectar suplantación y no tiene datos para tomar decisiones de aplicación.
Usar alineación relajada cuando se necesita estricta
La alineación relajada (predeterminada) permite que mail.ejemplo.com se alinee con ejemplo.com. Para la mayoría de las organizaciones esto es correcto, pero los dominios de alta seguridad pueden necesitar alineación estricta para prevenir el abuso de subdominios.
Preguntas sobre políticas DMARC
¿Cuál es la mejor política DMARC?
La mejor política DMARC es p=reject, que proporciona la máxima protección contra la suplantación de dominio. Sin embargo, debe alcanzar p=reject a través de un enfoque por fases: comience en p=none (supervise durante más de 90 días), pase a p=quarantine (más de 90 días), luego aplique p=reject. Saltar directamente a reject causa que el correo legítimo sea bloqueado.
¿Cuánto tiempo debo permanecer en p=none antes de aplicar?
Permanezca en p=none durante un mínimo de 90 días — un trimestre completo. Esto le da suficientes datos de informes agregados para identificar todas las fuentes de envío legítimas y corregir su autenticación. Algunas organizaciones con muchos remitentes externos pueden necesitar más tiempo. El viaje completo a p=reject típicamente toma de 9 a 18 meses.
¿Proporciona p=quarantine suficiente protección?
La cuarentena es un paso significativo sobre p=none porque los mensajes suplantados ya no llegan a la bandeja de entrada. Sin embargo, aún existen en la carpeta de spam. Para protección completa, p=reject es el objetivo — previene que los mensajes suplantados se entreguen en absoluto. Algunos marcos de cumplimiento (como PCI DSS v4.0) requieren específicamente p=reject.
¿Qué sucede si configuro p=reject y un remitente legítimo falla?
El correo del remitente legítimo será rechazado — el destinatario no lo recibirá. Por eso la supervisión en p=none y p=quarantine es esencial antes de aplicar. Use la etiqueta pct= para desplegar gradualmente la aplicación (pct=10 para comenzar) para detectar configuraciones incorrectas antes de que afecten todo el correo.
¿Puedo tener políticas diferentes para mi dominio y subdominios?
Sí. La etiqueta sp= (política de subdominios) le permite establecer una política separada para subdominios. Por ejemplo, puede aplicar p=reject en su dominio principal mientras mantiene sp=none en subdominios que aún se están configurando. Si sp= no se establece, los subdominios heredan la política del dominio principal.
¿Qué es la etiqueta pct= y cómo debo usarla?
La etiqueta pct= controla qué porcentaje de mensajes fallidos reciben la acción de aplicación. Con pct=10, solo el 10% de los mensajes fallidos se ponen en cuarentena o se rechazan — el resto se tratan como p=none. Aumente gradualmente de 10 a 25 a 50 a 100 durante varias semanas para transicionar de forma segura a la aplicación completa.
Vea su política DMARC actual en acción
Prueba gratuita — supervise informes agregados, identifique remitentes y planifique su viaje de aplicación.
Prueba gratuitaLos equipos confían en DMARC Report para la aplicación
Rated 4.8/5 on G2 · 469 verified reviews
Zunaid K.
Director
"Essential tool for email delivery"
This tool helps us to implement DMARC reporting for our domains in an easy to use manner.
Verified User in Information Technology and Services
"Best security tool for your own domains"
The weekly reports help me a lot to analyze quickly the emails sent from my domains and that gives me peace of mind.
Larry H.
Research & Development Manager
"Good tool to buy"
I have used many tools for monitoring DMARC reports. But DMARC Report is a good tool to use. It helps avoid sending emails to spam.