Inicio / Guías / DMARC p=none: cómo monitorizar antes de aplicar política

DMARC p=none: monitorizar el dominio sin bloquear emails legítimos

5,0 · 73 valoraciones
· Actualizado el 19 de noviembre de 2025

Aprende a usar DMARC p=none como fase inicial para detectar todos tus orígenes de envío sin afectar a la entrega antes de pasar a quarantine o reject.

DMARC p=none: cómo monitorizar antes de aplicar política
Forma parte de DMARC

DMARC se publica como un único registro TXT en _dmarc.tudominio.com y combina los resultados de configurar SPF y de la firma DKIM con una política que indica al receptor qué hacer cuando un mensaje no se autentica. La etiqueta p= es la pieza más visible de esa política, y p=none es la primera con la que prácticamente todo dominio debería empezar. No bloquea nada, pero abre el flujo de informes que te permite ver, por primera vez, qué orígenes de email están usando tu dominio.

Esta guía explica cuándo y por qué quedarse en p=none, cómo aprovechar los reportes y cómo planificar la transición a una política con enforcement real.

Qué hace exactamente p=none

Una política DMARC con p=none le dice al servidor receptor: “no apliques ninguna acción adicional sobre los mensajes que no se alineen con SPF o DKIM, pero sí envíame los reportes agregados”. Es decir:

  • Ningún email legítimo se va a bloquear por DMARC.
  • Tampoco se va a bloquear ningún email malicioso que esté suplantando tu dominio.
  • A cambio, recibes informes RUA (agregados) con un resumen diario por IP y dominio organizativo.

El registro mínimo se ve así:

_dmarc.tudominio.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

rua es la dirección donde quieres recibir los XML diarios. Algunos analizadores ofrecen un buzón propio para ingestarlos; en cualquier caso, el dominio del mailto: debe coincidir con el dominio donde publicas el registro o autorizar la recepción mediante un TXT en el dominio destino.

Por qué empezar siempre por p=none

Un dominio activo casi siempre envía email desde más sitios de los que recuerdas. Algunos típicos:

  • Plataforma corporativa (Google Workspace, Microsoft 365).
  • Herramientas de marketing (Mailchimp, Brevo, Klaviyo).
  • Email transaccional (Postmark, Sendgrid, AWS SES).
  • Helpdesk, CRM, facturación, formularios, ATS de RR. HH.
  • Aplicaciones internas con relays SMTP propios.
  • Subdominios olvidados de proyectos antiguos.

Si saltas directamente a quarantine o reject, cualquier servicio que no estés autenticando correctamente verá sus mensajes filtrados o rechazados. La fase p=none está diseñada para descubrir todo ese inventario antes de poner el cerrojo.

Qué buscar en los reportes RUA

Los reportes XML que llegan a rua= están agrupados por IP de envío y por dominio organizativo del From. Las preguntas clave que debes responder con ellos son:

  1. ¿Qué IPs envían en mi nombre? Cualquier IP que no reconozcas es una bandera roja: o es un servicio legítimo no inventariado, o un suplantador.
  2. ¿Cuántos mensajes pasan SPF alineado? Pasar SPF “neto” no basta, el dominio del Return-Path debe alinearse con el del From.
  3. ¿Cuántos mensajes pasan DKIM alineado? Igual: la firma d= debe coincidir con el dominio del From (o un subdominio en modo relaxed).
  4. ¿Hay volumen significativo que falle ambos? Eso es lo que más adelante quedaría bloqueado por una política activa.

Una regla práctica: no avances a p=quarantine mientras tengas tráfico legítimo no autenticado por encima del 1-2 % del total.

Cuánto tiempo permanecer en p=none

No existe un plazo fijo, pero las referencias razonables son:

Tipo de organizaciónTiempo recomendado en p=none
Pequeño negocio o dominio nuevo2-3 semanas
Empresa mediana con varios SaaS4-8 semanas
Gran empresa con múltiples filiales2-3 meses

Lo importante no es el calendario sino haber visto al menos un ciclo completo de actividad: una nómina mensual, un envío de newsletter trimestral, una factura anual… Cualquier cosa que envíe poco pero exista, debe haber dejado huella en los reportes antes de cerrar el dominio.

Riesgos de quedarse para siempre en p=none

Mantenerse indefinidamente en p=none es uno de los errores más frecuentes en DMARC. Los problemas son:

  • No protege frente al phishing. Cualquiera puede seguir suplantando tu dominio sin consecuencias para el atacante.
  • Falsa sensación de seguridad. El registro existe, pero no aplica nada.
  • Bulk senders requirements. Gmail y Yahoo, desde 2024, exigen DMARC publicado en remitentes masivos. p=none cumple el requisito formal, pero la política completa esperada es algo más estricto en el medio plazo.
  • Reputación. Algunos sistemas internos de scoring penalizan dominios que tienen DMARC pero no lo aplican.

