Desplegar DMARC por fases, tras el fin de pct

La verdadera granularidad siempre han sido las fuentes

Este es el punto que pct enmascaraba: nunca se endurece de verdad «el 25 % de un flujo». Se hacen conformes unas fuentes, una a una. El despliegue por fases real consiste en recorrer el inventario —plataforma de marketing, CRM, facturación, soporte— y alinear cada una (firma DKIM con la marca del remitente, d=ejemplo.es) hasta que los informes muestren un paso alineado para todas.

Mientras haya fuentes legítimas que fallen, se queda en none (o en quarantine si el riesgo es aceptable); en cuanto están todas alineadas, el endurecimiento llega sin falsos positivos. Ese es el verdadero cursor de progresividad, mucho más fino que un porcentaje, porque actúa sobre la causa (una fuente no alineada) y no sobre un síntoma (un volumen en fallo). El método de alineación fuente por fuente se detalla en alcanzar p=reject sin romper el correo legítimo.

El modo de prueba t=y: el sustituto honesto de pct

DMARCbis introduce la etiqueta t (por testing). Publicar t=y señala a los destinatarios que la política está en fase de prueba: aplican la política pedida sabiendo que aún no es definitiva, lo que los incita a ser más indulgentes y permite observar los efectos sin consecuencias brutales. Es el verdadero equivalente moderno de un despliegue prudente: ya no «aplica al 25 %», sino «esta es la política objetivo, que se trate como una prueba mientras se confirma».

En concreto, t=y se usa durante la ventana de subida de política, cuando hace falta una red de seguridad. Una vez los informes están limpios y la confianza establecida, se retira t=y (o se pasa a t=n) para hacer la política plenamente efectiva. El funcionamiento preciso de la etiqueta se explica en la etiqueta t de DMARCbis.

La cadencia de vigilancia entre tramos

Un despliegue por fases sin vigilancia no es por fases, es solo lento. En cada cambio de política hace falta una cadencia explícita:

• Día 1: verificar que nada se ha roto de inmediato; ninguna fuente legítima importante pasa a fallo.
• Día 3: llegan los primeros informes agregados del nuevo tramo (son diarios, con un desfase). Controlar la alineación fuente por fuente.
• Día 7: una semana completa capta las variaciones semanales (campañas del lunes, extractos). Si todo está limpio, el siguiente peldaño puede plantearse.

Esta cadencia transforma «hemos endurecido DMARC» de una apuesta optimista en un cambio controlado, reversible a la mínima alerta. Estos puntos de control necesitan un responsable asignado; un despliegue por fases que nadie mira no tiene de por fases más que el nombre.

¿Cuánto tiempo por tramo?

No hay una duración universal, pero sí un principio: permanecer en cada tramo el tiempo de captar el ciclo de envío completo. Un dominio que emite extractos mensuales no los verá en una ventana de unos días; hay que observar al menos un ciclo de facturación antes de concluir que «todo está limpio». Para un flujo simple y diario, unos días en quarantine bastan antes de reject. Para un ecosistema complejo, cuentan varias semanas. La cuestión de la duración total se trata aparte en el calendario de subida de política.

Los subdominios: un tramo que no hay que olvidar

El despliegue por fases no concierne solo al dominio raíz. Los subdominios heredan p por defecto, pero conviene pilotar sp explícitamente, y sobre todo bloquear los subdominios inexistentes con np. Buena noticia: np=reject es una ganancia inmediata y sin riesgo, a colocar temprano en el despliegue; ningún correo legítimo sale de un subdominio que no existe, así que no hay nada que observar antes de endurecer. Detalles en la política de subdominio (sp y np).

¿Varios dominios? La cartera también se escalona

