El fin de la etiqueta pct: el modo de prueba t= de DMARCbis

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=quarantine; t=y; rua=mailto:informes@ejemplo.es"

Cómo desplegar DMARC por fases, sin pct

La desaparición de pct no cambia el método de despliegue, incluso lo vuelve más claro. La secuencia sigue siendo la descrita en alcanzar p=reject sin romper el correo:

1. p=none — observación pura. Se recogen los informes y se inventarían las fuentes.
2. Alinear cada fuente legítima (SPF/DKIM), hasta que los informes estén limpios.
3. p=quarantine con t=y — la cuarentena se declara en modo de prueba: se verifica que ninguna fuente legítima olvidada caería, sin riesgo real.
4. Retirar t=y — la cuarentena se aplica de verdad.
5. p=reject (eventualmente con t=y primero, luego sin él) — la aplicación completa.

En lugar de un cursor de porcentaje impreciso, hay un interruptor neto: prueba o real. La granularidad ya no viene del «cuánto» (el porcentaje) sino del «qué» (qué política, en qué perímetro: raíz, subdominios vía sp, inexistentes vía np).

¿Y si pct sigue en el registro?

Nada grave. Las implementaciones actualizadas de DMARCbis simplemente ignoran pct. No rompe nada dejándola, pero ya no sirve de nada; mejor retirarla para mantener un registro limpio. Es uno de los pequeños gestos de la migración a este nuevo estándar, junto con el añadido de np.

Un matiz durante la transición

Como siempre con DMARCbis, el ecosistema se actualiza progresivamente. Durante un tiempo, coexistirán:

• destinatarios actualizados, que entienden t e ignoran pct;
• destinatarios antiguos, que ignoran t (y aplican, por tanto, la política plenamente, incluso con t=y).

Consecuencia práctica: t=y no es una red de seguridad absoluta del lado de los destinatarios antiguos; algunos aplicarán p=quarantine de verdad. Por eso la verdadera seguridad sigue siendo subir por etapas vigilando los informes: t=y ayuda a observar, pero es la limpieza de los informes lo que indica que ha llegado el momento, no la etiqueta. Para leer estos informes, ver cómo leer los informes agregados.

Un despliegue real, semana a semana

Para hacer la secuencia concreta, así podría verse la subida de un dominio de tamaño medio, con los registros en cada etapa.

Semana 1 — observación. Se publica:

v=DMARC1; p=none; rua=mailto:informes@ejemplo.es

No se toca nada más. Los informes empiezan a llegar; revelan las fuentes (plataforma de correo, CRM, facturación, una herramienta olvidada).

Semanas 2 a 4 — alineación. Se configuran SPF y DKIM alineados para cada fuente legítima, hasta que los informes las muestren todas en verde. El registro aún no cambia: el trabajo ocurre «bajo el capó».

Semana 5 — cuarentena en prueba. Se declara la cuarentena, pero en modo de prueba:

v=DMARC1; p=quarantine; t=y; rua=mailto:informes@ejemplo.es

Con t=y, se observa lo que se pondría en no deseados sin arriesgar el envío allí de una fuente legítima olvidada. La vigilancia dura unos días.

Semana 6 — cuarentena real. ¿Los informes están limpios? Se retira t=y:

v=DMARC1; p=quarantine; rua=mailto:informes@ejemplo.es

Semana 7 — reject. Misma lógica: eventualmente p=reject; t=y unos días, luego se retira t=y y se añade np=reject para bloquear los subdominios inexistentes. La aplicación está alcanzada.

Este calendario es indicativo: un dominio pequeño irá más rápido, un parque grande más lento (ver alcanzar p=reject). El punto clave: es el estado de los informes, no el calendario, lo que autoriza cada paso.

Qué buscar durante una ventana t=y

