¿Por qué migrar a DMARCbis?
DMARCbis sucede al RFC 7489 publicado en 2015. La RFC 9989 introduce cuatro cambios estructurales:
- Eliminación de
pct,rf,ri: la política se aplica ahora al 100% del tráfico, queda definido un solo formato de informe y el intervalo de remisión queda impuesto por defecto. El tagfose mantiene. - Adición de
np: la política de subdominios inexistentes se vuelve explícita, cerrando una brecha explotada por atacantes que inventan subdominios ficticios. - Conversión
pct<100at=y: el modo de prueba reemplaza el porcentaje. Más simple, más predecible, más alineado con el comportamiento real de los receptores. - Tree walk DNS para identificar el dominio organizacional, en reemplazo de la Public Suffix List.
Las RFC 9989, 9990 y 9991 se publicaron en mayo de 2026. La migración consiste ahora en retirar etiquetas históricas y comprobar np y el tree walk DNS.
Cómo funciona el analizador
La herramienta analiza tu registro DMARC v1, aplica las transformaciones DMARCbis y calcula una puntuación de compatibilidad DMARCbis sobre 100. El cálculo es local, sin resolución DNS ni llamada externa.
Los cinco veredictos posibles
| Veredicto | Puntuación | Significado |
|---|---|---|
| Configuración ya compatible | 90 a 100 | No se requiere ningún cambio o solo un ajuste menor de mantenimiento. |
| Migración parcial | 75 a 89 | Una a tres modificaciones menores (típicamente pct=100 redundante o np ausente). |
| Migración mayor | 50 a 74 | Cuatro cambios o más. Varios tags obsoletos presentes y política débil. |
| Registro inválido | 0 a 49 o estado inválido | Errores de sintaxis a corregir antes de la migración. |
| Sin registro | N/A | Campo vacío. Pega primero un registro DMARC antes del análisis. |
Las seis dimensiones de la puntuación
| Dimensión | Ponderación | Lo que mide la dimensión |
|---|---|---|
| Tags obsoletos ausentes | 40 puntos | Presencia de pct, rf, ri. Cuantos más, mayor la deducción. |
Tag np presente | 15 puntos | Política de subdominios inexistentes explícita. Hereda de sp o p si está ausente. |
| Fuerza de la política | 20 puntos | reject obtiene el máximo, quarantine una fracción, none un crédito mínimo. |
| Alineación DKIM y SPF | 10 puntos | adkim=s y aspf=s obtienen el máximo, r conserva una parte. |
rua configurado | 10 puntos | URI mailto válida para la remisión agregada. |
| Higiene sintáctica | 5 puntos | Registro bien formado y analizable. |
Tres factores prioritarios se muestran al inicio del resultado para explicar la puntuación de inmediato, antes del detalle dimensión por dimensión.
Los cambios clave DMARC a DMARCbis
Tags eliminados
| Tag | Acción | Por qué |
|---|---|---|
pct | Quitar | La política se aplica al 100% por defecto. Si pct<100, la herramienta convierte el valor en t=y. |
rf | Quitar | Solo un formato de informe queda definido en DMARCbis. |
ri | Quitar | Los receptores imponen un intervalo de informe por defecto. |
Tag agregado
| Tag | Valor | Por qué |
|---|---|---|
np | hereda de sp o p | Política para los subdominios inexistentes. Debe ser explícita en DMARCbis. |
Tags conservados sin cambios
v=DMARC1, p, sp, adkim, aspf, rua, ruf. Su semántica permanece idéntica.
Plan de migración recomendado
Paso 1: auditar el registro actual. Ejecuta el análisis con tu registro DMARC publicado. Toma nota de la puntuación, el veredicto y las recomendaciones.
Paso 2: aplicar los cambios propuestos. Copia el registro migrado y publícalo en tu zona DNS en _dmarc.captaindns.com. Conserva el registro anterior durante 48 horas con un TTL corto (300 segundos) para permitir un rollback rápido si fuera necesario.
Paso 3: monitorizar los informes rua. Durante dos a cuatro semanas, verifica tus informes DMARC agregados para confirmar la ausencia de impacto sobre los flujos legítimos. El paso a np puede revelar subdominios activos no documentados.
Paso 4: estabilizar el TTL. Una vez validados los informes, restablece el TTL a 3600 o 86400 segundos. La migración ha terminado.
Si también pasas de una política flexible a p=reject, usa t=y durante algunas semanas. Los receptores DMARCbis aplican entonces una política un nivel por debajo, lo que sirve de red de seguridad durante la fase de validación.
Errores comunes a evitar
Conservar pct=100. Este valor es redundante en DMARCbis. El tag completo puede eliminarse sin modificar el comportamiento.
Confundir np y sp. sp apunta a los subdominios existentes, np apunta exclusivamente a los subdominios inexistentes. Ambos tags son complementarios, no intercambiables.
Combinar pct y t. En DMARCbis, t siempre tiene precedencia. Es inútil conservar pct cuando t=y está presente.
Eliminar rua durante la limpieza. El reporting agregado es la única fuente de verdad sobre la eficacia de tu política. Conserva rua=mailto:reports@captaindns.com (o tu dirección dedicada) en el registro migrado.
Migrar sin revisar los informes existentes. Antes de endurecer la política, verifica qué remitentes legítimos aún no están alineados con SPF o DKIM. Migrar a p=reject sin este paso puede bloquear flujos internos.
Declarar psd=y sin ser un operador de registro. El tag psd=y está reservado para los operadores de sufijos públicos como .bank o .gov.uk. Para un dominio organizacional estándar, omite el tag o usa psd=n si quieres hacerlo explícito.
Herramientas relacionadas
| Herramienta | Utilidad |
|---|---|
| DMARCbis Checker | Auditar un dominio publicado contra DMARCbis con tree walk DNS |
| DMARC Checker | Verificar la publicación y resolver el registro DMARC desde el DNS |
| DMARC Validator | Validar la sintaxis de un registro DMARC v1 antes de publicar |
| Generador DMARC | Crear un registro DMARC o DMARCbis desde cero |
| Lector de informes DMARC | Decodificar informes agregados XML |
| Monitoring DMARC | Recibe y analiza automáticamente tus informes DMARC agregados |