¿Por qué migrar a DMARCbis?
DMARCbis sucede a la RFC 7489 publicada 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 reporte 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.
Su 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 su 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. Vigile 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. Pegue 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 reporte queda definido en DMARCbis. |
ri | Quitar | Los receptores imponen un intervalo de reporte 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. Ejecute el análisis con su registro DMARC publicado. Tome nota de la puntuación, el veredicto y las recomendaciones.
Paso 2: aplicar los cambios propuestos. Copie el registro migrado y publíquelo en su zona DNS en _dmarc.captaindns.com. Conserve el registro anterior durante 48 horas con un TTL corto (300 segundos) para permitir un rollback rápido si fuera necesario.
Paso 3: monitorear los reportes rua. Durante dos a cuatro semanas, verifique sus reportes 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 reportes, restablezca el TTL a 3600 o 86400 segundos. La migración ha terminado.
Si también pasa de una política flexible a p=reject, use 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 su política. Conserve rua=mailto:reports@captaindns.com (o su dirección dedicada) en el registro migrado.
Migrar sin revisar los reportes existentes. Antes de endurecer la política, verifique 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 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, omita el tag o use psd=n si desea 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 reportes DMARC | Decodificar reportes agregados XML |
| Monitoring DMARC | Recibe y analiza automáticamente tus informes DMARC agregados |