Llegó RFC 9989: Cómo Excello Mail Ya Es Compatible con el Nuevo Estándar DMARC

El IETF publicó RFC 9989 el 12 de mayo de 2026, cerrando el trabajo que la comunidad de seguridad del correo electrónico viene llamando “DMARCbis” desde hace cinco años. Es la primera revisión sustancial de DMARC desde que RFC 7489 salió en 2015 y contiene cambios suficientes para que toda plataforma de monitoreo DMARC, todo receptor de informes y todo propietario de dominio que publique un registro deba prestar atención.

Llevamos años siguiendo el borrador a lo largo de cuarenta y una revisiones dentro del grupo de trabajo DMARC del IETF. Hoy nos complace confirmar que Excello Mail ya analiza, valida y genera registros DMARC con el nuevo conjunto de etiquetas de RFC 9989, y que nuestro pipeline de ingestión de informes agregados lee las adiciones de esquema de RFC 9990 de fábrica.

Qué Cambia Realmente en RFC 9989

RFC 9989 reemplaza a RFC 7489 y a RFC 9091. Los dos documentos complementarios, RFC 9990 (informes agregados) y RFC 9991 (informes de fallos), recogen las partes del formato de informes que antes estaban dentro de la especificación original. Juntos forman el nuevo estándar DMARC.

Los cambios sustanciales se agrupan en tres áreas.

1. El Conjunto de Etiquetas Es Distinto

Llegan tres etiquetas nuevas, una desaparece y el resto se mantiene.

• np= (nueva). Política de Subdominio Inexistente. Los receptores la aplican cuando un mensaje afirma venir de un subdominio que no existe en DNS. Valores: none, quarantine o reject. Sección 4.7.
• t= (nueva). Modo de Prueba. Cuando vale y, la política publicada está en modo de prueba y los receptores deben tratar las acciones como recomendación, no como obligación. Sustituto del antiguo papel de la etiqueta pct. Sección 4.7.
• psd= (nueva). Bandera de Dominio de Sufijo Público. La usan los operadores de Sufijos Públicos (los operadores de .co.uk, .gov.au, etc.) para indicar si su registro está en un PSD o en un Dominio Organizacional. Valores: y, n, u. Sección 4.10.
• pct= (eliminada). La etiqueta de porcentaje desaparece. El Apéndice A.6 de RFC 9989 documenta su retirada. Los registros existentes siguen funcionando, pero los nuevos deberían usar t=y para el modo de prueba.

2. El Dominio Organizacional Ahora Viene del DNS, No de una Lista

El cambio arquitectónicamente más importante. RFC 7489 indicaba a los receptores que dedujeran el Dominio Organizacional (el dominio que posee la política a la que los subdominios deben recurrir) consultando una Public Suffix List. La PSL la mantiene Mozilla, depende de un repositorio centralizado en GitHub y produce resultados inconsistentes entre receptores que usan distintas instantáneas.

RFC 9989 reemplaza la PSL por la Caminata por el Árbol DNS. El algoritmo está en la Sección 4.10. En lenguaje claro: partiendo del dominio en el encabezado From del mensaje, el receptor consulta _dmarc.<ese-dominio>. Si no hay nada, quita la etiqueta más a la izquierda y vuelve a consultar. Sigue subiendo por el árbol hasta encontrar un registro DMARC o topar con la etiqueta psd= de un operador de Sufijo Público. La caminata está limitada a ocho consultas para evitar abusos.

¿El resultado? El propio DNS, y no una lista externa, determina dónde está la frontera del Dominio Organizacional. Los operadores de sufijos pueden publicar sus propios registros DMARC con psd=y para marcar la frontera explícitamente. Como efecto colateral, los propietarios de dominios obtienen que un subdominio sin su propio registro DMARC ahora hereda de forma fiable del padre a través del DNS, no de la instantánea de PSL que casualmente tuviera cargada el receptor.

3. Los Formatos de Informe Recibieron Adiciones de Esquema

