De p=none a p=reject sin perder tu propio correo

Publicar v=DMARC1; p=none lleva más o menos un minuto. Publicar p=reject lleva ese mismo minuto, y si lo haces la misma tarde puedes pasarte la semana siguiente explicando por qué dejaron de llegar las facturas, los restablecimientos de contraseña y los avisos de la herramienta de selección de personal.

La distancia entre esos dos registros no es técnica: es de inventario. p=reject pide a los receptores que rechacen el correo que falla DMARC; no garantiza que todos lo hagan. Casi toda organización envía correo legítimo desde más sitios de los que puede enumerar de memoria. El despliegue es el proceso de encontrar esos sitios antes de hacer esa petición.

Si los términos de abajo necesitan base antes —qué es la alineación, por qué no basta con que SPF pase— empieza por SPF, DKIM y DMARC: qué hace realmente cada uno. Este artículo da ese modelo por sabido y se ocupa de la mitad operativa.

Etapa 0: publica un registro de observación y nada más

El único trabajo del primer registro es que los receptores empiecen a informarte:

v=DMARC1; p=none; rua=mailto:informes-dmarc@tudominio.com

p=none no pide aplicar una política de DMARC. Los receptores aún pueden usar sus controles habituales de spam y abuso; lo que cambia es que los participantes pueden empezar a enviarte informes agregados sobre los mensajes que usan tu dominio.

Sobre esa dirección de informes hay dos cosas que conviene acertar desde el principio, porque ambas fallan en silencio.

Si la dirección de informes está en otro dominio, ese dominio tiene que autorizarte. Enviar informes a tu@proveedor-dmarc.example exige un registro TXT en tudominio.com._report._dmarc.proveedor-dmarc.example que contenga v=DMARC1. Sin él, los remitentes de informes que siguen la norma descartan tus informes, y «no llega ningún informe» es indistinguible de «nadie ha enviado ninguno». Los proveedores de DMARC gestionado suelen publicarlo por ti, pero merece la pena confirmarlo en vez de darlo por hecho.

Los informes agregados son XML y normalmente se comprimen con gzip. El periodo suele ser un día UTC, pero un receptor puede enviar varios informes o ninguno. Para un dominio pequeño basta un buzón; a partir de cierto volumen querrás algo que los procese. En cualquier caso, no los mandes a una dirección que nadie lee: los informes son el sentido entero de esta etapa.

Confirma que el registro está publicado y que el destino de informes está en regla con el comprobador de SPF y DMARC, que lee el registro etiqueta a etiqueta y verifica específicamente la autorización de informes externos.

Y luego espera. Si es un dominio de correo de uso general, cuyos usuarios podrían publicar en listas de correo, RFC 9989 recomienda mantener p=none al menos un mes. Incluso para un dominio dedicado al envío, espera a que aparezcan los remitentes mensuales, trimestrales y anuales. Aplicar la política antes de que un remitente poco frecuente haya aparecido en los datos es justo la forma en que llega la sorpresa.

Etapa 1: convierte los informes en un inventario de remitentes

Los informes agregados te dicen, por IP de origen: cuántos mensajes, si SPF pasó, si DKIM pasó y —la parte que importa— si alguno de los dos se alineó con tu dominio From.

Estás construyendo una sola tabla:

La sorpresa recurrente es lo larga que se vuelve la lista. Nóminas, avisos de CI, el CRM, las invitaciones de calendario de una herramienta de agenda, la herramienta de encuestas que alguien contrató en 2023: cada producto SaaS que envía «en tu nombre» aparece aquí. Eso es lo que compra la etapa 0.

Algunos orígenes serán reenvíos genuinos en lugar de un sistema tuyo: un destinatario reenvía tu mensaje automáticamente, el servidor que reenvía lo retransmite desde una IP que no es tuya y SPF falla. Si DKIM sobrevivió, DMARC sigue pasando por el lado de DKIM. Es uno de los argumentos más claros para asegurar DKIM alineado en todas partes en lugar de apoyarse solo en SPF.

