DMARC quarantine y reject: cómo pasar de p=none sin perder correo legítimo

1. Qué piden p=none, quarantine y reject a los receptores

La etiqueta p del registro DMARC en _dmarc.example.com indica qué te gustaría que hicieran los receptores con el correo cuyo dominio From no supera DMARC, es decir, cuando ni SPF ni DKIM han pasado para un dominio alineado con él. Es una petición, no una orden. La RFC 9989, el estándar DMARC publicado en mayo de 2026 que sustituye a la RFC 7489, deja la decisión final a la política local de cada receptor.

Dos ideas marcan el despliegue. La primera: p=none no protege nada por sí solo; genera informes, y solo si el registro incluye una dirección rua. La segunda: no todos los receptores aplican la política igual. La RFC 9989 les indica que no rechacen únicamente porque la política diga reject, y algunos ponen ese correo en cuarentena, así que un mismo cambio puede verse distinto en cada proveedor de buzones. Planifica el paso como una serie de cambios pequeños y reversibles, no como un interruptor.

Los grandes proveedores de correo ya exigen un registro DMARC a los remitentes masivos, pero aceptan p=none. La guía para comprobar SPF y DMARC resume sus requisitos y explica cada etiqueta del registro.

2. Cómo leer los informes agregados de DMARC (rua)

Los informes agregados son lo que hace posible un cambio seguro. Añade una dirección de informes al registro, por ejemplo rua=mailto:dmarc-reports@example.com, y los receptores que envían informes te mandarán un XML comprimido, normalmente de un día UTC, con cada dirección IP que ha enviado correo con tu dominio en el From y el resultado que obtuvo. El formato lo define la RFC 9990. Un nombre de archivo como receiver.example!example.com!1791590400!1791676800.xml.gz indica el receptor que informa, tu dominio y el inicio y el fin del periodo como marcas de tiempo Unix.

Cada <record> del archivo agrupa mensajes por origen y resultado. Estos campos son los que más importan:

La diferencia entre la última fila y policy_evaluated es lo más útil que puedes aprender aquí. Una plataforma de newsletters puede mostrar un DKIM pass en auth_results para mailer.example.net y aun así fallar DMARC, porque ese dominio no está alineado con example.com. Solo policy_evaluated refleja la conclusión de DMARC.

Lee los informes durante varias semanas, no un solo día: las facturas mensuales, las newsletters trimestrales y los avisos de renovación anual llegan con su propio ritmo. Con cierto volumen, el XML en bruto es tedioso; un analizador o una herramienta de informes que agrupe las filas por origen, alineación y disposición cada día hace viable la revisión. No todos los receptores envían informes agregados, así que una semana tranquila no significa un dominio tranquilo. Si la dirección rua está en otro dominio organizativo, ese dominio debe publicar un registro de autorización como example.com._report._dmarc.reports.example.net que empiece por v=DMARC1; si no, los receptores ignoran la dirección (RFC 9990, sección 4).

3. Localiza todos los remitentes legítimos antes de aplicar la política

Aplicar la política solo es seguro cuando conoces todos los sistemas que ponen tu dominio en el From. Construye la lista desde dos lados: lo que usa la organización y lo que muestran los informes. Fuentes habituales:

• La plataforma de correo que usa la plantilla a diario.
• Marketing y newsletters, incluida esa herramienta de campañas antigua en la que alguien sigue entrando.
• Correo transaccional de tu aplicación: confirmaciones de alta, restablecimiento de contraseñas, recibos.
• Herramientas de negocio: CRM, facturación y cobros, soporte, recursos humanos y selección, agenda y firma electrónica.
• Formularios y plugins de la web que envían como noreply@example.com.
• Dispositivos y scripts: escáneres, alertas de monitorización, tareas programadas y relays propios.

Después, asocia cada origen de los informes a una entrada de la lista. Una consulta inversa de la IP (dig +short -x 192.0.2.10) suele revelar el proveedor, y su documentación explica qué include de SPF y qué configuración DKIM admite. Recoge el resultado en una tabla como esta:

La última fila es el objetivo del ejercicio. Cuando todas las fuentes conocidas pasan, lo que sigue fallando es sobre todo correo falsificado o mal configurado, y eso es justo lo que la política debe frenar. Las fuentes que envían de vez en cuando son las que más se olvidan, así que pregunta a finanzas, a recursos humanos y a soporte qué herramientas usan antes de fiarte de un mes tranquilo.

