← Blog

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

Por Thomas · CISO virtual · 2026-07-01

Si ya has desplegado DMARC siguiendo una guía, sin duda te has cruzado con la etiqueta pct: ese pequeño porcentaje que supuestamente aplicaba la política a una fracción creciente del correo (pct=25, luego 50, luego 100). DMARCbis (2026) la suprime. En su lugar, encontramos una etiqueta más simple y más honesta: t, un modo de prueba binario. Esta guía explica por qué desaparece pct, cómo funciona t=y, y sobre todo cómo desplegar DMARC por fases en la era post-pct. Para el panorama de DMARCbis, mira DMARCbis explicado de forma sencilla.

Por qué desaparece pct

Sobre el papel, pct era seductora: aplicar p=quarantine al 10 % del correo en fallo, observar, y luego subir. En la práctica, la etiqueta planteaba varios problemas:

  • Un comportamiento imprevisible. La interpretación de pct variaba de un destinatario a otro. «25 %» no quería decir lo mismo en todas partes, y la muestra no siempre era representativa.
  • Una falsa seguridad. Un pct=10 daba la impresión de «probar» cuando el 90 % del correo en fallo seguía tratándose como en p=none; muchos equipos creían endurecer mientras seguían, de hecho, en observación.
  • Una complejidad inútil. Gestionar un cursor de porcentaje añadía una variable más a un despliegue ya delicado, sin beneficio fiable.

El grupo de trabajo de DMARCbis zanjó el asunto: más vale una señal clara que un porcentaje difuso. pct queda, por tanto, retirada del estándar (RFC 9989).

Lo que hace la etiqueta t

La nueva etiqueta t (por test) es binaria:

  • t=y — modo de prueba. Señalas a los destinatarios: «estoy experimentando con esta política, no la apliques aún estrictamente; envíame los informes como si estuviera activa». Útil para observar el efecto de un endurecimiento antes de que muerda de verdad.
  • t=n (o etiqueta ausente) — modo normal. La política p/sp/np se aplica plenamente.
_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@ton-domaine.fr"

Aquí, declaras p=quarantine pero con t=y: ves en tus informes lo que se pondría en cuarentena, sin que el correo legítimo que hubieras olvidado se vaya realmente a no deseados. Cuando los informes están limpios, retiras t=y y la política muerde de verdad.

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 tus correos:

  1. p=none — observación pura. Recoges los informes e inventarías tus fuentes.
  2. Alinear cada fuente legítima (SPF/DKIM), hasta que los informes estén limpios.
  3. p=quarantine con t=y — declaras la cuarentena en modo de prueba: verificas 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, tienes 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 dejo pct en mi registro?

Nada grave. Las implementaciones actualizadas de DMARCbis simplemente ignoran pct. No rompes 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, te encontrarás con:

  • 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: no cuentes con t=y como 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 te ayuda a observar, pero es la limpieza de tus informes lo que te dice que estás listo, no la etiqueta. Para leer estos informes, mira 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. Publicas:

v=DMARC1; p=none; rua=mailto:rapports@ton-domaine.fr

No tocas nada más. Los informes empiezan a llegar; descubres tus fuentes (plataforma de correo, CRM, facturación, una herramienta olvidada).

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

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

v=DMARC1; p=quarantine; t=y; rua=mailto:rapports@ton-domaine.fr

Con t=y, observas lo que se pondría en no deseados sin arriesgarte a enviar allí una fuente legítima olvidada. Vigilas unos días.

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

v=DMARC1; p=quarantine; rua=mailto:rapports@ton-domaine.fr

Semana 7 — reject. Misma lógica: eventualmente p=reject; t=y unos días, luego retiras t=y y añades np=reject para bloquear los subdominios inexistentes. Has alcanzado la aplicación.

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 sabes qué buscas en ella. Durante una fase t=y, separa el tráfico en fallo de tus informes en dos montones. Primero, las fuentes que reconoces —una plataforma, una herramienta, un socio que envía por tu 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 que no reconoces: esos fallos son la política haciendo exactamente lo que esperas 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. Dimensiona también la ventana según tus 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 tu política: no estás realmente protegido. Retíralo en cuanto los informes estén limpios.
  • Creer que t=y protege en todas partes. Los destinatarios antiguos ignoran t y aplican tu política plenamente. Así que incluso con t=y, un p=reject puede morder en algunos. No declares una política estricta hasta que estés listo para asumirla en todas partes.

Preguntas frecuentes sobre t

¿Debo usar obligatoriamente t=y? No. Es una herramienta de observación útil durante un endurecimiento, pero puedes perfectamente subir p=none → quarantine → reject vigilando simplemente tus 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. Aprovecha un cambio de registro 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 «sé más amable con mi correo»; les dice «esta política está en prueba, no la apliques aún estrictamente». Tu 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: te 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 tu 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: servirte de t=y como una ventana de observación durante un endurecimiento, sabiendo que algunos destinatarios ya aplicarán la política de verdad. Vigilas tus informes agregados; en cuanto están limpios, retiras t=y y la política muerde en todas partes. No te quedes nunca bloqueado en t=y «por prudencia»: sería creer que estás 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 apliques 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 tus informes estén limpios, nunca un destino.

Deja que Thomas pilote 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, tu CISO virtual, toma por ti a partir de tus datos reales. Genera el registro DMARCbis adaptado a cada etapa y te dice cuándo la etapa siguiente es segura.

Analiza tu dominio gratis → o crea una cuenta. Para el contexto completo, mira este nuevo estándar explicado de forma sencilla.

¿Listo para aplicar DMARC?

Thomas, tu CISO virtual, identifica cada fuente de envío legítima, escribe los registros DNS exactos y lleva tu dominio de p=none a p=reject — sin romper tu correo.

Alcanzar p=reject — gratis

Guías relacionadas

Sobre el autor

ThomasThomas es el CISO virtual de DMARC.com: un copiloto especializado en la autenticación de correo que acompaña a las organizaciones de p=none hasta p=reject, sin romper su correo. Sus guías se basan en los datos reales del Observatorio DMARC y de los informes RUA analizados por la plataforma.