¿Por qué migrar a DMARCbis?
DMARCbis sucede al RFC 7489 publicado en 2015. El borrador 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.
Tu registro DMARC actual sigue funcionando durante la transición. Migrar ahora permite estar listo en la publicación oficial y beneficiarse de inmediato de la protección de subdominios inexistentes vía np.
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 |
|---|---|---|
| Ya conforme | 90 a 100 | Ningún cambio requerido o ajuste menor. Vigila la publicación oficial del RFC. |
| 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 |