Una política DMARC configurada en p=none se denomina comúnmente modo de monitoreo.
Le indica a los servidores de correo receptores que evalúen la autenticación DMARC, generen informes cuando se solicite, pero no apliquen ninguna acción de aplicación DMARC cuando los mensajes fallen. En la práctica, esto significa que los mensajes que fallan DMARC no son rechazados ni puestos en cuarentena debido a tu política DMARC.
Esta configuración es útil, pero a menudo se malinterpreta.
p=none no es protección. Es visibilidad.
Las organizaciones la utilizan para descubrir quién está enviando correo electrónico en nombre de su dominio, qué sistemas están pasando la autenticación, qué proveedores están fallando en la alineación y dónde pueden estar ocurriendo ya intentos de suplantación.
Usado correctamente, p=none es la fase de diagnóstico que prepara un dominio para la aplicación. Usado indefinidamente, se convierte en una postura de solo visibilidad que deja el dominio expuesto a la suplantación de dominio exacto.
I. Qué Hace Realmente DMARC p=none
Cuando publicas un registro DMARC con p=none, los servidores de correo receptores aún pueden realizar la evaluación completa de DMARC.
Verifican si el mensaje pasa SPF o DKIM, y si al menos uno de esos identificadores autenticados se alinea con el dominio From visible.
Un mensaje pasa DMARC solo cuando al menos una de las siguientes condiciones es verdadera:
- SPF pasa y el dominio autenticado por SPF se alinea con el dominio From visible.
- DKIM pasa y el dominio firmante DKIM se alinea con el dominio From visible.
Que SPF pase solo no es suficiente. Que DKIM pase solo no es suficiente. La alineación es lo que conecta la autenticación con el dominio que ve el destinatario.
Con p=none, se instruye al receptor a no aplicar una acción de política DMARC cuando falla la autenticación. Si se configura el reporte agregado, el receptor puede enviar informes DMARC mostrando los resultados de autenticación que observó.
Esa distinción es importante.
Un dominio con p=none no es lo mismo que un dominio sin registro DMARC. El dominio está siendo evaluado y puede recibir informes. Pero aún no está protegido por la aplicación de DMARC.
II. Por Qué las Organizaciones Comienzan con p=none
La mayoría de las organizaciones no comprenden completamente su ecosistema de correo electrónico antes de comenzar con DMARC.
Eso es normal.
El correo electrónico a menudo sale de la organización a través de más sistemas de los esperados:
- Microsoft 365 o Google Workspace
- Plataformas de automatización de marketing
- Sistemas CRM
- Plataformas de tickets de soporte
- Proveedores de correo electrónico transaccional
- Sistemas de facturación y cobro
- Plataformas de RRHH
- Herramientas regionales
- Aplicaciones heredadas
- Proveedores de terceros
- Servicios de TI en la sombra
Si un dominio pasa directamente a p=quarantine o p=reject antes de que estas fuentes sean identificadas y alineadas, el correo legítimo puede fallar.
Por eso es importante el modo de monitoreo.
p=none da a los equipos de seguridad y TI una forma segura de observar el comportamiento de autenticación del mundo real antes de que comience la aplicación.
Durante esta fase, los informes DMARC pueden revelar:
- Remitentes legítimos que están correctamente autenticados
- Remitentes legítimos que fallan la alineación SPF o DKIM
- Plataformas de terceros que envían sin la configuración adecuada
- Direcciones IP desconocidas usando el dominio
- Sistemas heredados que aún envían correo electrónico
- Subdominios que necesitan revisión separada
- Intentos de suplantación contra el dominio
- Registros SPF que se acercan a los límites de búsqueda DNS
El objetivo no es quedarse en p=none.
El objetivo es usar la visibilidad para preparar el dominio para la aplicación.
III. Comienza el Monitoreo DMARC de la Manera Correcta
Un registro de monitoreo DMARC estático básico puede verse así:
v=DMARC1; p=none; rua=mailto:[email protected]Este registro puede funcionar, pero solo si los informes son realmente recibidos, analizados, revisados y se actúa sobre ellos.
Ahí es donde muchas organizaciones fallan.
Los informes DMARC generalmente llegan como archivos XML. Pueden venir de muchos receptores, cubrir grandes volúmenes de mensajes y requieren análisis para identificar qué remitentes son legítimos, cuáles están mal configurados y cuáles no están autorizados.
Un registro estático sin monitoreo activo crea una falsa sensación de progreso.
El mejor enfoque es comenzar el monitoreo DMARC a través de Skysnag y obtener un registro DMARC administrado generado para tu dominio.
Comienza aquí:
https://app.skysnag.com/en/register/Skysnag ayuda a recopilar y analizar informes DMARC para que los equipos puedan identificar remitentes, corregir brechas de autenticación y avanzar hacia la aplicación con confianza.
IV. Qué Puede Salir Mal con p=none
El modo de monitoreo puede fallar silenciosamente si no se implementa correctamente.
Fallos en la Entrega de Informes
Si el buzón en la etiqueta rua= no puede recibir informes, la organización pierde visibilidad.
Las causas comunes incluyen:
- Dirección de informe incorrecta
- Límites de tamaño del buzón
- Filtrado o cuarentena de correos electrónicos de informes
- Problemas de autorización de destino de informe externo
- Nadie monitoreando el buzón de informes
- Adjuntos de informes bloqueados por herramientas de seguridad de correo
Esta es una razón por la que los informes DMARC manuales no escalan bien.
Si los informes no se están recopilando y revisando, p=none se convierte en un registro DNS con poco valor operativo.
Informes Incompletos
No todos los receptores envían informes agregados DMARC.
Los grandes proveedores de buzones comúnmente envían informes, pero los proveedores más pequeños, los sistemas heredados y algunas puertas de enlace empresariales pueden no hacerlo. Eso significa que los informes DMARC proporcionan visibilidad útil, pero no una vista global completa de cada mensaje.
Las organizaciones deben tratar los informes DMARC como una señal fuerte, no como un conjunto de datos perfecto.
Retraso en los Informes
Los informes agregados DMARC no son alertas en tiempo real.
Generalmente llegan después de que se procesan los mensajes, a menudo con un retraso. Esto significa que son excelentes para análisis de tendencias, descubrimiento de remitentes y planificación de aplicación, pero no deben tratarse como detección instantánea de phishing.
Resultados de Autenticación Malinterpretados
Un error común es tratar el paso de SPF o el paso de DKIM como paso de DMARC.
DMARC requiere alineación con el dominio From visible. Un proveedor de terceros puede pasar SPF usando su propio dominio, o firmar DKIM con su propio dominio, mientras aún falla la alineación DMARC para tu dominio.
Este es uno de los problemas más importantes a resolver antes de la aplicación.
V. Cuando p=none Te Deja Expuesto
p=none da visibilidad, pero no detiene la suplantación de dominio exacto.
Si un atacante envía un correo electrónico afirmando que proviene de tu dominio real y el mensaje falla SPF, DKIM y la alineación DMARC, tu política p=none le dice al receptor que no ponga en cuarentena ni rechace el mensaje debido a DMARC.
El proveedor receptor aún puede filtrar el mensaje usando sus propios sistemas de spam, phishing, reputación y seguridad. Pero tu política DMARC en sí misma no le está pidiendo al receptor que lo bloquee.
Eso crea una ventana de exposición real.
Los atacantes pueden intentar:
- Suplantación de dominio exacto
- Suplantación de ejecutivos
- Mensajes de facturas falsas
- Phishing de credenciales
- Fraude de pago a proveedores
- Alertas falsas de soporte o seguridad
- Abuso de subdominios no protegidos
Para un dominio que aún está en p=none, DMARC puede mostrar que estos intentos están ocurriendo. No impide que sean entregados.
VI. Por Qué Quedarse en p=none Demasiado Tiempo Es un Riesgo
Muchas organizaciones publican p=none, reciben informes y nunca avanzan.
Ese es el fallo más común.
La fase de monitoreo debe tener un propósito y un punto final definidos.
Si un dominio permanece en p=none durante meses o años, la organización puede tener visibilidad del abuso pero ninguna aplicación DMARC contra él.
Esa es una posición débil para cualquier dominio utilizado para:
- Comunicación con clientes
- Comunicación con empleados
- Facturación y facturas
- Restablecimiento de contraseñas
- Notificaciones de cuenta
- Alertas de seguridad
- Comunicación con proveedores
- Comunicación ejecutiva
- Flujos de trabajo regulados o de alta confianza
Para estos dominios, el monitoreo debe conducir a la acción.
VII. Cuándo p=none Puede Ser Apropiado
p=none es apropiado cuando una organización está comenzando con DMARC, descubriendo remitentes o validando correcciones de autenticación.
También puede ser útil para dominios recién adquiridos, entornos complejos o dominios donde las fuentes de correo electrónico aún se están mapeando.
Los usos válidos comunes incluyen:
- Implementación inicial de DMARC
- Descubrimiento de fuentes de correo electrónico
- Revisión de remitentes de terceros
- Pruebas de alineación SPF y DKIM
- Planificación de migración
- Evaluación de adquisición de dominios
- Revisión de sistemas heredados
- Validación previa a la aplicación
Pero p=none no debe convertirse en el estado final para dominios de envío importantes.
Para dominios en los que confían clientes, empleados o socios, el objetivo a largo plazo generalmente debe ser la aplicación a través de p=quarantine o p=reject, una vez que el correo legítimo esté correctamente alineado.
VIII. Pasar de p=none a la Aplicación
El camino desde el monitoreo hasta la aplicación debe basarse en evidencia.
Antes de pasar a la aplicación, confirma:
- Todos los remitentes legítimos están identificados.
- Los remitentes críticos pasan DMARC.
- Los proveedores de terceros están correctamente alineados.
- Los registros SPF no están excediendo los límites de búsqueda.
- DKIM está habilitado donde se necesita.
- Los subdominios están revisados.
- Los remitentes desconocidos están investigados.
- Los propietarios de negocio entienden el cambio.
- Los procedimientos de reversión están definidos.
- Los informes DMARC se monitorean activamente.
Una vez que se cumplan estas condiciones, las organizaciones pueden comenzar a mover dominios o subdominios seleccionados a la aplicación.
Un camino práctico de aplicación se ve así:
- Comienza con
p=nonepara el descubrimiento. - Remedia las fuentes legítimas que fallan la autenticación o alineación.
- Mueve subdominios de menor riesgo o bien entendidos a
p=quarantine. - Monitorea el impacto y resuelve los problemas restantes.
- Mueve dominios maduros y críticos para el negocio a
p=quarantine. - Mueve a
p=rejectcuando la confianza sea alta.
Este enfoque escalonado es más seguro que cambiar todos los dominios a la vez.
También evita depender de la implementación basada en porcentajes, que ya no es el modelo preferido para los programas actuales conscientes de DMARC.
IX. Malentendidos Comunes sobre p=none
«p=none significa que estamos protegidos»
Falso.
p=none significa que estás monitoreando. No instruye a los receptores a poner en cuarentena o rechazar mensajes que fallan DMARC.
«SPF y DKIM son suficientes»
No siempre.
SPF y DKIM solo se vuelven útiles para DMARC cuando se alinean con el dominio From visible. Sin alineación, un mensaje puede pasar SPF o DKIM y aún fallar DMARC.
«Los informes nos dicen todo»
No.
Los informes DMARC son útiles, pero están retrasados, son incompletos y dependen de que los receptores los envíen.
No muestran cada mensaje globalmente, y los informes agregados no incluyen el contenido del mensaje.
«Podemos quedarnos en p=none para siempre»
Técnicamente sí, pero desde el punto de vista de la seguridad, eso significa que el dominio permanece en modo de solo monitoreo.
Para dominios importantes, p=none debe ser una fase, no una estrategia permanente.
«La aplicación romperá el correo electrónico»
La aplicación puede romper el correo electrónico legítimo si se implementa sin descubrimiento.
Por eso existe el monitoreo.
El propósito de p=none es encontrar y corregir problemas antes de la aplicación, no evitar la aplicación permanentemente.
X. ¿Qué Hay de los Informes Forenses?
DMARC admite informes de fallos a través de la etiqueta ruf=, pero no debe habilitarse casualmente.
Los informes de fallos pueden contener información sensible a nivel de mensaje, dependiendo de la implementación del receptor. También tienen una adopción limitada entre los principales proveedores de buzones debido a preocupaciones de privacidad.
Para la mayoría de las organizaciones, los informes agregados a través de rua= deben ser el punto de partida predeterminado.
Usa informes forenses solo después de una revisión legal, de privacidad, seguridad y retención.
XI. Por Qué las Herramientas Importan
El monitoreo DMARC solo es útil si los informes se vuelven accionables.
Los informes XML sin procesar son difíciles de revisar manualmente. Deben normalizarse, agruparse por remitente, interpretarse para la alineación SPF y DKIM, y rastrearse a lo largo del tiempo.
Skysnag Protect ayuda a automatizar este proceso dando a los equipos visibilidad sobre:
- Remitentes autorizados
- Fuentes no autorizadas
- Alineación SPF y DKIM
- Tendencias de paso y fallo de DMARC
- Actividad de subdominios
- Preparación para la aplicación
- Fallos de autenticación
- Cambios de remitentes a lo largo del tiempo
Esto ayuda a las organizaciones a pasar del monitoreo pasivo a la protección activa.
Comienza el monitoreo DMARC con Skysnag y obtén tu registro DMARC gratuito:
https://app.skysnag.com/en/register/XII. Lista de Verificación de Implementación
Usa esta lista de verificación para hacer que p=none sea efectivo.
- [ ] Publica un registro de monitoreo DMARC con informes agregados.
- [ ] Usa un destino de informes monitoreado, no un buzón no administrado.
- [ ] Confirma que los informes DMARC se están recibiendo y analizando.
- [ ] Identifica todas las fuentes de envío legítimas.
- [ ] Clasifica las fuentes desconocidas como legítimas, mal configuradas o no autorizadas.
- [ ] Valida la alineación SPF para cada remitente.
- [ ] Valida la alineación DKIM para cada remitente.
- [ ] Revisa los límites de búsqueda DNS de SPF.
- [ ] Confirma que los proveedores de terceros admiten autenticación alineada.
- [ ] Evita los informes forenses a menos que los equipos de privacidad y legales lo aprueben.
- [ ] Revisa los subdominios por separado.
- [ ] Define criterios para pasar a cuarentena o rechazo.
- [ ] Establece procedimientos de reversión antes de la aplicación.
- [ ] Monitorea los informes continuamente después de los cambios de política.
XIII. Conclusiones Clave
DMARC p=none es el modo de monitoreo.
Permite que los servidores de correo receptores evalúen DMARC y envíen informes, pero no les indica que bloqueen o pongan en cuarentena los mensajes que fallan.
Esto lo hace útil para el descubrimiento, pero insuficiente para la protección a largo plazo.
Las organizaciones deben usar p=none para identificar remitentes legítimos, detectar fallos de autenticación, corregir la alineación de terceros y prepararse para la aplicación de políticas.
El principal error es permanecer en p=none indefinidamente.
Para dominios importantes, el monitoreo debe conducir a p=quarantine o p=reject una vez que el correo legítimo esté correctamente alineado.
La aplicación de DMARC es lo que reduce el riesgo de suplantación de dominio exacto. El monitoreo es cómo llegar allí de forma segura.
Comience el monitoreo DMARC con Skysnag y obtenga su registro DMARC gratuito:
