Cómo pasar DMARC de p=none a p=quarantine sin perder correo legítimo

Un registro DMARC con p=none pide a los proveedores de correo que informen sobre los mensajes que no superan la autenticación, pero que los entreguen con normalidad. Es el punto de partida correcto y el lugar equivocado para quedarse: cualquiera puede seguir enviando correo con su dominio en el campo From, y los receptores no tienen ninguna instrucción suya para tratarlo como sospechoso.

Pasar a p=quarantine indica a los receptores que el correo que falla debe tratarse como sospechoso, lo que en la práctica suele significar la carpeta de spam. El riesgo no es el cambio en sí. El riesgo es un servicio legítimo (facturación, soporte, CRM, newsletter) que sigue fallando DMARC el día del cambio, de modo que sus propios mensajes acaban en spam.

La respuesta corta: lea sus informes agregados hasta que cada remitente legítimo supere la comprobación con DKIM alineado, cambie a p=quarantine primero con el modo de prueba, compare los informes y después retire el modo de prueba. A continuación, los detalles. Si necesita repasar los 3 registros, consulte SPF, DKIM y DMARC explicados.

Qué hace realmente p=none

DMARC se define ahora en el RFC 9989, publicado en mayo de 2026, que sustituyó al RFC 7489. Llama a p=none Monitoring Mode (modo de supervisión) y explica por qué existe: salvo en las configuraciones más sencillas, el titular de un dominio puede pasar por alto un servidor o un acuerdo de envío con un tercero, y los informes lo ponen de manifiesto.

El valor quarantine significa que el titular del dominio considera sospechoso el correo que falla. La decisión final sigue siendo del receptor, pero en la mayoría de los proveedores de correo eso significa la carpeta de spam. Google lo describe con claridad en su implantación recomendada de DMARC: los mensajes que no superan DMARC van a la carpeta de spam del destinatario.

Paso 1: que cada remitente legítimo supere la comprobación

El RFC 9989 es claro respecto al orden. Los flujos de correo legítimos que fallan porque sus identificadores no están alineados o faltan MUST be fixed before (deben corregirse antes) de publicar una política de aplicación.

Revise sus informes agregados (nuestra guía sobre cómo leer un informe agregado DMARC explica el XML) y anote cada origen:

• Su proveedor de correo principal: debe superar la comprobación con DKIM y SPF alineados.
• Cada herramienta de terceros que envía con su dominio: active en su configuración la firma DKIM con su propio dominio. Una herramienta que solo supera SPF con su propio dominio de sobre no está alineada y fallará DMARC.
• Reenviadores y listas de correo: a menudo rompen SPF. Las firmas DKIM generalmente siguen siendo válidas cuando el correo se retransmite, otro motivo para apoyarse en DKIM y no solo en SPF.
• Orígenes desconocidos que fallan: son justo lo que la nueva política debe detener.

Cuánto tiempo observar lo decide usted. Google sugiere al menos 1 semana con p=none, ya que eso suele bastar para que los informes cubran todos sus flujos de correo. El RFC 9989 señala que, según la frecuencia con la que envíe, puede llevar muchos meses. Piense en el correo que envía una vez por trimestre o una vez al año: avisos de nómina, facturas anuales, recordatorios de renovación. Si todavía no han aparecido en sus informes, aún no ha comprobado que superen DMARC.

Paso 2: cambiar primero con el modo de prueba

Con el RFC 7489, la forma habitual de hacer una transición gradual era la etiqueta pct (aplicar la política a un porcentaje del correo que falla). El RFC 9989 eliminó pct porque los receptores aplicaban de forma desigual los valores distintos de 0 y 100. En su lugar existe una etiqueta de modo de prueba, t:

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

Con t=y pide a los receptores que apliquen 1 nivel por debajo de la política indicada, de modo que p=quarantine; t=y se trata como none, mientras que intermediarios como las listas de correo ya pueden ajustar cómo gestionan su correo. La etiqueta no cambia los informes. Compare sus informes antes y después: muestran qué parte de su correo pasa por retransmisores que fallarían una vez aplicada la política.

Algunos proveedores todavía documentan el antiguo enfoque por porcentaje; la guía de implantación de Google, por ejemplo, muestra pct=5 como valor inicial. Los receptores que aún no admiten t simplemente lo ignoran, así que considere el modo de prueba un arranque suave, no una red de seguridad.

Paso 3: aplicar la política y seguir vigilando

Cuando los informes del modo de prueba se vean limpios, retire la etiqueta:

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

En las primeras semanas tras el cambio:

• Lea los informes a diario y busque valores disposition iguales a quarantine en orígenes que reconoce.
• Pida a los equipos que escriben a clientes (finanzas, ventas, soporte) que le avisen si bajan las respuestas o si los clientes dicen que el correo llegó a spam.
• Trate cada nueva herramienta que envíe con su dominio como una solicitud de cambio: DKIM con su dominio antes de ponerla en marcha.
• Mantenga ordenado el acceso al DNS. Un registro DMARC devuelto discretamente a p=none por un proveedor externo bienintencionado deshace el trabajo.

Subdominios y dominios que no envían nada

Sin una etiqueta sp, la política p se aplica también a los subdominios. Si un subdominio envía correo de marketing desde otra plataforma, revíselo en los informes antes del cambio o asígnele su propio registro _dmarc. La etiqueta np fija una política para subdominios que no existen en absoluto, una opción habitual para nombres desde los que nadie debería enviar nunca.

Los dominios que posee pero nunca usa para correo (antiguas marcas, registros defensivos) son el caso fácil: sin remitentes legítimos, pueden pasar directamente a una política de aplicación. Son justamente los dominios atractivos para los fraudes de facturas falsas, porque nadie los vigila.

Antes de avanzar a p=reject

p=reject es el siguiente paso, pero el RFC 9989 es prudente al respecto en dominios cuyos usuarios publican en listas de correo. Recomienda mantener p=none al menos un mes y después p=quarantine durante un periodo igual de largo, y comparar antes los resultados. Los grandes proveedores de correo ya exigen DMARC a los remitentes masivos, como explicamos en los requisitos de Gmail y Yahoo para remitentes, así que un p=quarantine estable es por sí solo una posición sólida.

Una lista de comprobación breve

• Informes agregados recopilados durante el tiempo suficiente para incluir los flujos de correo poco frecuentes.
• Cada remitente legítimo supera DMARC con DKIM alineado.
• p=quarantine; t=y publicado e informes comparados antes y después.
• Modo de prueba retirado e informes leídos a diario durante las primeras semanas.
• Subdominios y dominios sin uso cubiertos con sp, np o registros propios.

Dónde encaja Guarding

Una vez aplicada su política, el principal riesgo es que vuelva a cambiar sin que nadie lo note. Vigilamos sus registros SPF, DKIM y DMARC y el resto de lo que protegemos desde fuera cada día, sin entrar en sus sistemas. Si un registro se debilita o desaparece un selector DKIM, una persona lo revisa y usted recibe el cambio exacto que debe hacer, tal como describimos en qué ocurre cuando encontramos algo. El panel de ejemplo muestra cómo se presenta.