No. Un registro DMARC en p=none no bloquea nada: evalúa si un correo pasa la alineación de SPF y DKIM, pero no le pide al servidor receptor que haga algo distinto con lo que falla. Un mensaje falsificado con tu dominio llega igual a la bandeja de tu cliente o tu proveedor, como si no tuvieras DMARC publicado. Ni la banca mexicana lo tiene resuelto: de 54 bancos analizados, 42% no llega a p=reject y 11% sigue en modo monitor.
El dato es de un análisis de Proofpoint de agosto de 2026 sobre las principales instituciones bancarias de México, publicado por IT Masters Mag el 21 de septiembre de 2026 (consultado el 2026-09-28): 58% usa reject, 22% quarantine, 11% monitor y 9% no tiene DMARC. Proofpoint vende monitoreo DMARC, así que le conviene que el número suene alarmante; aun así es un conteo de registros DNS públicos, que cualquiera puede repetir. Si los bancos se quedan cortos, quedarse en none es lo normal.
¿Qué hace exactamente p=none y qué no hace?
DMARC en p=none es la política de solo reporte. El servidor que recibe el correo (Gmail, Outlook, Yahoo) comprueba si SPF o DKIM pasan alineados con el dominio del campo From:, y manda un resumen en XML al buzón declarado en la etiqueta rua=. Ahí termina su efecto. No hay filtro nuevo, ni rechazo, ni cuarentena hasta que cambias el valor de p=.
La diferencia entre tener DMARC en none y no tenerlo es que ahora te enteras, aunque enterarte no es bloquear.
| Política | Qué pasa con el correo que falla | Qué necesitas antes de publicarla |
|---|---|---|
p=none | Llega igual; solo se reporta | Nada: es el punto de partida |
p=quarantine | El receptor lo manda a spam | Inventario completo de las fuentes legítimas que envían como tu dominio |
p=reject | El receptor lo rechaza antes de entregarlo | Cero fuentes legítimas fallando alineación en los reportes recientes |
¿Por qué tantos dominios se quedan en none para siempre?
La causa más común es que none basta para cumplir el requisito. La guía de remitentes de Google (consultada el 2026-09-28) exige DMARC a quien envía más de 5,000 mensajes al día a cuentas de Gmail, y dice textual: "Puedes asignar el valor none a tu política de implementación de DMARC". El checklist queda en verde con none, y nadie vuelve a tocar el registro. El detalle de ese umbral y del orden de configuración está en la pieza sobre entregabilidad antes del primer envío.
Las otras dos causas refuerzan la primera:
- Miedo a romper correo legítimo. Subir de política sin inventariar los servicios que envían como tu dominio (facturación, CRM, helpdesk, la plataforma de marketing) bloquea correo real junto con el falso. Nadie quiere ser quien tumbó las facturas del mes.
- Nadie lee los reportes. Llegan como XML, sin interfaz en la mayoría de los proveedores de DNS, y se acumulan en un buzón que nadie abre.
Publicar p=none es una tarea con fecha de entrega. Subir de política es una decisión que alguien tiene que tomar mirando datos, y casi nunca tiene dueño.
¿Cómo saber si ya te están suplantando mientras estás en none?
Los reportes agregados de DMARC ya te lo dicen, si publicaste rua=. Cada reporte lista, por IP de origen, cuántos mensajes usaron tu dominio y si pasaron SPF y DKIM. Cuatro campos importan: source_ip, count, el resultado de spf y el de dkim. El campo disposition confirma lo que hizo el receptor, y en none siempre dice none:
<record>
<row>
<source_ip>203.0.113.44</source_ip>
<count>40</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
</row>
</record>
Un ejemplo ilustrativo, no un caso real. Un dominio en p=none junta una semana de reportes de Gmail y Outlook: 1,200 mensajes evaluados, 40 fallan la alineación (40 ÷ 1,200 = 3.3%) y salen de una IP que no pertenece a ninguno de los remitentes autorizados. Con none, esos 40 llegan a la bandeja del destinatario. Con quarantine, los mismos 40 habrían ido a spam.
Antes de concluir que es suplantación, descarta el reenvío. Un correo tuyo que pasa por una lista de distribución o un reenvío automático puede llegar con SPF roto y DKIM alterado, y aparece como falla desde una IP ajena. Si la IP pertenece a un proveedor de correo conocido y el volumen es bajo y constante, probablemente es eso.
El síntoma que no deja dudas es un cliente o proveedor que recibió un correo "tuyo" que nadie mandó. Eso es un incidente que none no evitó.
¿Cuándo pasar de none a quarantine o reject?
La regla depende de los reportes: si todas las fuentes legítimas que identificaste pasan alineación de forma consistente en tus reportes agregados, sube un nivel; si aunque sea una sigue fallando, corrígela antes de subir. "Ya llevo tres meses en none" no es un criterio.
Cambiar la política es una línea de DNS. El trabajo es el inventario:
- Lista cada servicio que manda correo con tu dominio de marca: el ESP de marketing, el sistema de facturación, el CRM, el helpdesk, las notificaciones del producto.
- Busca cada uno en los reportes y confirma que pasa SPF o DKIM alineado con tu dominio, no con el del proveedor.
- Corrige los que fallan (lo común es un DKIM que se quedó firmando con el dominio del proveedor) y espera a ver los reportes limpios.
- Sube de
noneaquarantine. Repite el ciclo y sube areject.
El orden importa: quarantine primero, porque un error ahí manda correo legítimo a spam, que se recupera; en reject, el mensaje no llega nunca y la persona que lo mandó muchas veces ni se entera. Si después de subir ves que las respuestas caen, el cambio de política es el primer sospechoso del orden de revisión que describe la pieza sobre qué revisar cuando la tasa de apertura cae de golpe.
¿Qué cambió en 2026 con pct= y el RFC 9989?
El RFC 9989 del IETF, publicado en mayo de 2026 (consultado el 2026-09-28), sustituye al RFC 7489, la especificación de DMARC vigente desde 2015. En su Apéndice A.6 elimina la etiqueta pct=, que servía para aplicar la política solo a un porcentaje de los mensajes que fallan. En su lugar define t=, el modo de prueba: con t=y, un reject se aplica como quarantine y un quarantine como none.
La guía de Google Workspace para configurar DMARC (actualizada el 2026-09-26, consultada el 2026-09-28) todavía recomienda la rampa por porcentaje: "puedes comenzar con un pequeño porcentaje de tus mensajes. A medida que más mensajes de tu dominio pasen la autenticación con los servidores receptores, actualiza tu registro con un porcentaje más alto hasta que alcances el 100%". La documentación de uno de los receptores más grandes todavía no se puso al día con el estándar, y eso cambia qué registro conviene publicar hoy.
_dmarc.tudominio.com. IN TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:reportes-dmarc@TU-DOMINIO"
Ese es el registro que describe Google. El problema es que, durante la transición, ninguna de las dos rampas es confiable:
- Para un receptor que ya implementa el RFC 9989,
pct=es una etiqueta que el estándar ya no define, y su sección 4.7 dice que las etiquetas desconocidas se ignoran: tupct=10se lee comoquarantinecompleto. - Para un receptor que sigue en el RFC 7489,
t=yes la etiqueta desconocida. La sección 6.3 de ese RFC (RFC 7489, consultado el 2026-09-28) también manda ignorarla: tup=reject; t=yse aplica comoreject.
Publica solo una política que aceptarías aplicada al 100%. La rampa segura hoy es el inventario de la sección anterior.
¿Cuándo quedarse en none es lo correcto, y cuándo no?
Dos casos donde none es la decisión correcta. El primero es un dominio recién autenticado: en las primeras semanas después de publicar SPF y DKIM, el momento que cubre la pieza sobre entregabilidad antes del primer envío, todavía no hay reportes suficientes para saber qué fuentes son legítimas.
El segundo es un dominio con una fuente legítima que todavía falla y que no has podido corregir: un sistema de facturación que manda con DKIM del proveedor, por ejemplo. Subir ahí rompe ese correo. Quedarse en none mientras se corrige es lo que toca.
Un matiz sobre los dominios secundarios de prospección: tienen pocas fuentes (el proveedor de buzones y la herramienta de envío), así que su inventario es corto y la fase en none debería durar semanas, no meses. Aun así, la prioridad de endurecimiento es el dominio de marca, que es el que se suplanta para engañar a clientes y proveedores. La distinción está en por qué se usan dominios secundarios y qué riesgo traen.
Cuando no es correcto: un dominio que lleva meses activo, con reportes acumulados que nadie ha mirado. Ahí none dejó de ser una fase y se volvió un descuido. Y el error contrario sale más caro: subir sin inventario rechaza facturas, notificaciones del sistema y campañas autorizadas junto con el correo falso, y te enteras cuando un cliente pregunta por qué no le llegó su factura.
¿Qué haces hoy si tu dominio lleva meses en none?
El primer paso es leer el reporte que ya estás recibiendo, no cambiar DNS:
- Localiza el buzón de
rua=y abre el reporte más reciente. Si nadie lo ha leído nunca, usa un agregador de reportes DMARC: el XML crudo de un mes es ilegible a mano. - Lista cada IP o fuente y marca las que reconoces: tu ESP de marketing, tu facturación, tu CRM. Lo que no reconoces es justo lo que
nonete deja ver sin bloquear. - Aplica la regla: si todo lo que reconoces pasa alineación de forma consistente, sube a
quarantine; si algo falla, corrígelo primero.
En el método IMPRO (Investiga, Mensajes que llegan, Personalizados, Respuestas, Oportunidades), esta pieza vive en la M: un mensaje bien escrito no sirve si termina en spam o si alguien más lo manda con tu dominio. Para revisar la autenticación junto con dominios, buzones y calentamiento, está la guía de infraestructura de outbound: el stack completo.
Si prefieres que alguien más lea los reportes y decida cuándo subir, Improvitz, consultoría de prospección B2B con IA en México, lo revisa en un diagnóstico.
