Por qué DMARCbis y por qué ahora
RFC 7489, publicada en 2015 como documento Informational, dejó tres lagunas: la etiqueta pct permitía aplicar la política a solo X% de los mensajes, diluyendo la protección y haciendo impredecible el comportamiento de los receptores; la ausencia de una política específica para subdominios inexistentes dejaba un hueco explotable para el phishing; y la dependencia de la Public Suffix List (PSL) para identificar el dominio organizacional generaba inconsistencias entre implementaciones MTA. RFC 9989 (DMARC core), RFC 9990 (informes agregados) y RFC 9991 (informes de fallo) abordan cada uno de estos puntos, elevando el estándar al rango de Proposed Standard.
- RFC 9989 (núcleo DMARCbis) — hace obsoletas RFC 7489 y RFC 9091; introduce la etiqueta
np, eliminapct, la reemplaza por la etiquetat(modo prueba) y define Tree Walk DNS para identificar el dominio padre sin recurrir a la PSL - RFC 9990 (informes agregados) — extrae y moderniza la sección de reporting agregado de RFC 7489; los informes XML comprimidos en GZIP siguen siendo el formato pero la verificación de destinos externos se refuerza
- RFC 9991 (informes de fallo) — extrae el reporting de fallos; enfatiza los riesgos para la privacidad e impone limitación de velocidad en los generadores para prevenir abusos DoS
- Supresión de
pct— cualquier registro DMARC existente conpct=50(u otro valor) debe revisarse; los receptores conformes con RFC 9989 pueden ignorar esta etiqueta y aplicar la política al 100% de los mensajes - Tree Walk DNS — el receptor sube el árbol DNS mediante consultas sucesivas (máximo 8) para encontrar la política aplicable, eliminando la dependencia de la PSL y mejorando la coherencia entre implementaciones
Requisitos previos antes de intervenir
Antes de cualquier modificación, verifica que tu infraestructura cubre lo básico: SPF y DKIM deben estar correctamente configurados en tu dominio emisor — DMARCbis no añade nada a estos mecanismos pero depende enteramente de ellos. Asegúrate también de tener acceso a tus herramientas de auditoría (dig, nslookup, SSH a tu VPS) y a tu zona DNS. Por último, dispón de los informes agregados DMARC actuales (vía rua) para establecer una línea de base del tráfico legítimo antes de endurecer la política.
Audita tu registro DMARC actual
Ejecuta
dig TXT _dmarc.example.comdesde tu VPS o terminal. Anota el valor exacto de cada etiqueta:v,p,sp,pct,rua,ruf,adkim,aspf. Sipctaparece con un valor inferior a 100, planifica su eliminación.Elimina o reemplaza la etiqueta `pct`
En RFC 9989,
pctestá obsoleta. Su función de despliegue progresivo pasa a la etiquetat:t=yindica al receptor que trate el mensaje como si la política fuerap=none, sin aplicar cuarentena ni rechazo. Para migrar desdepct=50, reemplaza port=y, valida durante unas semanas con tus informes agregados y luego retirat=y. Ejemplo:v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]Añade la etiqueta `np` para subdominios inexistentes
La etiqueta
npdefine la política a aplicar a mensajes que afirman proceder de un subdominio que no existe en tu DNS. Para bloquear el phishing a través de subdominios inventados, añadenp=reject. Ejemplo completo:v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]Comprende Tree Walk DNS y publica en los niveles correctos
Con Tree Walk, un receptor que procesa un mensaje de
mail.app.example.comconsulta_dmarc.mail.app.example.com, luego_dmarc.app.example.com, luego_dmarc.example.com, deteniéndose en la primera respuesta válida (máximo 8 consultas DNS). Audita tus zonas DNS para detectar registros_dmarc.*no intencionados que puedan anular tu política principal.Actualiza el registro DNS final
Una vez revisadas las etiquetas, publica el registro actualizado. Ejemplo completo para un dominio en fase de endurecimiento:
v=DMARC1; p=quarantine; sp=quarantine; np=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1Comprueba la alineación DKIM en Postfix
Asegúrate de que
adkim=s(estricto) no entra en conflicto con subdominios que firman con una clave distinta. En modo estricto, el dominio del encabezadoFrom:debe coincidir exactamente con el dominiod=de la firma DKIM. En caso de duda, usa temporalmenteadkim=r(relajado) y analiza los informes agregados.Comprueba la alineación DKIM en Exim
Verifica en tu configuración de Exim que
dkim_domaincoincide exactamente con el dominio publicado en tu registro DMARC. Cualquier discrepancia bajoadkim=sprovoca un fallo DKIM y puede activar la política de cuarentena o rechazo.Prueba y valida los informes
Espera 24 a 48 horas y analiza los informes XML agregados recibidos en la dirección
rua. Los campos<policy_evaluated><dkim>y<policy_evaluated><spf>indican si tus mensajes superan la alineación. Herramientas como MXToolbox DMARCAnalyzer o mail-tester.com pueden analizar estos informes sin necesidad de escribir código.
Para validar rápidamente tu registro DMARC desde el VPS, ejecuta dig TXT _dmarc.example.com +short y pega el valor en el comprobador DMARC de MXToolbox (mxtoolbox.com/dmarc.aspx). Detecta etiquetas desconocidas, conflictos pct/t e indica si el registro es sintácticamente válido según RFC 9989. Para simular un Tree Walk, ejecuta dig TXT _dmarc.subdominio.example.com y dig TXT _dmarc.example.com en secuencia y compara las políticas devueltas en cada nivel.
Resolución de problemas frecuentes
La mayoría de los problemas tienen una causa determinista — aquí los más frecuentes y cómo resolverlos.
pctignorado por un receptor — Si los MTA conformes con RFC 9989 ignoran tupct=50y aplican la política al 100% de los mensajes, tus informes mostrarán un aumento repentino de rechazos o cuarentenas. Añadet=yde inmediato para pasar a modo prueba mientras adaptas tu infraestructura.- Política
npdemasiado restrictiva — Si un servicio legítimo envía desde un subdominio no publicado en DNS,np=rejectbloqueará esos mensajes. Empieza pornp=quarantiney analiza los informes antes de pasar areject. - Tree Walk produce una política inesperada — Si encuentras un registro
_dmarc.app.example.comhuérfano de un servicio antiguo, los receptores Tree Walk lo aplicarán primero. Elimina los registros_dmarc.*no utilizados tras un inventario completo de tus zonas DNS. - Informes agregados vacíos o ausentes — Comprueba que la dirección
ruasea accesible y que tu MX acepte informes XML comprimidos en GZIP. Algunos filtros antispam bloquean archivos adjuntos.gz. Verifica también el tamaño máximo de mensaje aceptado por tu servidor de recepción de informes. - Discrepancia
adkim=scon Postfix multidmonio — Si usas una sola instancia de Postfix para varios dominios y la clave DKIM firma bajoexample.commientras queFrom:contienenewsletter.example.com, la alineación estricta fallará. Añade una clave DKIM dedicada por subdominio o cambia aadkim=rpara esos dominios.
RFC 7489 vs RFC 9989: las diferencias que importan
La tabla siguiente resume las diferencias estructurales entre las dos especificaciones.
Desplace la tabla
| Punto | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| Etiqueta `pct` | Presente — aplica la política a X% de los mensajes para un despliegue progresivo | Eliminada — reemplazada por `t=y` (modo prueba); cualquier receptor conforme aplica la política al 100% de los mensajes |
| Subdominios inexistentes | Sin etiqueta dedicada — `sp` o `p` se aplica por defecto | Etiqueta `np` introducida — política diferenciada para subdominios ausentes del DNS |
| Descubrimiento del dominio padre | Basado en la Public Suffix List (PSL), mantenida fuera de la IETF, varía por implementador | Tree Walk DNS — sube el árbol DNS mediante consultas sucesivas, máximo 8, definido en el estándar |
| Informes | Agregados y de fallo en una sola RFC 7489 | Tres RFC independientes: 9989 (núcleo), 9990 (agregado), 9991 (fallo) — mejor extensibilidad |
| Estado | Informational — valor de referencia pero fuera del Standards Track | Proposed Standard (Standards Track) — autoridad IETF plena, base para implementaciones futuras de MTA |
Adapta ahora o gestiona las consecuencias después
DMARCbis no está aún aplicado de forma uniforme por todos los MTA — Google, Microsoft y Yahoo han anunciado fases de prueba para Tree Walk pero no se ha comunicado ninguna fecha de corte oficial. Esto no justifica la espera: RFC 9989, 9990 y 9991 están en el Standards Track, la implementación progresiva está en marcha y las primeras divergencias en la interpretación de pct entre receptores ya están apareciendo. Eliminar pct, añadir np y auditar tus zonas DNS para Tree Walk son acciones defensivas que no rompen nada en receptores aún en RFC 7489 — np es ignorado por los MTA más antiguos, y eliminar pct solo tiene efecto si el receptor ya aplica RFC 9989. El coste de adaptarse es bajo; el de una política aplicada de forma parcial por un ecosistema de receptores mixtos no lo es.
