¿Hay que migrar a DMARCbis? La checklist sin estrés

_dmarc.ton-domaine.fr.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:rapports@ton-domaine.fr"

Lo que NO hay que hacer

• No crees un segundo registro DMARC. Como antes, un solo registro _dmarc por dominio. Un segundo hace la política ambigua y puede ser ignorado.
• No saltes a p=reject con el pretexto de «modernizar», si todavía no has alineado todas tus fuentes. DMARCbis no cambia nada de esta regla de oro: endurecer sobre un inventario incompleto rompe correo legítimo. La secuencia sigue siendo la de alcanzar p=reject.
• No te precipites con psd. Esta etiqueta concierne a los operadores de dominios de sufijo público (registros), no a las organizaciones ordinarias.

En qué orden migrar

El orden depende de tu punto de partida.

Si ya estás en p=reject con una alineación limpia (el caso ideal):

1. añade np=reject;
2. retira pct;
3. verifica tus informes. Has terminado.

Si todavía estás en p=none o p=quarantine:

1. añade np=reject de inmediato (sin riesgo, independiente del resto);
2. continúa tu subida normal hacia p=reject (inventario → alineación → quarantine con t=y → reject);
3. retira pct de paso. La prioridad, en este caso, no es DMARCbis: es alcanzar la aplicación de la política.

Cómo verificar que todo va bien

Después de cada cambio, dos controles simples:

1. Relee tu registro con un analizador para confirmar la sintaxis y la presencia de las etiquetas esperadas (np, ausencia de pct) — nuestro analizador DMARC gratuito lo hace en unos segundos y te da una nota.
2. Vigila tus informes agregados unos días. Quieres ver: las fuentes legítimas siempre alineadas, y los subdominios inexistentes suplantados ahora en disposición reject. Aprende a leerlos en cómo leer los informes agregados.

Un ecosistema a dos velocidades, y es normal

Durante el periodo de transición, ten en cuenta que los destinatarios no adoptan DMARCbis todos a la vez. Un mismo mensaje puede, por tanto, ser evaluado por un servidor actualizado, que honra tu np=reject, y por otro que aún no conoce la etiqueta y la ignora sin más. Nada preocupante: es exactamente el comportamiento previsto por la retrocompatibilidad. La consecuencia práctica se lee en tus informes agregados — para un mismo tráfico suplantado sobre un subdominio inexistente, algunos destinatarios reportarán una disposición reject mientras otros aplicarán todavía tu política histórica. Esta heterogeneidad no es ni un fallo de tu configuración ni una señal de fracaso de la migración: se resolverá por sí sola a medida que las implementaciones se actualicen. Sobre todo, no «corrijas» tu registro para hacerla desaparecer.

¿Cuánto se tarda?

Para un dominio ya bien gestionado, la «migración» a DMARCbis se reduce a dos retoques de DNS — unos minutos, más el tiempo de propagación. Si todavía estás en p=none, el verdadero trabajo no es DMARCbis sino la alineación de tus fuentes, que puede tardar de unos días a unos meses según el tamaño de tu parque de envío (ver alcanzar p=reject sin romper tus correos).

Tres casos concretos, antes / después

Según tu punto de partida, la «migración» toma una forma diferente. Aquí van tres registros reales, antes y después.

Caso 1 — dominio ya protegido. Antes:

v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:rapports@ton-domaine.fr

Después:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@ton-domaine.fr

Se retira pct=100 (inútil) y se añade np=reject. Dos segundos de trabajo.

Caso 2 — dominio en monitorización. Antes:

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

Después (pones np de inmediato, y continúas tu subida hacia reject):

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

np=reject no depende de p: incluso en p=none, puedes bloquear los subdominios inexistentes sin riesgo.

Caso 3 — dominio aparcado (ningún envío). Antes: a menudo nada en absoluto. Después:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:rapports@ton-domaine.fr

Un dominio desde el que nunca envías debe rechazarlo todo. Es la configuración más estricta, y la más fácil de justificar.

Tres ideas falsas sobre la migración

