Mailgun: DMARCbis ha muerto

Mailgun: DMARCbis ha muerto. Larga vida a DMARC. 

El protocolo DMARC actualizado ya está aquí. Te contamos qué ha cambiado, qué se mantiene igual, y qué implica cuando envías a través de Mailgun.

Justo cuando te estabas haciendo con las nuevas políticas DMARC.
En mayo de 2026, el IETF (Grupo de Trabajo de Ingeniería de Internet) publicó un nuevo conjunto de RFC de DMARC que reemplaza a los documentos técnicos RFC 7489: RFC 9989 (protocolo DMARC principal), RFC 9990 (informes agregados) y RFC 9991 (informes de fallos). Ahora, DMARCbis, conocido anteriormente como el borrador de la “próxima versión de DMARC”, es el estándar DMARC publicado. 

¿Por qué es esto importante?
Este cambio es importante porque los proveedores de servicios de email esperan cada vez más que el comportamiento base de los remitentes sea un email autenticado y alineado. Los RFC de DMARC actualizados no cambian esas expectativas de forma radical, pero aclaran y formalizan las prácticas con las que muchos remitentes y ESP ya operan hoy en día. 

En el caso de los remitentes de Mailgun, vale la pena entender esto, pero no implica que sea el momento de poner tu DNS patas arriba a la carrera. Los fundamentos son los mismos: autentica el email, mantén los identificadores alineados, haz un seguimiento de los informes y pon solución a los flujos que no cuadran.

El estándar actualizado es más limpio, más explícito y está mejor alineado con cómo funciona la autenticación de emails a gran escala en la fase de producción. Para la mayor parte de los remitentes que ya utilizan dominios autenticados e identificadores alineados correctamente, esta actualización del RFC resulta más evolutiva que disruptiva.

En general, los RFC actualizados reestructuran, aclaran y modernizan la documentación de DMARC; no cambian esencialmente el modelo de evaluación principal de DMARC de «conformidad con SPF o conformidad con DKIM».

• Tres RFC en lugar de uno: el RFC 9989 abarca la política y la conformidad, el RFC 9990 los informes agregados y el RFC 9991 los informes de fallos. 

• Recorrido del árbol DNS (DNS Tree Walk) para llegar a las políticas: Los receptores pueden recorrer la jerarquía del DNS de forma ascendente en lugar de depender de una lista estática de sufijos públicos. En la práctica, esto afecta principalmente a las estructuras de dominio muy grandes o complejas (como algunos entornos .edu, .gov o de sufijos públicos) y requiere cambios de implementación por parte del receptor. La mayor parte de los remitentes debería seguir publicando registros DMARC explícitos en los dominios que usan activamente para su email, en vez de depender del comportamiento alternativo del dominio de la organización.

• Cambios de etiqueta: se añaden nuevas etiquetas como «np» (que define la política para los subdominios inexistentes) y «psd» (que marca explícitamente los dominios de sufijo público); se eliminan las etiquetas obsoletas como «pct», «rf» y «ri»; una nueva etiqueta «t» describe mejor el modo de prueba. 

Si llevas registros DMARC, es posible que con el tiempo decidas eliminar etiquetas retiradas como «pct», «rf» y «ri» por motivos de higiene y legibilidad, aunque lo esperado es que los receptores ignoren las etiquetas desconocidas u obsoletas. Es poco probable que la mayoría de los remitentes necesiten la nueva etiqueta «psd», mientras que «np» puede resultar relevante para las organizaciones que gestionan estructuras de subdominio grandes o complejas.

Esto es lo que los clientes de Mailgun deberían tener muy presente:

La autenticación DMARC se sigue pasando cuando el dominio visible en el campo «From» se alinea con SPF o DKIM, no solo cuando es con ambos. 

DMARC sigue evaluando si el dominio del autor (el campo «From» visible) coincide con un identificador autenticado de: 

• SPF (dominio MAIL FROM / Return‑Path)

• DKIM (dominio de firma identificado mediante el valor «d=»)

La conformidad sigue operando bajo una política estricta (coincidencia exacta) o relajada/flexible (mismo dominio organizativo, como mg.ejemplo.com y ejemplo.com).

También vale la pena separar la conformidad del dominio de la reputación de la dirección IP. Las diferencias entre las IP compartidas y las IP dedicadas tienen efectos sobre la gestión de la reputación, el calentamiento y la visibilidad de la resolución de problemas, pero no cambian fundamentalmente cómo funciona la conformidad con DMARC. Tanto si envías a través de una infraestructura compartida o dedicada, DMARC sigue evaluando si tu dominio visible en «From» se corresponde con los identificadores SPF o DKIM autenticados.

