Simulador de avance de política DMARC — camino seguro hacia el rechazo

Su camino seguro de DMARC p=nonea p=reject

Simulador gratuito de avance de la política DMARC. Ingrese su dominio y vea la ruta exacta de despliegue con riesgo minimizado, desde el monitoreo hasta la aplicación completa — con la progresión pct= recomendada y el tiempo de permanencia en cada etapa.

¿Cómo funciona el avance de la política DMARC?

La aplicación de DMARC es el proceso de avanzar tu política desde p=none (solo monitoreo) a p=quarantine (los correos fallidos se envían a la carpeta de spam) y luego a p=reject (los correos fallidos se bloquean por completo). Cada paso debe introducirse con cuidado — un salto agresivo directo a p=reject sin confirmar que todos los remitentes legítimos están alineados provocará fallos inmediatos en la entrega de correos de nómina, facturación, restablecimiento de contraseñas y campañas de marketing.

El plazo típico es de 10 a 16 semanas desde la publicación de p=none hasta alcanzar p=reject; pct=100. Las grandes empresas con ecosistemas de envío complejos suelen tardar de 4 a 6 meses debido a la cantidad de ESP de terceros, plataformas de marketing y aplicaciones heredadas que deben inventariarse y alinearse. Skysnag Protect reduce esto a 30 días al automatizar el descubrimiento y la alineación de remitentes.
Técnicamente sí, pero casi nadie debería hacerlo. Pasar directamente de p=none a p=reject sin visibilidad a través de informes agregados garantiza que algunos correos legítimos — normalmente un sistema de RR. HH. poco conocido, un proveedor externo de nómina o una herramienta interna — fallarán en la entrega. El despliegue gradual existe para detectar estos casos antes de que provoquen un incidente en producción.
La etiqueta pct= indica a los destinatarios que apliquen la política DMARC solo a ese porcentaje de los correos que fallan. Por ejemplo, p=quarantine; pct=10 pone en cuarentena solo el 10 % de los mensajes fallidos — el 90 % restante vuelve a la política anterior (p=none). Este es el mecanismo clave para un despliegue seguro, permitiendo detectar casos límite con un impacto limitado antes de avanzar.
Los problemas más comunes son: remitentes de terceros mal configurados a nivel del ESP (firmas DKIM ausentes), registros SPF que superan el límite de 10 consultas (PermError), correos reenviados a través de listas de distribución sin firma ARC y aplicaciones heredadas que falsifican el encabezado From:. Corrige estos problemas durante la fase de monitoreo antes de avanzar a quarantine.
Sí. SPF no sobrevive al reenvío de correos porque el remitente del sobre SMTP cambia cuando el mensaje pasa por listas de correo, alias o Google Groups. Las firmas DKIM sí sobreviven al reenvío porque son firmas criptográficas aplicadas al propio mensaje. Tanto SPF como DKIM deben estar activos y alineados para una aplicación sólida.
p=quarantine indica a los destinatarios que filtren los correos que fallan hacia la carpeta de spam. p=reject indica a los destinatarios que rechacen esos correos con un error SMTP — el destinatario nunca los ve. Reject ofrece una protección más estricta y es el estado requerido para la elegibilidad de BIMI y la marca de verificación azul de Gmail.