Una nota sobre lo que los informes no pueden decirte: agregan, así que un origen que falla es un recuento y una IP, no un mensaje que puedas leer. Cuando necesites saber por qué falló un mensaje concreto, esa respuesta vive en sus cabeceras: guarda el código fuente y pásalo por el analizador de cabeceras de correo; cómo leer las cabeceras de un correo explica qué buscar.

Etapa 2: alinea todos los remitentes legítimos

Para cada remitente de la lista, el objetivo es al menos un pass alineado. En la práctica, busca DKIM alineado en todas partes, porque sobrevive al reenvío y no consume tu presupuesto de SPF.

Configurar DKIM en un proveedor suele significar que el proveedor genera un par de claves y te da un CNAME o TXT que publicar, a menudo en un selector como s1._domainkey.tudominio.com. El detalle decisivo es el valor d= de la firma resultante: tiene que ser tu dominio, no el del proveedor. Una firma con d=proveedor-de-correo.com verifica perfectamente y no se alinea con nada. Ya que estás ahí, mira el tamaño de la clave: RFC 8301 fija el mínimo en 1024 bits y recomienda 2048, y todavía hay proveedores que entregan claves de 1024. El comprobador mide todas las que encuentra.

La alineación de SPF normalmente exige que el remitente SMTP del sobre esté bajo tu dominio. Muchos proveedores ofrecen un ajuste de «dominio de rebotes propio» o «Return-Path personalizado» exactamente para esto: configúralo y SPF podrá alinearse. Sin él, el remitente del sobre se queda en el dominio de rebotes del proveedor, SPF pasa allí y no aporta nada a DMARC. En un mensaje entregado, confirma smtp.mailfrom (o smtp.helo si la ruta inversa es nula), no solo Return-Path.

Ya que estás tocando SPF, vigila el techo. SPF permite diez términos que consultan al DNS, include cuenta de forma recursiva y cada proveedor nuevo añade al menos uno. Pasarse devuelve PermError, que DMARC cuenta como fallo de SPF, y el registro parece completamente normal mientras ocurre. El comprobador despliega todo el árbol de include y cuenta cada término que gasta una consulta frente al límite, que es la manera más práctica de ver cuánto margen te queda. El recuento es un límite superior conservador y no un resultado por mensaje, así que un número por encima de diez significa «algunas rutas de envío darán PermError», y toca averiguar cuáles.

Si un remitente no se puede alinear, muévelo a un subdominio: notificaciones.tudominio.com para el soporte, por ejemplo. El correo de subdominio se juzga con sp (o np), así que puedes aplicar la política estrictamente en tu dominio principal mientras un subdominio corre con otra distinta.

Etapa 3: cuarentena y después rechazo

Con el inventario limpio y los informes tranquilos, sube un escalón. Cuarentena primero:

v=DMARC1; p=quarantine; rua=mailto:informes-dmarc@tudominio.com

La cuarentena tiene algo que el rechazo no tiene: se puede deshacer. Un mensaje que no debería haber fallado acaba en spam, donde el destinatario todavía puede encontrarlo y avisarte. Un mensaje rechazado desaparece, y el remitente recibe un rebote que quizá no te reenvíe. Para un dominio de correo de uso general, mantén la cuarentena al menos otro mes y sigue leyendo informes.

Y entonces:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r;
  rua=mailto:informes-dmarc@tudominio.com

Cuando este registro se hereda desde el dominio organizativo, sp=reject cubre los subdominios existentes y np=reject los que no existen en absoluto: los que un atacante inventa precisamente porque nada los limita. Pon np a conciencia; no cuesta nada y cierra un hueco real.

