Migración DMARC a DMARCbis

Guía de migración de DMARC a DMARCbis

¿Por qué migrar?

La migración de DMARC a DMARCbis no impone ninguna fecha límite. Sus registros DMARC actuales siguen funcionando. Sin embargo, usar una herramienta de migración le permite:

• Proteger subdominios inexistentes con el tag np, cerrando una brecha explotada por atacantes
• Simplificar la gestión eliminando tags ignorados por los receptores modernos
• Declarar su ámbito organizacional con psd=n, clarificando la jerarquía DNS para los receptores

Pasos de migración

1. Eliminar los tags obsoletos

2. Agregar el tag np

Elija una política para los subdominios inexistentes:

• np=reject: recomendado si p=reject (protección máxima)
• np=quarantine: enfoque intermedio
• np=none: solo monitoreo

Si np está ausente, se aplica la política de sp (luego la de p).

3. Evaluar el tag t

• Si actualmente usa pct=0 para el modo de prueba, cambie a t=y
• Si su política se aplica completamente, no se requiere ninguna acción (el valor predeterminado t=n es equivalente)
• No combine pct y t: t siempre tiene precedencia

4. Declarar psd si es pertinente

• Dominio organizacional (captaindns.com): psd=n declara que usted no es un sufijo público
• Registro (.bank, .gov.uk): psd=y permite la publicación de una política para todos los registrantes
• Por defecto: psd=u (indeterminado), el tree walk DNS determina el dominio organizacional

Ejemplo de migración

Antes:

v=DMARC1; p=reject; sp=quarantine; pct=100; ri=86400; rua=mailto:dmarc@captaindns.com

Después:

v=DMARC1; p=reject; sp=quarantine; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Modificaciones:

• pct=100 eliminado (equivalente al valor predeterminado t=n)
• ri=86400 eliminado (ignorado por los receptores)
• np=reject agregado (protección de subdominios inexistentes)
• psd=n agregado (declaración del ámbito organizacional)

Ejemplos reales de migración

A continuación, tres escenarios representativos que puede encontrar al migrar su registro DMARC a DMARCbis.

Escenario 1: registro con pct parcial

Antes:

v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@captaindns.com

Después:

v=DMARC1; p=quarantine; t=y; np=quarantine; rua=mailto:dmarc@captaindns.com

El valor pct=50 significa que la política solo se aplicaba a la mitad de los mensajes. En DMARCbis, este enfoque granular se sustituye por un modo binario. El tag t=y activa el modo de prueba: los receptores DMARCbis aplican la política un nivel por debajo (quarantine se convierte en none). El tag np=quarantine hereda de la política p para proteger los subdominios inexistentes.

Escenario 2: registro estricto sin tags obsoletos

Antes:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@captaindns.com

Después:

v=DMARC1; p=reject; sp=reject; np=reject; psd=n; rua=mailto:dmarc@captaindns.com

Este registro ya está limpio: no hay tags obsoletos que eliminar. Simplemente agregue np=reject para cubrir los subdominios inexistentes y psd=n para declarar que el dominio no es un sufijo público. La migración consiste en agregar dos tags sin modificar la política existente.

Escenario 3: registro con todos los tags obsoletos

Antes:

v=DMARC1; p=reject; pct=100; ri=86400; rf=afrf; rua=mailto:dmarc@captaindns.com

Después:

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@captaindns.com

Aquí se eliminan tres tags obsoletos a la vez. pct=100 corresponde al comportamiento predeterminado (aplicación completa), por lo que no se necesita ningún tag t. ri=86400 nunca influyó realmente en la frecuencia de los reportes. rf=afrf era el único valor posible, ahora implícito. El tag np=reject se agrega para una protección completa.

¿Qué sucede durante la transición?

El periodo de transición entre DMARC y DMARCbis no presenta ningún riesgo para la entregabilidad de sus correos. He aquí por qué:

