Mailgun: SPF, DKIM y alineación DMARC por subdominio

mg.ejemplo.es.            TXT    "v=spf1 include:mailgun.org ~all"
k1._domainkey.mg.ejemplo.es.  TXT    "k=rsa; p=MIIBIjANBgkq…"
mg.ejemplo.es.            MX     10 mxa.mailgun.org.
mg.ejemplo.es.            MX     10 mxb.mailgun.org.
email.mg.ejemplo.es.     CNAME  mailgun.org.

La alineación DMARC: el modo relajado en acción

DMARC solo valida un mensaje si SPF o DKIM pasa y se alinea con el dominio del From. La disposición por subdominio de Mailgun se apoya en la alineación relajada, que es el modo por defecto de DMARC.

En modo relajado, un subdominio se alinea con su dominio organizativo: mg.ejemplo.es se alinea con ejemplo.es. Así, un mensaje enviado con un From en @ejemplo.es, una firma DKIM d=mg.ejemplo.es y un sobre en el subdominio pasa DMARC en ambos mecanismos. Bajo DMARCbis, el dominio organizativo se determina mediante el DNS Tree Walk en lugar de la antigua Public Suffix List, pero el resultado es idéntico: el subdominio y el dominio raíz se reconocen como pertenecientes a la misma organización.

Un detalle merece precisarse sobre la cabecera From. Coexisten dos disposiciones: un From en @ejemplo.es — la más común, la identidad de marca —, que se apoya en la alineación relajada del subdominio, o un From directamente en @mg.ejemplo.es, que alinea entonces tanto en estricto como en relajado pero expone el subdominio técnico a los destinatarios. La primera es casi siempre preferible por la legibilidad de la dirección mostrada; la segunda solo se encuentra en flujos puramente de máquina donde la apariencia de la dirección importa poco.

El único caso en que esta disposición falla es la alineación estricta, que exige una correspondencia exacta del dominio. Una política DMARC que imponga adkim=s o aspf=s rompería la alineación de un envío vía mg.ejemplo.es bajo un From @ejemplo.es. Salvo necesidad precisa, el modo relajado sigue siendo la elección correcta — es lo que hace viable la disposición por subdominio. Los ejemplos de registros DMARC comentados muestran dónde se ajustan estas etiquetas de alineación.

Región US o UE: la residencia de datos

Mailgun opera dos regiones distintas, americana y europea, elegidas al crear el dominio de envío. La elección tiene dos efectos. El primero es técnico: la API y el punto de entrada SMTP difieren, y un dominio creado en una región debe gobernarse a través del endpoint de esa región — una confusión frecuente cuando un script heredado sigue apuntando al endpoint estadounidense para un dominio europeo.

El segundo efecto atañe a la residencia de datos. Para una organización sujeta a exigencias de soberanía, la región europea mantiene el tratamiento de los correos y de los registros asociados dentro de la UE. Esto es menos una cuestión de autenticación que de conformidad, pero se decide en el mismo momento — al crear el dominio — y se corrige mal a posteriori: cambiar de región implica recrear el dominio de envío y volver a colocar todos los registros. Mejor zanjarlo de entrada.

IP compartida, IP dedicada y puesta en carga

Mailgun ofrece dos regímenes de direcciones de emisión. Por defecto, los envíos pasan por un pool de IP compartido: la reputación se mancomuna allí entre clientes, lo que conviene a volúmenes moderados y arranca sin calentamiento. Más allá de cierto volumen regular, una IP dedicada se vuelve pertinente — la reputación pertenece entonces solo a la organización, pero se construye: una IP nueva debe calentarse, es decir, subirse en volumen de forma progresiva a lo largo de varios días, so pena de ser tratada como sospechosa por los proveedores destinatarios.

Esa elección no tiene efecto sobre la alineación DMARC — DKIM y SPF se alinean de la misma forma sea cual sea la IP emisora — pero pesa en la entregabilidad, y por tanto en la lectura de los informes. Una IP dedicada nueva puede ver una parte de sus mensajes diferidos durante el calentamiento, sin que nada falle del lado de la autenticación. Distinguir un problema de reputación de un problema de alineación es precisamente lo que permiten los informes agregados: el primero se lee en las tasas de entrega, el segundo en las columnas SPF y DKIM.

Los errores de configuración habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Colocar los registros en el dominio raíz. Configurar Mailgun en ejemplo.es en lugar de mg.ejemplo.es pierde el aislamiento de reputación y mezcla el SPF de la plataforma con el del correo humano — un enredo que complica todo diagnóstico posterior.

Confundir las regiones. Un dominio creado del lado UE pero gobernado a través del endpoint US no se autenticará como se espera, y los informes lo mostrarán.

Olvidar verificar el dominio en la consola. Como en otras plataformas, publicar los registros no basta: Mailgun debe constatar su propagación y marcar el dominio como verificado antes de que las firmas se apliquen realmente.

Endurecer la política demasiado pronto. Pasar a p=reject — o peor a la alineación estricta — antes de confirmar con los informes que todo el tráfico legítimo se alinea equivale a arriesgarse al rechazo de los propios envíos.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la consola de Mailgun, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados confirma que el tráfico de Mailgun se atribuye correctamente al dominio: la fuente correspondiente al subdominio de envío debe aparecer allí con DKIM y SPF alineados.

Basta una cadencia sencilla: una primera lectura unos días después de publicar el registro _dmarc, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. El tráfico de Mailgun se reconoce pronto por sus rangos de direcciones estables; toda fuente nueva o no alineada resalta de inmediato — un segundo dominio de envío olvidado, una región mal conectada, un selector DKIM nunca verificado. Una vez confirmada la alineación durante varios días y sobre el conjunto de los flujos, el paso a p=reject se hace sin riesgo. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.