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

_dmarc.ejemplo.es.  IN TXT
  "v=DMARC1; p=reject; sp=reject; np=reject; adkim=s; aspf=s; rua=mailto:informes@ejemplo.es"

Lo que NO hay que hacer

• No crear un segundo registro DMARC. Como antes, un solo registro _dmarc por dominio. Un segundo hace la política ambigua y puede ser ignorado.
• No saltar a p=reject con el pretexto de «modernizar», mientras no estén alineadas todas las 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 precipitarse 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 del punto de partida.

Un dominio ya en p=reject con una alineación limpia (el caso ideal):

1. añadir np=reject;
2. retirar pct;
3. verificar los informes. Terminado.

Un dominio todavía en p=none o p=quarantine:

1. añadir np=reject de inmediato (sin riesgo, independiente del resto);
2. continuar la subida normal hacia p=reject (inventario → alineación → quarantine con t=y → reject);
3. retirar 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. Releer el 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 da una nota.
2. Vigilar los informes agregados unos días. Lo que se busca ver: las fuentes legítimas siempre alineadas, y los subdominios inexistentes suplantados ahora en disposición reject. La lectura se aprende en cómo leer los informes agregados.

Un ecosistema a dos velocidades, y es normal

Durante el periodo de transición, conviene tener 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 el 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 los 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 su política histórica. Esta heterogeneidad no es ni un fallo de 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 hay que «corregir» el 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. Desde p=none, el verdadero trabajo no es DMARCbis sino la alineación de las fuentes, que puede tardar de unos días a unos meses según el tamaño del parque de envío (ver alcanzar p=reject sin romper el correo legítimo).

Tres casos concretos, antes / después

Según el 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:informes@ejemplo.es

Después:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:informes@ejemplo.es

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:informes@ejemplo.es

Después (se pone np de inmediato, y continúa la subida hacia reject):

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

np=reject no depende de p: incluso en p=none, bloquea 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:informes@ejemplo.es

Un dominio que nunca envía 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. Una herramienta que pida 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».
• «Hay que migrarlo todo el mismo día.» Falso. No hay fecha límite. np puede añadirse hoy, pct retirarse el mes que viene — o un dominio ya sano no tocarse nunca. DMARCbis no impone ningún calendario.

Preguntas frecuentes sobre la migración

¿Cuántos dominios hay que tratar? Todos los que posee la organización, incluidos aquellos desde los que nunca envía — 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 el DNS. Si un proveedor gestiona el DMARC por la organización, basta con pedirle que añada np y retire pct.

¿Y con 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). Conviene verificar que la herramienta interpreta bien np; si no, toca cambiar de herramienta o añadir 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. Una autenticación que funciona hoy funciona después de la migración. Es un buen momento, de todos modos, para verificar que las claves DKIM están almacenadas en el lugar correcto, no en un fichero perdido por ahí.

Migrar un parque multidominio

En una organización con varios dominios — es el caso de la mayoría, aunque solo sea con los dominios de marca y los dominios aparcados — la migración se aborda como una revisión, no como una urgencia. El método:

1. Inventariar todos los dominios, incluidos los que ya no se usan pero se siguen poseyendo. A menudo son los más expuestos, porque nadie los vigila.
2. Clasificarlos 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. Aplicar 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. Priorizar por exposición: empezar por los 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, se despliega sobre el conjunto del parque de una sola pasada, sin temer romper nada — ninguno de esos dominios emite desde un subdominio inexistente. Los informes agregados de cada dominio confirmarán después que nada legítimo se ha visto afectado.

Un consejo de organización: designar 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 toca de todos modos cada registro.

En breve

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

Thomas hace la migración

¿Dos líneas de DNS, pero sin ganas de equivocarse? Thomas, el CISO virtual, lee el estado real del dominio, genera el registro DMARCbis exacto a publicar (np, t, sin pct), y verifica en los informes que ninguna fuente legítima se ve afectada. Solo queda validar, pegar, y listo.

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