DMARC sigue basándose en “conformidad con SPF o DKIM», no en que “SPF, DKIM y DMARC se aprueben de forma independiente”. Pasar la autenticación DMARC no garantiza llegar a la bandeja de entrada; demuestra el uso autorizado del dominio, mientras que la reputación, la interacción y el contenido siguen determinando dónde llega el mensaje.

Aquí es donde se unen las especificaciones y lo que haces en el panel de control de Mailgun.

Cómo usa Mailgun tus dominios autenticados

Cuando añades un dominio de envío (a menudo un subdominio como mg.ejemplo.com) en Mailgun:

• Mailgun te da registros TXT SPF y DKIM para publicar en ese dominio, junto con registros MX y registros CNAME de seguimiento opcionales.

• El dominio debe verificarse antes de que puedas enviar; el flujo de dominio autenticado estándar de Mailgun requiere una clave DKIM válida en el DNS antes de que el dominio se considere y trate como autenticado por completo.

Una vez que eso esté hecho:

• Mailgun firma el email saliente con DKIM utilizando tu dominio de envío en el valor «d=», por ejemplo d=mg.ejemplo.com.

• El MAIL FROM / Return-Path generalmente se basa en tu dominio de envío de Mailgun

Mailgun puede enviar emails completamente conformes con SPF usando tus subdominios autenticados, no solo con direcciones MAIL‑FROM en un dominio que sea propiedad del proveedor por defecto.

En otras palabras, en el flujo de dominio autenticado estándar, Mailgun autentica los emails en tus dominios, por lo que la conformidad reside en tu parte del proceso.

Si usas el patrón convencional de Mailgun de subdominios de envío dedicados, con SPF y DKIM proporcionados por Mailgun en esos dominios, y un dominio «From» coincidente, entonces tanto la conformidad con SPF como con DKIM se pueden lograr sin soluciones alternativas especiales. 

La Seguridad automática del remitente (ASS) no cambia lo anterior: automatiza la generación de claves y la rotación para los selectores de tu dominio, pero la firma sigue usando tu dominio con el valor «d=». 

Puedes mantener tu arquitectura actual. Pero debes asegurarte de que coincida con lo que DMARC describe ahora de forma más clara.

1. Haz un inventario de los dominios de Mailgun y su uso
   • Enumera todos los dominios verificados por Mailgun y qué flujos (transaccionales, de marketing, de notificaciones de aplicaciones, etc.) usa cada uno.
   • Retira o refuerza el protocolo DMARC en los dominios que ya no se usan de forma activa, especialmente si aún tienen registros permisivos.
2. Verifica la conformidad con SPF y DKIM, no solo que aparezca «pass» (aprobado)
   • Confirma que SPF esté publicado correctamente en cada dominio de envío de Mailgun y que esos dominios compartan un dominio organizativo con el campo «From» visible. 
   • Usa un analizador de encabezados para confirmar que «d=» en la firma DKIM coincida con tu dominio de envío de Mailgun (o un subdominio de tu organización), y no con un nombre de host no relacionado. 
3. Limpia tus registros DMARC
   • Elimina las etiquetas «pct», «rf» y «ri», que las nuevas especificaciones han descartado. 
   • Considera si «np» y «psd» son relevantes para tu estructura de dominio. 
   • Confirma que tu comportamiento de la etiqueta «sp=» para subdominios sea deliberado. 

4. Considera los informes agregados como un sistema de alerta temprana
   • Usa los informes DMARC agregados para detectar nuevos dominios de Mailgun, flujos heredados olvidados o remitentes de terceros no conformes que utilicen tu dominio.
   • Si el valor es «p=none», tómatelo como una situación que requiere un seguimiento activo, no como algo que harás «en algún momento». 

5. Separa DMARC y DKIM2 mentalmente
   • Vas a oír más sobre DKIM2, pero se trata de un esfuerzo de protocolo separado centrado en modelos de firma y protecciones contra las repeticiones.
   • La actualización del RFC de DMARC no convierte DKIM2 en un requisito, y las evaluaciones actuales de DMARC todavía se basan en SPF y DKIM, exactamente igual que antes. En el IETF se está debatiendo sobre si DKIM2 podría llegar a desempeñar un papel en futuras evaluaciones tipo DMARC, pero este trabajo sigue siendo independiente y por ahora es una cuestión por resolver.

DMARCbis ha muerto. Larga vida a DMARC. Para la mayor parte de los clientes de Mailgun que ya utilizan correctamente dominios autenticados e identificadores alineados, los nuevos RFC deberían parecerse más a una aclaración de las mejores prácticas existentes que a un cambio operativo importante. 

Autor: Alison Gootee