El freno de despliegue es t, no pct. Si aprendiste DMARC antes de 2026, el consejo estándar era pct=20 para aplicar la política a una fracción de tu correo. RFC 9989 eliminó pct (junto con rf y ri) al dejar obsoleto RFC 7489 en mayo de 2026, y señala la etiqueta de modo de prueba t como su sustituta. Los registros que aún llevan pct siguen funcionando —los receptores ignoran las etiquetas eliminadas en lugar de rechazar el registro— pero el comportamiento se divide: quien sigue la especificación actual aplica tu política completa a todos los mensajes, y quien todavía respeta pct aplica solo a una muestra. Si te apoyas en pct como margen de seguridad, ya no tienes el margen que crees.

Cómo se comporta realmente t=y

t=y es el freno actual, y se malinterpreta habitualmente como «no apliques esto». Más exactamente, pide a los receptores que no apliquen la política publicada de forma directa. RFC 9989 prevé un resultado un escalón más suave que el publicado, aunque el tratamiento final sigue siendo decisión del receptor:

Así que p=reject; t=y es una forma de publicar la política final que pretendes mientras el tratamiento previsto se queda en cuarentena. Resulta útil de verdad para un cambio prudente, y también es una trampa, porque un registro que a primera vista dice p=reject solo solicita cuarentena hasta que alguien quite la etiqueta. Ponte un recordatorio. El comprobador muestra por separado el tratamiento previsto cuando detecta t=y, así que el resultado suavizado queda a la vista en lugar de depender de tu memoria.

Qué vigilar después de aplicar

Aplicar la política no cierra la relación con los informes. Mantén rua de forma permanente: es como te enteras de que una herramienta SaaS nueva ha empezado a enviar en tu nombre, o de que un proveedor rotó una clave DKIM sin decírtelo.

Vale la pena nombrar dos situaciones porque parecen DMARC rompiéndose cuando no lo es:

Listas de correo. Una lista que añade un pie o reescribe el asunto invalida la firma DKIM, y además retransmite desde su propia IP, con lo que SPF también falla. Bajo p=reject, los suscriptores en receptores estrictos dejan de recibir esos mensajes. Las listas bien llevadas lo resuelven reescribiendo la cabecera From al dominio de la propia lista; las mal llevadas no. Algunos intermediarios además sellan con ARC el resultado que vieron, de modo que un receptor posterior puede saber que el mensaje se autenticó antes de que la lista lo tocara — pero eso solo sirve si el receptor confía en ese intermediario, así que es una mitigación y no un arreglo. En cualquier caso, es un coste conocido de aplicar la política, no un error de configuración tuyo.

Reenvío. Forma parecida, mejor desenlace: mientras el cuerpo del mensaje quede intacto, el DKIM alineado sobrevive y DMARC sigue pasando.

La lista de comprobación

1. Publica p=none con un rua que funcione. Verifica la autorización de informes externos si la dirección está fuera del dominio.
2. Observa hasta que aparezcan todos los remitentes. Para un dominio de correo de uso general, deja p=none al menos un mes.
3. Construye el inventario de remitentes a partir de los informes: cada origen, y si tiene un pass alineado.
4. Alinea cada remitente, prefiriendo DKIM con d=tudominio.com. Vigila el techo de diez consultas de SPF. Mueve los tercos a un subdominio.
5. Pasa a p=quarantine y, para un dominio de correo de uso general, sigue leyendo informes al menos otro mes.
6. Pasa a p=reject, y define sp y np de forma explícita.
7. Usa t=y como freno si quieres uno, recordando que suaviza un escalón, y recordando quitarlo.
8. Conserva rua para siempre.

Toda la secuencia es deliberadamente aburrida. Publicar p=reject no tiene ninguna dificultad; el trabajo está en el inventario, y el inventario solo existe porque pasaste unas semanas en p=none leyendo informes en vez de suponiendo. Para revisar el registro con el que acabes —política, tratamiento de subdominios existentes e inexistentes, modos de alineación, el presupuesto SPF que hay detrás y si tus direcciones de informe están autorizadas— pasa el dominio por el comprobador de SPF y DMARC.