Cómo construir el plan de salida

La forma sana de salir de p=none no es activar p=reject un viernes por la noche. Es subir gradualmente el porcentaje de aplicación con la etiqueta pct:

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

Pasos típicos:

  1. p=none con todos los reportes hasta tener inventario completo.
  2. Corregir SPF y DKIM en cada servicio (incluido el alineamiento).
  3. p=quarantine; pct=10 durante una o dos semanas.
  4. Subir a pct=50, después pct=100.
  5. p=reject; pct=100 cuando los reportes muestren cero tráfico legítimo no autenticado.

Si encuentras un origen difícil de autenticar (un servicio de terceros sin DKIM propio), valora moverlo a un subdominio dedicado y aplicar la política estricta solo al dominio principal con sp=reject mientras el subdominio se queda en quarantine.

Errores frecuentes en la fase de monitorización

No leer los reportes

Recibirlos en una bandeja sin abrir no sirve de nada. Conecta un parser (open source o SaaS) que normalice los XML y agrupe por origen.

Confundir SPF/DKIM “pass” con DMARC “pass”

Un email puede pasar SPF y aun así fallar DMARC si el dominio del Return-Path no coincide con el del From. El alineamiento es lo que cuenta. Esto se ve en los reportes en el campo policy_evaluated.

Olvidar los subdominios

Si no defines sp= (subdomain policy), DMARC hereda p= para los subdominios. Eso puede ser deseable o no. Si todavía estás en p=none no importa, pero al avanzar a quarantine debes decidirlo explícitamente.

Publicar varios registros DMARC

Igual que con SPF, solo puede haber un TXT que empiece por v=DMARC1 en _dmarc.tudominio.com. Si hay dos, los receptores ignoran ambos.

Usar un rua sin capacidad real de procesar

Mandar los XML a una bandeja personal y no procesarlos es equivalente a no tener rua. Si el volumen es alto, conviene un servicio dedicado.

Cómo verificar que p=none está bien publicado

Una consulta DNS rápida confirma la sintaxis y que solo existe un registro:

dig +short TXT _dmarc.tudominio.com

La respuesta debe ser una sola línea TXT que empiece por v=DMARC1;. Si ves varias líneas o caracteres extraños, hay un problema de publicación.

Para validar el alineamiento en mensajes concretos, abre las cabeceras de un correo enviado y busca el campo Authentication-Results. Debería aparecer algo similar a:

dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tudominio.com

Ese resultado, combinado con los reportes RUA, te indica si estás listo para empezar a endurecer la política.

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 para ecommerce de Abalola para ecommerce: estrategia, producción y operación del stack sobre Klaviyo, Mailchimp o Brevo.

Preguntas frecuentes

¿Por qué empezar siempre por p=none?
Porque permite descubrir todos los orígenes de envío reales sin bloquear entregas. Saltar a quarantine o reject sin esa fase suele tirar emails legítimos al spam.
¿Cuánto tiempo conviene quedarse en p=none?
Lo razonable son 4 a 8 semanas con tráfico habitual. Si tu organización envía facturas mensuales o flujos estacionales, conviene cubrir al menos un ciclo completo.
¿Sirve p=none para protegerme de spoofing?
No. p=none solo monitoriza, no aplica acción a los mensajes que fallan. La protección real llega con p=quarantine o p=reject.
¿Qué hago con los reportes RUA?
Los reportes RUA son XML que conviene procesar con un parser dedicado (Dmarcian, Postmark DMARC, Easydmarc) para identificar orígenes y diagnosticar fallos de alineación.
¿Es seguro pasar directamente de p=none a p=reject?
No. Lo recomendable es un escalón intermedio en `p=quarantine` con `pct` progresivo. Incluso con inventario completo, casi siempre aparece algún caso límite la primera vez que se aplica enforcement.
¿Qué pasa si recibo reportes de IPs que no reconozco?
Investígalas antes de hacer cualquier cambio. Pueden ser servicios olvidados, reenvíos legítimos a listas de correo, o intentos de suplantación. Solo después de identificarlas conviene apretar la política.
¿Puedo poner p=none y olvidarme?
Cumple el mínimo formal de algunos requisitos, pero no protege ni de phishing ni de spoofing. Hay que avanzar a una política con enforcement real en cuanto el inventario lo permita.