Mailgun: DMARCbis ha muerto

Mailgun: DMARCbis ha muerto. Larga vida a DMARC. 

El estándar DMARC actualizado ya está aquí. Esto es lo que ha cambiado, lo que no, y lo que significa cuando envías a través de Mailgun. 

Justo cuando te estabas sintiendo cómodo con las nuevas políticas DMARC…
En mayo de 2026, el IETF publicó un nuevo conjunto de RFC de DMARC que reemplaza al RFC 7489: RFC 9989 (DMARC principal), RFC 9990 (informes agregados) y RFC 9991 (informes de fallos). DMARCbis, conocido anteriormente como el borrador de la “próxima versión de DMARC”, ahora es el estándar DMARC publicado. 

¿Por qué esto es importante?
Este cambio es importante porque los proveedores de servicios de email esperan cada vez más un email autenticado y alineado como comportamiento base del remitente. Los RFC de DMARC actualizados no cambian radicalmente esas expectativas, pero aclaran y formalizan las prácticas bajo las cuales muchos remitentes y ESP ya están operando hoy en día. 

Para los remitentes de Mailgun, vale la pena entender esto, pero no es un momento de «arrancar tu DNS para el viernes». Los fundamentos son los mismos: autentica tu email, mantén los identificadores alineados, supervisa tus informes y arregla los flujos que no cuadran. 

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

Los RFC actualizados en su mayoría refactorizan, aclaran y modernizan la documentación de DMARC; no cambian fundamentalmente el modelo de evaluación central de DMARC de «SPF alineado o DKIM alineado».

• Tres RFC en lugar de uno: el RFC 9989 cubre la política y la alineación, el RFC 9990 cubre los informes agregados y el RFC 9991 cubre los informes de fallos. 

• Recorrido del árbol DNS para el descubrimiento de la política: Los receptores pueden recorrer la jerarquía del DNS en lugar de depender de una lista de sufijos públicos estática. En la práctica, esto afecta principalmente a estructuras de dominio muy grandes o complejas (como algunos entornos .edu, .gov o de sufijos públicos) y requiere cambios de implementación del lado del receptor. La mayoría de los remitentes aún deberían publicar registros DMARC explícitos en los dominios que usan activamente para su email, en lugar de depender del comportamiento de alternativa del dominio organizativo.

• Cambios de etiqueta: se añaden nuevas etiquetas como np (política de subdominio inexistente) y psd (dominio de sufijo público); se eliminan las etiquetas obsoletas como pct, rf y ri; una nueva etiqueta t describe mejor el comportamiento de prueba. 

Si mantienes los registros DMARC, es posible que con el tiempo decidas eliminar etiquetas retiradas como pct, rf y ri por motivos de limpieza y legibilidad, aunque se espera 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 ser relevante para las organizaciones que gestionan estructuras de subdominio grandes o complejas.

La parte que los clientes de Mailgun deberían tener muy presente: 

DMARC sigue aprobándose cuando el dominio visible en el campo From se alinea ya sea con SPF o DKIM, no solo cuando ambos se alinean. 

DMARC todavía evalúa si el dominio del autor (el campo From visible) se alinea con un identificador autenticado de: 

• SPF (MAIL FROM / dominio de Return‑Path) 

• DKIM (d= dominio de firma) 

La alineación sigue siendo estricta (coincidencia exacta) o relajada (mismo dominio organizativo, como mg.example.com y example.com). 

También vale la pena separar la alineación del dominio de la reputación de dirección IP. Las IPs compartidas frente a las IPs dedicadas afectan 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 alineación de DMARC. Ya sea que envíes en infraestructura compartida o dedicada, DMARC sigue evaluando si tu dominio visible en From se alinea con identificadores SPF o DKIM autenticados. 

DMARC continúa dependiendo de “SPF o DKIM con alineación”, no de “que SPF, DKIM y DMARC se aprueben de forma independiente”. Aprobar DMARC todavía no garantiza la llegada a la bandeja de entrada; demuestra el uso autorizado del dominio, mientras que la reputación, la interacción y el contenido siguen decidiendo dónde llega el mensaje. 

Aquí es donde la especificación se encuentra con lo que haces en el panel de control de Mailgun. 

Cómo Mailgun usa tus dominios autenticados 

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

• Mailgun te da registros TXT de 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 espera una clave DKIM válida en el DNS antes de que el dominio sea tratado como completamente autenticado. 

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.example.com. 

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

Mailgun es capaz de enviar email completamente alineado con SPF utilizando tus subdominios autenticados, y no solo direcciones MAIL‑FROM en un dominio propiedad del proveedor de forma predeterminada. 

En otras palabras, en el flujo de dominio autenticado estándar, Mailgun autentica el email en tus dominios, por lo que la alineación reside de tu lado. 

Si estás usando 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 alineación de SPF como la de DKIM se pueden lograr sin soluciones alternativas especiales. 

La Seguridad automática del remitente (ASS) no cambia esa historia: automatiza la generación de claves y la rotación para los selectores de tu dominio, pero la firma todavía usa tu dominio en d=. 

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

1. Inventory Mailgun domains and usage 
   • Enumera todos los dominios verificados por Mailgun y qué flujos (transaccional, marketing, notificaciones de aplicaciones) usa cada uno. 
   • Retira o endurece DMARC en los dominios que ya no se usan activamente, especialmente si aún tienen registros permisivos. 
2. Verify aligned SPF and DKIM, not just “pass” 
   • 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 encabezado 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. Clean up your DMARC records 
   • Elimina las etiquetas pct, rf y ri, que la nueva especificación descarta. 
   • Considera si np y psd son relevantes para tu estructura de dominio. 
   • Confirma que tu comportamiento sp= para subdominios sea intencionado. 

4. Treat aggregate reports as an early‑warning system 
   • Usa los informes agregados de DMARC para detectar nuevos dominios de Mailgun, flujos heredados olvidados o remitentes de terceros desalineados que utilicen tu dominio. 
   • Si estás en p=none, trátalo como una supervisión activa, no como «lo miraremos algún día». 

5. Keep DMARC and DKIM2 mentally separate 
   • Oirás más sobre DKIM2, pero eso es un esfuerzo de protocolo separado centrado en modelos de firma y protecciones contra repeticiones. 
   • La actualización del RFC de DMARC no hace que DKIM2 sea un requisito, y las evaluaciones de DMARC de hoy todavía dependen de SPF y DKIM exactamente igual que antes. Hay un debate en curso en el IETF sobre si DKIM2 podría llegar a tener un rol en futuras evaluaciones de estilo DMARC, pero ese trabajo sigue separado y sin resolverse por ahora.

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

Author: Alison Gootee