• Los tags desconocidos se ignoran: los receptores que aún no soportan DMARCbis simplemente ignoran los tags np, t y psd. Continúan aplicando p, sp y rua como antes.
• La versión permanece v=DMARC1: DMARCbis no cambia el identificador de versión. Ningún receptor rechazará su registro por la actualización.
• El tag t en la práctica: un receptor DMARCbis aplica el modo de prueba si t=y está presente. Un receptor DMARC v1 no reconoce t y aplica la política p directamente al 100%. Esto significa que durante la transición, sus correos se benefician del nivel de protección más alto de ambos estándares.
• Adopción gradual: los grandes proveedores (Google, Microsoft, Yahoo) adoptan las nuevas especificaciones de forma progresiva. Se espera que la coexistencia de ambos comportamientos dure varios años.
• No se requiere acción urgente: sus registros DMARC actuales siguen siendo funcionales. La migración puede realizarse a su propio ritmo, sin ventana de mantenimiento ni interrupción de servicio.

Estrategia de despliegue recomendada

Para migrar de forma segura, siga estos cuatro pasos en orden:

Paso 1: Auditar el registro actual. Use nuestro DMARCbis Checker para analizar su registro DMARC publicado. La herramienta identifica los tags obsoletos y evalúa la conformidad con DMARCbis.

Paso 2: Eliminar los tags obsoletos. Retire pct, rf y ri de su registro. Estos tags no tienen efecto en DMARCbis y su presencia añade complejidad innecesaria a su configuración DNS.

Paso 3: Agregar los nuevos tags. Agregue np=reject (o la política de su elección) para proteger los subdominios inexistentes. Agregue psd=n para declarar explícitamente su ámbito organizacional. Ambas adiciones refuerzan su postura de seguridad del correo sin modificar la política principal.

Paso 4: Probar antes de aplicar. Si pasa de una política flexible (none o quarantine) a una política estricta (reject), use t=y durante algunas semanas. Supervise sus reportes agregados DMARC para verificar que ningún flujo legítimo se vea afectado. Una vez validados los reportes, retire el tag t (el valor predeterminado t=n aplica la política en su totalidad).

Errores comunes a evitar

Olvidar desactivar el modo de prueba. El tag t=y es útil durante la fase de validación, pero reduce intencionalmente el nivel de protección. Programe un recordatorio para cambiar a t=n (o eliminar el tag) después de su periodo de prueba.

Confundir np con sp. El tag sp define la política para los subdominios existentes. El tag np se dirige exclusivamente a los subdominios inexistentes, los que los atacantes fabrican para evadir las protecciones. Ambos tags cumplen funciones distintas y complementarias.

Eliminar el tag rua por accidente. Al limpiar su registro, asegúrese de conservar el tag rua que apunta a su dirección de reportes agregados. Sin reportes, pierde toda visibilidad sobre los intentos de suplantación y los problemas de alineación.

Declarar psd=y sin ser un registro. El tag psd=y está reservado para los registros de sufijos públicos (como .bank o .gov.uk). Si es propietario de un dominio organizacional estándar, use psd=n. Una declaración incorrecta podría enviar una señal errónea a los receptores y complicar el tree walk DNS.

Migrar sin revisar los reportes existentes. Antes de modificar su registro, analice sus reportes DMARC agregados recientes. Revelan qué remitentes legítimos aún no están alineados con SPF o DKIM. Migrar sin esta verificación corre el riesgo de bloquear flujos de correo legítimos al cambiar a una política más estricta.

Herramientas relacionadas

Antes de migrar, verifique la compatibilidad DMARCbis actual de su dominio con el DMARCbis Checker. El checker realiza un análisis tree walk DNS completo y detecta todos los tags obsoletos.

Para una auditoría DMARC completa, explore estas herramientas:

• Validador DMARC para validar la sintaxis de su registro DMARC
• Inspector DMARC para consultar y analizar el registro DMARC publicado en su dominio
• Generador DMARC para crear un nuevo registro DMARC
• Lector de reportes DMARC para decodificar reportes agregados XML

Más información sobre los cambios del protocolo: DMARCbis: todos los cambios y cómo prepararse.