La ventana de prueba solo es útil si se sabe qué buscar en ella. Durante una fase t=y, el tráfico en fallo de los informes se separa en dos montones. Primero, las fuentes identificadas —una plataforma, una herramienta, un socio que envía por su cuenta— y que aún fallan la alineación: cada una es una tarea que terminar antes de retirar el indicador, porque bajo la política real habría sido capturada. Después, las fuentes desconocidas: esos fallos son la política haciendo exactamente lo que se espera de ella, la prueba de que morderá el tráfico correcto. La ventana ha cumplido su papel cuando el primer montón está vacío y solo queda el segundo. La ventana se dimensiona también según los ritmos de envío; una semana tranquila puede enmascarar un remitente raro pero importante.

Tres errores que evitar con t

• Confundir t=y y pct=100. t=y no «reduce» la aplicación a una muestra: señala un modo de prueba que solo respetan los destinatarios actualizados. No es un sustituto del porcentaje, es otra cosa: un indicador de experimentación.
• Quedarse en t=y para siempre. El modo de prueba es una etapa de transición, no un destino. Mientras t=y esté ahí, los destinatarios actualizados no aplican de verdad la política: el dominio no está realmente protegido. Se retira en cuanto los informes estén limpios.
• Creer que t=y protege en todas partes. Los destinatarios antiguos ignoran t y aplican la política plenamente. Así que incluso con t=y, un p=reject puede morder en algunos. Una política estricta no se declara antes de estar en condiciones de asumirla en todas partes.

Preguntas frecuentes sobre t

¿t=y es obligatoria? No. Es una herramienta de observación útil durante un endurecimiento, pero la subida p=none → quarantine → reject puede perfectamente hacerse vigilando simplemente los informes en cada etapa, sin tocar nunca t.

¿t=y reemplaza la etapa p=none? No, son dos cosas diferentes. p=none no pide ninguna acción a los destinatarios; t=y con p=quarantine o p=reject les dice «este es mi verdadero objetivo, pero aún estoy probando». t=y es útil después de p=none, para franquear un peldaño con una red de seguridad.

¿Mi antiguo pct=50 va a dar problemas? No, simplemente lo ignorarán las implementaciones actualizadas. Un cambio de registro es la ocasión para retirarlo.

t, entregabilidad y lo que hacen realmente los destinatarios

Una confusión frecuente merece aclararse: t=y no es un ajuste de entregabilidad. No les dice a los proveedores «sea más amable con mi correo»; les dice «esta política está en prueba, no la aplique aún estrictamente». La entregabilidad depende de otros factores —reputación de IP, tasa de quejas, alineación real— no de la presencia de t.

Lo que hacen los destinatarios con t=y varía. Las implementaciones actualizadas de DMARCbis lo respetan: envían los informes como si la política estuviera activa, pero no ponen realmente el correo en cuarentena o rechazo. Las implementaciones más antiguas, que no conocen t, lo ignoran y aplican la política plenamente. Consecuencia práctica: durante la transición, t=y es una red de seguridad parcial, no total.

El buen uso, por tanto: servirse de t=y como una ventana de observación durante un endurecimiento, sabiendo que algunos destinatarios ya aplicarán la política de verdad. Se vigilan los informes agregados; en cuanto están limpios, se retira t=y y la política muerde en todas partes. Quedarse bloqueado en t=y «por prudencia» es un error: sería creerse protegido cuando los destinatarios actualizados, ellos, no aplican nada. La prudencia es la limpieza de los informes antes de endurecer, no un indicador de prueba que se deja abandonado indefinidamente.

En resumen

DMARCbis suprime la etiqueta pct (despliegue por porcentaje, considerado poco fiable) y la reemplaza por t, un modo de prueba binario: t=y señala «política en prueba, no la aplique aún estrictamente». La subida se pilota ahora con la observación de los informes, no con el porcentaje. t=y es una etapa de transición que hay que retirar en cuanto los informes estén limpios, nunca un destino.

Thomas pilota la subida

Elegir el buen momento para retirar t=y, pasar de cuarentena a reject, verificar que ninguna fuente cae: es exactamente el tipo de decisión que Thomas, el CISO virtual, toma a partir de los datos reales del dominio. Genera el registro DMARCbis adaptado a cada etapa e indica cuándo la etapa siguiente es segura.

Análisis DMARC gratuito del dominio o crear una cuenta. Para el contexto completo, ver este nuevo estándar explicado de forma sencilla.