4. Alineación de SPF y DKIM: relajada o estricta

DMARC se supera cuando SPF o DKIM pasan y el dominio para el que pasan está alineado con el dominio From. Basta con un resultado alineado. En SPF se comprueba el remitente del sobre (RFC 7208); en DKIM, el valor d= de una firma válida (RFC 6376). Las etiquetas aspf y adkim fijan cuánto deben coincidir:

• Relajada (r, el valor por defecto): ambos dominios comparten el mismo dominio organizativo, así que bounce.example.com y news.example.com están alineados con example.com.
• Estricta (s): los dominios deben ser idénticos.

La RFC 9989 determina el dominio organizativo con un recorrido del árbol DNS (DNS Tree Walk), consultando registros _dmarc desde el nombre completo hacia arriba, en lugar de la lista de sufijos públicos en la que se apoyaba la RFC 7489.

La RFC 9989 constata que casi todos los titulares de dominios encuentran suficiente la alineación relajada. La estricta rompe el patrón habitual de un subdominio de rebotes por proveedor, así que mantén el valor por defecto salvo que tengas un motivo concreto; por ejemplo, subdominios delegados a proveedores externos, donde la alineación relajada dejaría que el correo autenticado para vendor.example.com pasara por example.com. Elijas lo que elijas, haz que DKIM sea el método alineado de cada fuente. SPF se rompe al reenviar, porque el servidor que reenvía no figura en tu registro; una firma DKIM suele sobrevivir al reenvío mientras el mensaje no se modifique.

5. Despliegue escalonado: pct ya no existe, usa t=y

Las guías antiguas escalonan con pct: p=quarantine; pct=10, luego 25, 50 y 100, para que la política cubra una muestra creciente del correo que falla. Según la RFC 7489, el correo fuera de la muestra recibía la política inmediatamente inferior. La RFC 9989 eliminó la etiqueta; su apéndice A.6 explica que los valores distintos de 0 y 100 casi nunca se aplicaban con precisión y que la desviación variaba mucho entre implementaciones.

La eliminación tiene una trampa. La RFC 9989 indica a los receptores que ignoren las etiquetas que no conocen, así que un receptor que sigue el nuevo estándar lee p=quarantine; pct=25 como un simple p=quarantine y lo aplica a todo el correo que falla. Ya no puedes confiar en un pct parcial para limitar el impacto.

El sustituto es el indicador de prueba t. Con t=y se pide a los receptores que apliquen un nivel por debajo de la política publicada: p=quarantine; t=y se trata como none, y p=reject; t=y como quarantine. Los informes siguen llegando como siempre, y el receptor puede anotar la desviación con el motivo policy_test_mode. La RFC 9989 presenta t=y y t=n como equivalentes de pct=0 y pct=100.

Durante la transición, algunos receptores solo implementan la RFC 7489 e ignoran t, mientras que los más nuevos ignoran pct. Como pct=0 con las reglas antiguas y t=y con las nuevas piden el mismo trato, puedes publicar ambas mientras pruebas:

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Observa los informes unas semanas y después quita las dos etiquetas para que p=quarantine se aplique por completo. Repite el patrón antes de reject: p=reject; t=y; pct=0 pide cuarentena, y al retirar las dos etiquetas se activa el rechazo.

También puedes escalonar por flujo de correo en lugar de por porcentaje. Un subdominio como news.example.com puede tener su propio registro DMARC y pasar a la aplicación antes o después que el dominio principal; el propio ejemplo de despliegue de la RFC 9989 prueba p=quarantine con t=y en un subdominio antes de endurecer la política.

6. Política de subdominios: sp y np

Un registro DMARC en example.com también cubre los subdominios que no tienen registro _dmarc propio. Dos etiquetas permiten que la política de subdominios sea distinta de p:

Unas cuantas reglas hacen que todo sea predecible. sp solo tiene efecto en el registro del dominio organizativo; un subdominio que publica su propio registro se rige por la p de ese registro. Fijar np=reject cuando p aún está en none es un primer paso de bajo riesgo: el correo falsificado desde nombres inventados como billing-support.example.com se rechaza, y los receptores que no admiten np simplemente recurren a sp o a p. Antes de apoyarte en ello, asegúrate de que cada subdominio desde el que envías de verdad tenga al menos un registro DNS, para que cuente como existente. Y recuerda que SPF no se hereda: cada nombre usado como remitente del sobre necesita su propio registro SPF, diga lo que diga la política DMARC.

