¿Es suficiente p=none? Por qué publicar DMARC no es lo mismo que aplicarlo

¿Es suficiente DMARC p=none? No. p=none no detiene la suplantación. Solo monitoriza. Si su dominio está en p=none, los destinatarios le envían informes pero siguen entregando correo falsificado con su nombre, por lo que su dominio aún se puede suplantar. Resolvimos 300 dominios principales mediante DNS público y leímos sus registros de autenticación de correo electrónico para ver qué tan común es este error. La publicación parece saludable: El 84.7% publica un registro DMARC. En la aplicación es donde todo se cae. Solo el 67.3% realmente aplica DMARC con una política de quarantine o reject. Entre los 261 dominios que reciben correo, alrededor del 30% no aplica nada, porque están en p=none, no publican ninguna etiqueta de política utilizable o no publican DMARC en absoluto. Si heredó un registro DMARC y asumió que le protege, esta es la brecha en la que se encuentra.
Publicar DMARC no es lo mismo que aplicarlo
La autenticación de correo consta de tres registros que la gente suele tratar como una sola casilla de verificación. SPF (RFC 7208) enumera qué servidores pueden enviar en nombre de un dominio. DKIM (RFC 6376) firma un mensaje para que el destinatario pueda verificar que no fue alterado. DMARC (RFC 7489) vincula esas comprobaciones a la dirección From visible y le dice a los destinatarios qué hacer cuando fallan.
Esa última cláusula es donde se separan la publicación y la aplicación de DMARC. Un registro puede existir y aun así indicar a los destinatarios que no hagan nada. La política vive en la etiqueta p= y tiene tres configuraciones. Esto es todo lo referente a p=none frente a reject:
- p=reject indica a los destinatarios que rechacen el correo que falle. Esto es lo que realmente impide que alguien suplante su dominio.
- p=quarantine indica a los destinatarios que traten el correo que falla como sospechoso, enviándolo por lo general a spam. Es una forma de aplicación, aunque más débil que reject.
- p=none indica a los destinatarios que envíen informes y, por lo demás, entreguen normalmente el correo que falla. El correo falsificado sigue llegando. Esto es monitorización, no defensa.
Así que la pregunta honesta no es "¿tiene este dominio DMARC?", sino "¿aplica DMARC?". ¿Qué significa la aplicación de DMARC en la práctica? Significa que se le indica al destinatario que actúe ante un fallo en lugar de limitarse a registrarlo. En nuestra muestra, los dos números divergen casi dieciocho puntos: el 84.7% publica un registro, el 67.3% aplica uno. Esa brecha de dieciocho puntos corresponde a dominios que hicieron el trabajo visible, editaron su DNS, colocaron un registro y se quedaron a un paso de la parte que realmente bloquea algo.
Los datos: publicado frente a aplicado
Aquí está la muestra completa. Los controles de publicación son altos, mientras que la aplicación y las capas de transporte son bajas.
Ahora la distribución de políticas. Esta es la tabla que responde directamente a la pregunta: de los dominios que realmente reciben correo, cuántos están en p=none o peor.
| Política | Dominios | Proporción | ¿Bloquea el correo falsificado con el dominio From? |
|---|---|---|---|
| Aplicando: p=reject | 139 | 53.3% | Sí, el correo es rechazado |
| Aplicando: p=quarantine | 44 | 16.9% | En su mayoría, el correo se envía a spam |
| Solo monitorización: p=none | 44 | 16.9% | No, el correo es entregado |
| Sin registro DMARC | 30 | 11.5% | No, nada sobre lo que actuar |
| Registro sin una etiqueta p= utilizable | 4 | 1.5% | No, se trata como sin política |
Lea las tres filas inferiores juntas. Eso representa el 29.9% de los dominios receptores de correo donde el correo falsificado con su nombre no es detenido por DMARC. Estos son dominios que reciben correo de forma activa, por lo que no es una cuestión técnica de zonas estacionadas o que no envían. Es la misma vía de suplantación que describimos en nuestra guía sobre lo que los atacantes pueden ver sobre su empresa, aún abierta en casi un tercio de los dominios de correo activos situados en la cima de la web. Si tiene un registro DMARC pero todavía sufre suplantaciones, es casi seguro que se encuentre en la fila p=none.
La brecha de aplicación
Llamamos al espacio entre el 84.7% publicado y el 67.3% aplicado la brecha de aplicación de DMARC, y es el punto central de esta medición. Publicar un registro es barato y visible, por lo que se hace. Convertir ese registro en algo que bloquee el correo requiere que una organización conozca sus propios remitentes lo suficientemente bien como para rechazar el resto sin interrumpir el correo legítimo de la empresa. Ese segundo paso es donde los dominios se estancan, y ese estancamiento es medible.
Analícelo desde la perspectiva del atacante, porque es esa postura la que determina si un control importa. Usted quiere enviar un correo que parezca provenir del propio dominio del objetivo, dirigido al equipo de finanzas o a uno de sus clientes, pidiendo transferir un pago o restablecer una credencial. Comprueba primero el DNS del objetivo, del mismo modo que lo hicimos nosotros. Si el dominio publica p=reject, su correo falsificado es rechazado en el extremo receptor y nunca llega a la bandeja de entrada. Ese plan se arruinó. Si el dominio publica p=none, nada cambia para usted. El destinatario anota el fallo en un informe que va al propietario del dominio, no a su víctima, y entrega su mensaje de todos modos. Entonces, ¿se puede suplantar mi dominio en p=none? Sí, exactamente con la misma facilidad que si no tuviera DMARC en absoluto.
Lo que hace que nuestra cifra valga la pena citar es cómo la obtuvimos. Se trata de una medición pasiva e independiente, no de telemetría de un proveedor. No estamos informando sobre el correo que filtró nuestro propio producto ni extrapolando a partir del flujo entrante de un solo proveedor. Leímos la política pública que lee cualquier destinatario en Internet, el registro en sí, para una muestra fija en una fecha fija. Ese es un punto de vista diferente y más neutral que el de un proveedor de seguridad que informa sobre el tráfico que llega a observar.
Cómo comprobar su propio dominio
No necesita ninguna herramienta ni registrarse para esto. Lea su propio DNS público y observe una etiqueta. Cualquiera puede realizar estas consultas sobre cualquier dominio, porque una consulta DNS es una lectura pasiva de registros que ya son públicos.
- Compruebe la política DMARC. Ejecute
dig TXT _dmarc.yourdomain.com +shorty lea la etiquetap=.p=rejectop=quarantinesignifica que está aplicando. p=none, o sin etiquetap=, o sin registro en absoluto, significa que no tiene la política aplicada y su dominio se puede suplantar. - Compruebe SPF. Ejecute
dig TXT yourdomain.com +shorty busque un registro que comience conv=spf1. La ausencia de SPF debilita la alineación de la que depende DMARC. - Compruebe las capas de transporte e integridad. Ejecute
dig DS yourdomain.com +shortpara DNSSEC ydig TXT _mta-sts.yourdomain.com +shortpara un anuncio de MTA-STS. Ambos suelen estar ausentes, como muestran los datos anteriores.
Si la consulta DMARC devuelve p=none, ya tiene su respuesta: el registro se está publicando, no aplicando, y usted está únicamente en modo de monitorización.
Pasar de p=none a la aplicación
El camino de none a reject está muy recorrido, y lo cierto es que la edición en el DNS es la parte fácil. El trabajo consiste en confirmar que no interrumpirá el correo legítimo cuando los destinatarios comiencen a actuar ante los fallos. A continuación se explica cómo mover DMARC de none a reject sin dejar fuera a sus propios remitentes:
- Permanezca en p=none solo el tiempo suficiente para hacer un inventario. Apunte la etiqueta
rua=a un buzón de correo o a un analizador de informes y lea los informes agregados hasta que pueda identificar cada fuente que envía correo en nombre de su dominio, incluidas las plataformas de marketing, los sistemas de tickets y los terceros. - Pase a p=quarantine, incrementando gradualmente con pct si quiere ser cauto. A
pct=aplica la política a una fracción del correo que falla para que pueda vigilar si hay remitentes legítimos que no cumplen la alineación antes de aplicarlo a todo. Corrija cualquier remitente real que falle en la alineación SPF o DKIM antes de ampliarlo. - Pase a p=reject una vez que los informes estén limpios. Cuando ninguna fuente legítima esté fallando, reject es la configuración que detiene por completo la falsificación. Este es el único estado en el que la respuesta a "¿es suficiente p=none?" deja de ser relevante, porque ya ha dejado atrás p=none.
Ya que está modificando el DNS, anuncie MTA-STS para que el correo entrante no pueda degradarse silenciosamente a texto plano, y firme su zona con DNSSEC para que las consultas que obtienen su política no puedan ser suplantadas. La adopción de MTA-STS se sitúa en tan solo el 4.7% en nuestra muestra, por lo que implementarlo le sitúa por delante de casi todos. DNSSEC también da paso a esquemas más sólidos como DANE, y su escasez en el 20.0% limita hasta dónde puede llegar la seguridad del correo en cuatro de cada cinco de estos dominios. El criterio detrás de aplicar la política sin romper nada es el mismo que se requiere para saber cuáles de sus controles de emisión de certificados y superficies expuestas realmente importan y cuáles son solo ruido.
Lo que esto no demuestra
Límites honestos, porque un número sin sus salvedades es solo marketing.
- Majestic clasifica por enlaces entrantes, no por tráfico. La lista Majestic Million ordena los sitios por subredes de referencia y enlaces, lo que favorece a los dominios antiguos y muy citados. Esa es una población diferente a la de una lista clasificada por tráfico, así que interprete esto como una muestra honesta, no como la totalidad de Internet.
- Es una muestra de 300 dominios. Cada porcentaje conlleva un error de muestreo. Una cifra como el 67.3% aplicando la política significa 202 de 300 dominios, y una muestra distinta de 300 variaría algunos puntos.
- Es una instantánea. El DNS cambia a diario. Estas cifras describen la situación al 24 de julio de 2026, no una tendencia. Un dominio que hoy está en p=none podría estar en pleno despliegue y aplicándolo el próximo mes.
- Es una visión basada únicamente en DNS. Un p=reject publicado no es prueba de que el SPF y el DKIM de un dominio estén alineados correctamente para sus remitentes reales. Leemos la política sobre la que actúan los destinatarios, no el correo entregado. Es una declaración sobre la intención publicada, no sobre un despliegue impecable.
- La medición de la aplicación es general. Contamos p=quarantine y p=reject como aplicación. En la práctica, una política de cuarentena con un valor bajo de
pcto un modo de alineación laxo todavía permite el paso de algún correo falsificado, por lo que la cifra de aplicación es, en todo caso, generosa.
Preguntas frecuentes
¿Es suficiente p=none para detener la suplantación de correo?
No. p=none es solo monitorización. Los destinatarios informan de los fallos pero entregan el correo falsificado con normalidad, por lo que el correo con su dominio sigue llegando a las bandejas de entrada. Es una buena primera etapa mientras realiza el inventario de remitentes, pero no bloquea nada hasta que la política pasa a quarantine o reject.
¿Se puede seguir suplantando mi dominio si tengo un registro DMARC?
Sí, si ese registro está en p=none. Tener un registro no es lo mismo que estar protegido. Solo p=quarantine o p=reject indica a los destinatarios que actúen ante el correo que no supera la autenticación.
¿Cuál es la diferencia entre publicar y aplicar DMARC?
Publicar significa que existe un registro _dmarc. Aplicar significa que su política es p=quarantine o p=reject. Un registro en p=none no bloquea nada. En nuestra muestra de julio de 2026, el 84.7% publicó un registro, pero solo el 67.3% aplicó uno.
¿Qué porcentaje de dominios aplica realmente DMARC?
En nuestra muestra de 300 dominios, el 84.7% publicó DMARC y el 67.3% lo aplicó. Entre los 261 dominios receptores de correo, aproximadamente el 30% no aplica nada.
¿Es p=none lo mismo que no tener DMARC?
Para detener la suplantación, prácticamente sí. Para un atacante el resultado es idéntico: el correo falsificado es entregado. La diferencia es que p=none genera informes que puede utilizar para alcanzar la aplicación.
¿Cómo paso DMARC de none a reject?
Lea sus informes agregados en p=none hasta tener identificados todos los remitentes legítimos, pase a p=quarantine (opcionalmente de forma gradual mediante una etiqueta pct), corrija cualquier remitente real que falle en la alineación y luego establezca p=reject.
¿Por qué me siguen suplantando si tengo DMARC configurado?
Casi siempre porque la política está en p=none, o porque SPF y DKIM no están alineados para sus remitentes, por lo que una política aplicada no se puede superar. Compruebe primero la etiqueta p= en su registro _dmarc.
Lecturas relacionadas
- ¿Qué tan expuestos están a la suplantación de correo los dominios más concurridos del mundo? La pregunta de presencia sobre la que se apoya esta publicación.
- ¿Cuántos dominios principales restringen quién puede emitir sus certificados? El mismo método de DNS pasivo, aplicado a los registros CAA.
- ¿Qué pueden ver realmente los atacantes sobre su empresa?
¿No está seguro de si su dominio realmente aplica la política?
Nuestra revisión por $100 lee su superficie externa como lo haría un atacante, sobre un alcance que usted ha verificado que posee y autorizado por escrito, con un operador senior a cargo de la presentación de resultados. Que su DMARC esté publicado o realmente aplicado es una de las primeras cosas que observamos.
Reservar una revisión por $100