El formato XML de informes agregados (RUA) en RFC 9990 ahora lleva elementos opcionales version, discovery_method, np y testing sobre policy_published, convierte el elemento selector de DKIM en parte obligatoria de cada entrada de auth_results y añade los campos opcionales human_result y scope para diagnósticos más ricos.

El formato de informes de fallos (RUF) en RFC 9991 introduce un encabezado obligatorio Identity-Alignment que enumera los mecanismos que fallaron al autenticar una identidad alineada, además de los campos DKIM-Domain, DKIM-Identity, DKIM-Selector y SPF-DNS con el mismo propósito. También oficializa Auth-Failure: dmarc.

Qué Significa Esto para Tu Dominio

Nada se rompe de inmediato. Los registros RFC 7489 siguen siendo interpretados correctamente por todas las implementaciones que conocemos, incluida la nuestra. Los receptores irán desplegando el soporte para RFC 9989 de manera gradual, y se espera que los grandes proveedores de buzón vayan primero.

Dicho esto, dos recomendaciones prácticas:

1. Si publicas pct= hoy, planifica migrar a t=y cuando revises tu registro la próxima vez. Los receptores seguirán tolerando la etiqueta obsoleta durante mucho tiempo, pero la señal más limpia para “política en modo de prueba” ahora es la etiqueta nueva.
2. Si administras un dominio con varios subdominios, considera establecer np= de forma explícita. Hoy muchas plataformas se ven afectadas por correo falsificado desde subdominios inexistentes, y np=reject es la manera más limpia de cerrar ese vector.

Cómo Lo Soporta Excello Mail

Nuestro trabajo de las últimas dos semanas puso al día cada parte de la plataforma respecto a RFC 9989, RFC 9990 y RFC 9991:

• Analizador de registros DMARC. Nuestra página /details/dmarc ahora muestra np, t y psd cuando están presentes, con descripciones completas de lo que significa cada etiqueta. Si tu registro publicado usa pct=, lo mostramos (ningún registro se rompe) y destacamos la desaprobación de RFC 9989 en la información sobre el campo.
• Caminata por el Árbol DNS. Nuestro módulo de descubrimiento de política sube por la jerarquía DNS desde el dominio autor, respeta los límites psd= y el tope de ocho consultas. Los subdominios sin su propio registro DMARC ahora heredan correctamente del Dominio Organizacional.
• Ingestión de informes agregados. Nuestro pipeline RUA extrae cada elemento nuevo de RFC 9990. El selector DKIM, las cadenas de diagnóstico legibles, el ámbito SPF y los identificadores envelope-from / envelope-to se analizan y almacenan de forma relacional. Sin blobs JSON.
• Procesamiento de informes de fallos. Nuestro parser ARF lee los nuevos campos Identity-Alignment, DKIM-Selector, DKIM-Domain, DKIM-Identity y SPF-DNS, y reconoce Auth-Failure: dmarc como un tipo de fallo de primera clase.
• Generador de registros. Nuestra herramienta /generate/dmarc ofrece np y t como opciones configurables. Quitamos el campo pct para registros nuevos porque RFC 9989 lo elimina, y explicamos ese cambio junto al formulario. Traducido al inglés, español y portugués.

Si publicas o monitoreas registros DMARC, tu instrumental debe mantenerse al día con el nuevo estándar. La forma más sencilla de seguir el ritmo es delegar el trabajo.

Prueba Excello Mail

Excello Mail es una plataforma de monitoreo DMARC totalmente gestionada. Recibimos tus informes agregados y de fallos, los analizamos contra los últimos estándares (ahora incluyendo RFC 9989, RFC 9990 y RFC 9991), mostramos cómo se ve realmente tu tráfico desde cada fuente que autentica, y te guiamos desde p=none hasta p=reject sin romper tus flujos de correo legítimo.

Comienza tu prueba gratis en excello.email

¿Tienes una duda sobre cómo te afecta algún cambio específico de RFC 9989? Crea una cuenta y nuestro equipo revisará contigo tu registro publicado.