7. Un calendario realista de p=none a p=reject

Ningún calendario sirve para todos los dominios, y la RFC 9989 advierte de que pueden hacer falta muchos meses de informes antes de estar listo para aplicar la política. Para dominios cuyos usuarios escriben en listas de correo, sugiere al menos un mes en p=none y otro tanto en p=quarantine, comparando resultados, y aun así recomienda que esos dominios no publiquen reject. Una organización con unos pocos servicios de envío podría planificarlo así:

Antes de cada cambio, baja el TTL del registro TXT _dmarc, por ejemplo a 300 segundos, con al menos un periodo del TTL anterior de antelación, para que una marcha atrás llegue rápido a los resolvers. Haz los cambios a principio de semana, avisa al equipo de soporte de qué debe vigilar y lleva un registro con fecha de cada valor que publiques. La RFC 9989 exige que todo dominio que publique p=reject firme su correo con firmas DKIM válidas en lugar de depender solo de SPF. Reject no es el único buen punto final: para un dominio que tu equipo usa en listas de correo, una cuarentena bien vigilada puede ser mejor opción, mientras que un dominio que solo envía facturas y notificaciones es un candidato claro a reject.

8. Cuando falla correo legítimo: diagnostica, corrige y da marcha atrás

Tarde o temprano, un informe o un compañero mostrará correo legítimo que falla. Busca las filas correspondientes en los informes agregados, o pide las cabeceras completas de un mensaje afectado y lee su cabecera Authentication-Results; después compara el patrón:

Si el fallo es grande, o afecta a correo que genera ingresos como recibos o restablecimientos de contraseña, primero da marcha atrás y luego investiga: añade t=y y pct=0, o vuelve a la política anterior. Con un TTL corto, el cambio llega a la mayoría de los resolvers en minutos. Un rechazo 5xx es definitivo, así que el correo ya rechazado no se entregará más tarde; di al equipo afectado qué mensajes debe reenviar. Luego corrige la fuente, comprueba durante unos días de informes que pasa y vuelve a avanzar. Los reenviadores y las listas que conservan los resultados de autenticación con ARC (RFC 8617) ayudan, pero la RFC 9989 señala que ningún mecanismo de este tipo está aún muy extendido, así que DKIM en cada fuente sigue siendo la solución fiable.

9. Cómo comprobar el registro DMARC publicado

Comprueba lo que de verdad está publicado, no lo que muestra el panel de tu DNS:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

Las dos primeras líneas muestran lo que devuelven los resolvers; la última consulta directamente un servidor autoritativo, que refleja el cambio antes de que caduquen las respuestas en caché. Confirma que:

• hay exactamente un registro TXT en _dmarc que empieza por v=DMARC1; si hay dos, los receptores descartan ambos y el dominio se comporta como si no tuviera DMARC;
• v=DMARC1 es la primera etiqueta y p vale none, quarantine o reject;
• el buzón de rua existe y, si está en otro dominio, está autorizado con un registro _report._dmarc;
• las etiquetas van separadas por punto y coma, sin comillas tipográficas ni caracteres sueltos copiados de un documento.

Después envía un mensaje desde cada servicio a un buzón que controles y lee la cabecera Authentication-Results: dmarc=pass junto a tu dominio From es el veredicto del receptor, y es el que cuenta.

Para una vista rápida desde fuera, el verificador gratuito de registros SPF y DMARC lee el registro _dmarc del nombre de host exacto que escribes, sin recurrir al dominio principal. Señala un registro ausente (medio, si el host tiene registros MX) y p=none (bajo, como modo de observación); quarantine y reject no generan ninguna señal. No lee tus informes ni evalúa sp, np, t, pct, rua o la alineación. La misma comprobación del DNS de correo lee también SPF, MTA-STS y CAA, y es una de las ocho comprobaciones pasivas del snapshot gratuito de preparación para el lanzamiento, que no pide registro y devuelve una puntuación con el resultado de cada comprobación. Para una revisión periódica, consulta la guía de DNS y seguridad del correo.