DMARC p=none: monitorizar el dominio sin bloquear emails legítimos
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 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:
- ¿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.
- ¿Cuántos mensajes pasan SPF alineado? Pasar SPF “neto” no basta, el dominio del Return-Path debe alinearse con el del
From. - ¿Cuántos mensajes pasan DKIM alineado? Igual: la firma
d=debe coincidir con el dominio delFrom(o un subdominio en modo relaxed). - ¿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ón | Tiempo recomendado en p=none |
|---|---|
| Pequeño negocio o dominio nuevo | 2-3 semanas |
| Empresa mediana con varios SaaS | 4-8 semanas |
| Gran empresa con múltiples filiales | 2-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=nonecumple 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:
p=nonecon todos los reportes hasta tener inventario completo.- Corregir SPF y DKIM en cada servicio (incluido el alineamiento).
p=quarantine; pct=10durante una o dos semanas.- Subir a
pct=50, despuéspct=100. p=reject; pct=100cuando 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.