• «Hay que pasar a v=DMARC2.» Falso. El identificador sigue siendo v=DMARC1. Si una herramienta te pide poner v=DMARC2, es una señal de alarma.
• «Mi viejo registro va a ser rechazado.» Falso. Un registro 7489 sigue siendo un registro DMARCbis válido. Nada «caduca».
• «Debo migrarlo todo el mismo día.» Falso. No hay fecha límite. Puedes añadir np hoy, retirar pct el mes que viene — o no tocar nunca un dominio ya sano. DMARCbis no impone ningún calendario.

Preguntas frecuentes sobre la migración

¿Cuántos dominios debo tratar? Todos los que poseas, incluidos aquellos desde los que nunca envías — son precisamente los más suplantados. Un parque multidominio merece una revisión; el principio (añadir np, retirar pct) es el mismo en todas partes.

¿Hay que avisar a mi proveedor de alojamiento o a mi proveedor de correo? No. La migración se reduce a editar un registro TXT en tu DNS. Si un proveedor gestiona tu DMARC por ti, pídele simplemente que añada np y retire pct.

¿Y si uso un servicio de monitorización DMARC? La mayoría se actualizan para reflejar DMARCbis (aparición de np, desaparición de pct en los informes). Verifica que tu herramienta interpreta bien np; si no, cambia de herramienta o añade la etiqueta a mano — sigue siendo válida pase lo que pase.

¿Debo rehacer mis claves DKIM o mi SPF? No, DMARCbis no toca ni SPF ni DKIM. Si tu autenticación funciona hoy, funciona después de la migración. Aprovecha de todos modos para verificar que tus claves DKIM están almacenadas en el lugar correcto, no en un fichero perdido por ahí.

Migrar un parque multidominio

Si gestionas varios dominios — es el caso de la mayoría de las organizaciones, aunque solo sea con sus dominios de marca y sus dominios aparcados — aborda la migración como una revisión, no como una urgencia. El método:

1. Inventaría todos tus dominios, incluidos los que ya no usas pero todavía posees. A menudo son los más expuestos, porque nadie los vigila.
2. Clasifícalos en dos grupos: los que envían correo (a tratar con cuidado, alineación incluida) y los que no envían (dominios aparcados, a pasar directamente a p=reject; sp=reject; np=reject).
3. Aplica los mismos dos retoques en todas partes: añadir np, retirar pct. Para los dominios aparcados, es la ocasión de publicar un primer registro estricto si no había ninguno.
4. Prioriza por exposición: empieza por tus dominios de marca de consumo, los más susceptibles de ser suplantados, antes que los dominios internos o técnicos.

El beneficio de un tratamiento agrupado es la coherencia: un parque donde cada dominio aplica la misma política estricta no deja ningún eslabón débil. Y como np=reject es sin riesgo, puedes desplegarlo sobre el conjunto de tu parque de una sola pasada, sin temer romper nada — ninguno de esos dominios emite desde un subdominio inexistente. Los informes agregados de cada dominio te confirmarán después que nada legítimo se ha visto afectado.

Un consejo de organización: designa un responsable de la postura DMARC del parque. Los dominios se desvían — un nuevo proveedor aquí, un subdominio de campaña olvidado allá — y sin nadie que vigile, un parque antes limpio degenera en silencio. La migración a DMARCbis es un buen momento para poner en marcha esta responsabilidad, ya que tocas de todos modos cada registro.

En breve

No hay ninguna migración obligatoria: DMARCbis es retrocompatible y tu registro v=DMARC1 sigue siendo válido. Los dos únicos retoques útiles son añadir np=reject y retirar pct. Si todavía estás en p=none, la verdadera prioridad sigue siendo alcanzar p=reject por el método habitual. Y sobre todo: nada de v=DMARC2, no existe.

Deja que Thomas haga la migración por ti

¿Dos líneas de DNS, pero sin ganas de equivocarte? Thomas, tu CISO virtual, lee el estado real de tu dominio, genera el registro DMARCbis exacto a publicar (np, t, sin pct), y verifica en tus informes que ninguna fuente legítima se ve afectada. Tú validas, pegas, y listo.

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