De p=none a p=reject: criterios de salida por etapa para DMARC

La pregunta detrás de la mayoría de los proyectos DMARC no es cómo escribir el registro, sino cuánto tiempo quedarse en p=none y qué tiene que cumplirse antes de avanzar. Esperar para siempre deja tu dominio expuesto a la suplantación, y avanzar demasiado pronto manda tus propias facturas a spam. Esta guía te da criterios de salida etapa por etapa, un plan para subdominios, lo que suele romperse y cómo volver atrás. Los umbrales son consejo nuestro, no parte de ningún estándar, y los etiquetamos así.

La respuesta corta#

Quédate en p=none durante al menos un ciclo de envío completo, normalmente de dos a cuatro semanas, más si tienes correo mensual o trimestral como extractos. Pasa a quarantine cuando cada fuente legítima que conoces pase DMARC mediante una comprobación SPF o DKIM alineada. Pasa a reject tras un periodo más en quarantine sin sorpresas. No planifiques la rampa en torno a pct=: el estándar DMARC actual, el RFC 9989, elimina esa etiqueta. Se publicó en mayo de 2026 y deja obsoleto el RFC 7489, la especificación original de DMARC. Los fundamentos del registro en sí están en la guía de configuración de DMARC, que este artículo no repite.

Las etapas y cuándo salir de cada una#

Cada etapa de abajo tiene una prueba de salida. Cada número de la tabla es una regla orientativa que sugerimos, porque tu volumen y tu mezcla de remitentes deciden qué es realista.

Una etapa está terminada cuando los fallos sin explicar son pequeños y aburridos: unos pocos mensajes de reenviadores, listas de correo o fuentes que puedes identificar como ajenas. Si una fuente con volumen real sigue sin identificar, no has terminado la etapa 2. El manual para identificarlas está en la guía cómo leer los informes DMARC.

Un calendario de ejemplo#

Para concretar la tabla, aquí tienes un calendario plausible para una empresa con un ESP, un CRM y una herramienta de facturación. Es una ilustración, no una promesa.

• Semanas 1 a 4: publica p=none, recoge informes y construye una lista de cada fuente con su responsable. Incluye la que envía solo a fin de mes.
• Semanas 5 a 8: corrige la alineación fuente por fuente, empezando por la mayor en volumen. Revisa los informes después de cada cambio, no al final.
• Semana 9: aplica la política en dominios aparcados y que no envían.
• Semanas 10 a 13: pasa el dominio principal a quarantine y vigila cada semana si aparecen fuentes nuevas con fallos.
• Semana 14 en adelante: pasa a reject si el último mes fue tranquilo, y añade una regla permanente de que los remitentes nuevos se autentican antes del lanzamiento.

Si una fuente tarda en corregirse, el calendario la espera. La fecha es un plan, la prueba de salida es la regla.

Qué hacer con pct#

Si has visto consejos antiguos como pct=10, luego 25, 50, 100, era una forma de aplicar una política más estricta a una parte del correo que falla. El RFC 9989 elimina la etiqueta. Su propia justificación dice que la etiqueta normalmente no se aplicaba con precisión salvo que el valor fuera 0 o 100. En su lugar añade una etiqueta t, con y para "testing" y n (el valor por defecto) para el tratamiento normal.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"

Con t=y, un receptor que lo admita debería tratar un mensaje que falla un nivel más suave de lo que dice la política: quarantine pasa a none, reject pasa a quarantine. No tiene efecto sobre p=none. Dos advertencias honestas. Primero, el soporte de la nueva etiqueta tardará en extenderse, así que no dependas de ella para protegerte. Segundo, una rampa por porcentaje nunca fue una red de seguridad fiable, ni siquiera antes del cambio.

Una forma más segura de limitar el riesgo es escalonar por alcance en lugar de por porcentaje: aplica primero en subdominios y dominios que no envían, luego en el dominio principal, y permanece en quarantine unas semanas antes de reject. Si tu registro actual aún contiene pct=, no hace falta que corras a quitarlo, pero no añadas una rampa nueva que dependa de él.

Subdominios y dominios que no envían nada#

La victoria más rápida viene de los dominios que nunca envían correo. Los dominios aparcados y las marcas retiradas son objetivos favoritos de suplantación, y no tienen fuentes legítimas que romper. Publica de inmediato una política que se aplique, más un registro SPF que no autorice a nadie:

parked.example.com.         TXT  "v=spf1 -all"
_dmarc.parked.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
parked.example.com._report._dmarc.example.com.  TXT  "v=DMARC1;"

La tercera línea es el registro de autorización. Como la dirección rua= está en un dominio distinto del que protege la política, los receptores solo envían informes si ese otro dominio publica un registro TXT con el nombre <protected-domain>._report._dmarc.<report-domain>. Si lo omites, o pones la dirección rua= en el propio dominio aparcado, los informes de ese dominio nunca llegan. La guía de informes que no llegan explica la comprobación.