Con varios dominios, la progresividad tiene una tercera dimensión: el orden en el que se tratan. Lo sensato es empezar por un dominio secundario —bajo volumen, flujo de envío simple— y desplegar toda la escala sobre él primero. El ejercicio enseña al equipo a leer los informes, mantener la cadencia de vigilancia y ejecutar el gesto de repliegue, en un contexto donde un error cuesta poco. El escenario probado se reproduce luego sobre el dominio insignia, donde lo que está en juego es real pero el proceso ya no tiene nada de nuevo. Los dominios aparcados, por su parte, no necesitan ninguna progresividad: nada legítimo sale de ellos, pueden recibir la política más estricta desde el primer día. Secuenciar así la cartera transforma el primer despliegue en un ensayo general en lugar de una apuesta.

Saber retroceder

Un buen despliegue por fases incluye un plan de repliegue. Si un tramo revela una fuente legítima que había pasado inadvertida y cuyos mensajes se bloquean, hay que bajar un peldaño (por ejemplo de reject a quarantine, o reactivando t=y), alinear la fuente, y luego volver a subir. Retroceder no es un fracaso: es exactamente lo que se supone que la progresividad permite. El error sería quedarse en reject esperando que el problema se resuelva solo mientras desaparecen correos legítimos.

Trampas frecuentes

• Seguir apoyándose en pct. Algunas herramientas la aceptan por retrocompatibilidad, otras la ignoran. Ningún despliegue debería construirse sobre ella: DMARCbis la retiró, y su comportamiento era de todos modos desigual.
• Saltarse tramos. Pasar directamente de none a reject sin ventana en quarantine funciona si y solo si los informes son irreprochables desde hace semanas. En la duda, mejor mantener el paso intermedio.
• Endurecer sin vigilar. Un cambio de política sin cadencia de control es una apuesta, no un despliegue.
• Olvidarse de retirar t=y. El modo de prueba es una fase, no un destino: dejado en su sitio, debilita la política objetivo.

Un calendario tipo, del primer día a reject

Para hacer todo esto concreto, así es como se ve una progresión serena para un dominio de tamaño medio, sin urgencia particular:

• Semanas 1 a 3 — p=none. Se publica el registro con una dirección rua, se coloca np=reject desde el principio, y se deja que afluyan los informes. Nada se bloquea. Se levanta el inventario de fuentes y se alinean las más evidentes.
• Semanas 4 a 6 — alineación. El grueso del trabajo de calendario. Se recorre el inventario fuente por fuente, se añade una firma DKIM con la marca del remitente en cada plataforma, y se verifica en los informes que cada una pasa en alineado. Se queda en none mientras una fuente importante siga fallando.
• Semana 7 — p=quarantine; t=y. Primer tramo de aplicación, en modo de prueba. Se vigila según la cadencia día 1 / 3 / 7. El modo de prueba señala a los destinatarios que la confirmación sigue en curso, y deja una red de seguridad.
• Semana 8 — p=quarantine. Se retira t=y. La política de cuarentena es plenamente efectiva. Una semana de observación para captar un ciclo semanal completo.
• Semana 9 — p=reject. Los informes están limpios desde hace varias semanas, las únicas fuentes en fallo son desconocidas (por tanto, suplantadores). Se endurece. La vigilancia de los informes continúa, porque la aparición de una nueva fuente no alineada siempre puede darse.

Este calendario no es una regla: un flujo simple irá el doble de rápido, un ecosistema complejo el doble de lento. Es una plantilla: cada peldaño se franquea con pruebas, no con reloj. Las duraciones se adaptan al ciclo de envío real, nunca al revés.

En resumen

La desaparición de pct no ha vuelto el despliegue de DMARC más arriesgado, lo ha vuelto más honesto. La progresividad real siempre se apoyó en la alineación de las fuentes y en el tiempo de observación entre los tramos, no en un porcentaje que los destinatarios aplicaban de forma desigual. El trío none → quarantine → reject, marcado por una vigilancia seria y asegurado por el modo de prueba t=y, sigue siendo el buen método.

Para situar el punto exacto y verificar la alineación real de cada fuente antes de subir un tramo, un paso por el analizador DMARC gratuito dice, desde el punto de vista de los destinatarios, si el endurecimiento puede hacerse sin romper nada.