Para los subdominios de un dominio que sí envía, se aplica la política del padre salvo que el subdominio publique su propio registro. La etiqueta sp= fija una política distinta para los subdominios que no tienen ninguna. El RFC 9989 también define una etiqueta np para subdominios que no existen en el DNS, útil contra nombres de host inventados. Si piensas poner sp=reject en el padre, confirma primero que cada subdominio emisor pasa, o dale su propio registro. La guía del subdominio de envío explica por qué cada flujo de correo está mejor en su propio subdominio desde el principio.

Qué suele romperse al aplicar la política#

Casi todos los incidentes de aplicación se remontan a uno de estos. Búscalos en las etapas 1 y 2, no después del cambio de política.

• El remitente que nadie recordaba. Una herramienta de facturación, una plataforma de encuestas o un sistema de reclutamiento que envía una vez al mes. Un ciclo completo de informes atrapa a la mayoría, y por eso la etapa 1 no se puede saltar.
• Alineado en la prueba, no en producción. Un servicio pasa desde un grupo de IP de envío y falla desde otro. Juzga cada fuente por su volumen real a lo largo del tiempo.
• Reenviadores y listas de correo. El reenvío rompe SPF, y las listas que editan un mensaje rompen DKIM. No puedes evitarlo del todo. Espera una pequeña tasa residual de fallos y decide de antemano que es aceptable. El RFC 9989 es explícito al respecto: un dominio que publica p=reject no debe depender solo de SPF y debe firmar su correo con DKIM, y un dominio cuyos usuarios escriben en listas de correo no debería publicar p=reject en absoluto. Para ese tipo de dominio sugiere al menos un mes en p=none, y luego un periodo igual de largo en p=quarantine, antes de comparar resultados. Nuestras ventanas más cortas de arriba sirven para dominios que envían sobre todo correo de sistema, así que alárgalas si tu equipo escribe en listas públicas.
• Una herramienta nueva añadida después de aplicar la política. El equipo de marketing se da de alta en una plataforma un martes y su correo empieza a rebotar. Es un problema de proceso: acordad que los remitentes nuevos tengan la autenticación configurada antes del primer uso.
• Alineación estricta que se quedó activada. adkim=s o aspf=s convierten una configuración relajada que funciona en fallos. La guía de resolución de problemas de alineación recorre cada causa.

Vigilar el avance con números reales#

Durante las etapas 2 a 4 quieres una sola vista: para cada fuente, qué porcentaje de su correo pasa DMARC, y qué fuentes son nuevas esta semana. Los informes DMARC de Qualisend lo muestran por dominio, a 7, 30 o 90 días, y te envían un correo al día siguiente de que un dominio tenga al menos 10 mensajes que fallan tanto SPF como DKIM, o una fuente nueva con al menos 5 mensajes fallidos. No tiene una puntuación de "listo para reject", así que el juicio es tuyo: observa cómo cada fuente legítima llega al 100 % y se mantiene ahí. Los datos agregados además llegan con uno o dos días de retraso y cubren solo a los receptores que envían informes, así que una semana tranquila no prueba que nada fallara.

El monitoreo de salud del dominio de Qualisend muestra p=none como advertencia en los problemas de un dominio, y avisa cuando pct está por debajo de 100, lo que ayuda si gestionas varios dominios y quieres ver cuáles aún no han avanzado.

Vuelta atrás#

Planifica el camino de regreso antes de avanzar. Tres hábitos hacen que revertir sea rápido.

1. Guarda el texto del registro anterior en tus notas de cambios, para que revertir sea copiar y pegar.
2. Baja el TTL del registro _dmarc a unos minutos un día antes de un cambio de política, y vuélvelo a subir cuando todo esté estable. Los receptores guardan el DNS en caché, y un TTL largo ralentiza tu propia vuelta atrás.
3. Retrocede un paso, no todo el camino. Si una fuente legítima empieza a fallar con reject, vuelve a quarantine mientras la arreglas. Los mensajes ya rechazados durante esa ventana normalmente rebotan al remitente y no se pueden recuperar desde el lado receptor, así que es mejor que la primera ventana de aplicación sea corta y vigilada.

Dónde conecta la aplicación de la política con todo lo demás#

Llegar a quarantine o reject en el dominio organizacional es también el requisito previo de los logotipos BIMI, y la guía de BIMI lista lo que pide el estándar. No elimina la necesidad de los demás fundamentos de los requisitos de Google y Yahoo. El panorama completo de cómo encaja la autenticación con la reputación está en la guía de entregabilidad.

Una política DMARC aplicada demuestra que el correo es tuyo, pero no puede hacer buena una mala lista. El plan gratuito de la página de precios incluye 100 créditos que ejecutan la verificación completa en una lista. Un dominio protegido sigue necesitando una lista sana para llegar a la bandeja de entrada.