DMARC falla aunque SPF pasa: entender la alineación

<policy_evaluated>
  <dkim>fail</dkim>
  <spf>fail</spf>
</policy_evaluated>
…
<auth_results>
  <spf>
    <domain>bounces.router-envios.net</domain>
    <result>pass</result>
  </spf>
</auth_results>

La alineación, la exigencia que añade DMARC

DMARC cierra exactamente ese hueco, y el principio general de DMARC se resume en eso: atar la autenticación técnica a la dirección que un humano ve de verdad. El veredicto DMARC es un pass si —y solo si— al menos uno de los dos mecanismos funciona y el dominio que validó se alinea con el dominio del From:. Para SPF, el dominio comparado es el del MAIL FROM; para DKIM, el d= de la firma.

La alineación existe en dos modos, regulados por dos etiquetas del registro DMARC. En modo relaxed (aspf=r, adkim=r, los valores por defecto, rara vez escritos), basta con compartir el mismo dominio organizativo: bounce.ejemplo.es se alinea con ejemplo.es. Desde DMARCbis, ese dominio organizativo se determina mediante el DNS Tree Walk —el ascenso por el árbol DNS— y ya no mediante la Public Suffix List. En modo strict (aspf=s, adkim=s), la igualdad debe ser exacta: bounce.ejemplo.es deja de alinearse con ejemplo.es.

Un registro típico no tiene, por tanto, nada de exótico:

v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.es

Los modos relaxed se aplican implícitamente. Y un punto capital, que a menudo se pasa por alto: DMARC no exige que los dos mecanismos se alineen. Basta con uno. Un SPF no alineado acompañado de un DKIM alineado da dmarc=pass —y esa es, como se verá, la clave de la mayoría de las correcciones—.

Tres casos típicos detrás del síntoma

Un spf=pass no alineado casi nunca aparece por azar. Tres configuraciones concentran lo esencial de lo que muestran los informes agregados.

Caso 1: la plataforma de envío que pasa SPF con su propio dominio. El gran clásico. Una plataforma de emailing —Mailchimp, Brevo, SendGrid, Mailjet— expide la newsletter de ejemplo.es con, por defecto, un sobre puesto en su propio dominio: MAIL FROM bounces.router-envios.net. La plataforma domina su SPF, la IP está autorizada, spf=pass —para router-envios.net—. El From: muestra ejemplo.es: ninguna alineación es posible, los dos dominios son ajenos entre sí. Si, además, la firma DKIM por defecto lleva d=router-envios.net, el fallo es total: todo está autenticado, pero nada lo está en nombre del dominio correcto.

Caso 2: el reenvío que reescribe el sobre. Un mensaje perfectamente alineado en origen se envía a una dirección que reenvía —el alias de un antiguo empleado, un buzón universitario redirigido a una cuenta personal—. El servidor que retransmite acaba emitiendo desde una IP ausente del SPF del remitente original; para evitar un rechazo, muchos reescriben el sobre a su propio nombre (el mecanismo SRS). Resultado: spf=pass, pero para el dominio del reenviador —de nuevo sin alineación—. La mecánica completa está detallada en por qué el reenvío rompe SPF. El matiz que salva: la firma DKIM viaja con el mensaje y sobrevive mientras el contenido no se modifique —de ahí la importancia del «basta con uno»—.

Caso 3: el subdominio mal alineado. La organización envía con MAIL FROM en newsletter.ejemplo.es y From: en ejemplo.es. En modo relaxed, todo va bien: mismo dominio organizativo. Pero si el registro impone aspf=s, el pass se vuelve no alineado de la noche a la mañana. Variante más traicionera: un dominio técnico separado, ejemplo-mailing.es, elegido hace años «para aislar los envíos». Ese no se alineará jamás con ejemplo.es, ni siquiera en relaxed: son dos dominios organizativos distintos.

Detectar el pass no alineado en un informe agregado

No hace falta rehacer aquí la teoría de los informes: la lectura de los informes agregados DMARC la cubre campo a campo. Para este síntoma concreto basta un reflejo: comparar el dominio del header_from con el dominio asociado al resultado SPF. Si el resultado es pass pero los dos dominios difieren —y no comparten dominio organizativo—, la línea describe un pass no alineado, contado como fallo del lado DMARC.

La lectura rinde cuando se hace por fuente. Una IP de plataforma que solo muestra passes no alineados señala una configuración por defecto nunca personalizada (caso 1). Líneas dispersas, de poco volumen, con dominios SPF de proveedores de acceso o universidades delatan reenvíos (caso 2). Y un vuelco repentino de todo un flujo, de alineado a no alineado, acompaña a menudo un cambio de la etiqueta aspf o una migración de plataforma (caso 3). El síntoma es idéntico en los tres casos; el remedio depende del diagnóstico.

Las correcciones: dominio de retorno propio y DKIM alineado

El dominio de retorno personalizado. Para el caso de la plataforma, la corrección tiene nombre en todos los proveedores serios: custom return-path, bounce domain, dominio de sobre. El principio: crear un subdominio dedicado —bounce.ejemplo.es— apuntado por CNAME a la infraestructura de la plataforma. El sobre de los envíos pasa a ser MAIL FROM bounce.ejemplo.es: el SPF de la plataforma sigue validando la IP, pero el pass beneficia ahora a un subdominio de ejemplo.es, alineado en modo relaxed. Unos pocos registros DNS, ningún cambio en el contenido de los mensajes.

La firma DKIM alineada. La corrección más robusta está en otra parte: hacer que los mensajes se firmen con d=ejemplo.es, mediante las claves o los CNAME que la plataforma proporciona al configurar el dominio. Un DKIM alineado hace el veredicto DMARC independiente de la suerte del sobre: sobrevive a los reenvíos, no depende de ninguna reescritura SRS y basta por sí solo para producir dmarc=pass. Por eso la doctrina cabe en una línea: DKIM alineado primero, SPF alineado como cinturón de seguridad —y ambos cuando la plataforma lo permite, que hoy es la norma—.

Queda el caso especial del modo strict: antes de imponer aspf=s o adkim=s, el inventario de los subdominios de envío resulta indispensable; de lo contrario, el endurecimiento del modo fabrica por sí mismo passes no alineados. El modo relaxed, valor por defecto, cubre la gran mayoría de las necesidades reales.

Qué cambia la alineación para p=reject

Mientras la política sigue en p=none, un pass no alineado no cuesta nada: los mensajes llegan, los informes se acumulan, el síntoma queda en lo académico. En p=reject, esa misma línea se convierte en correo rechazado. Cada fuente legítima aún no alineada en el momento del endurecimiento se transforma en un incidente de entregabilidad: facturas que dejan de llegar, notificaciones de RR. HH. rechazadas en silencio.

El criterio de paso es, por tanto, sencillo de enunciar: cada fuente legítima debe producir al menos un pass alineado, preferiblemente vía DKIM, antes de endurecer la política. Los reenvíos ordinarios superan ese filtro gracias a DKIM; el caso rebelde siguen siendo las listas de distribución, que modifican el contenido —rompiendo DKIM— a la vez que reescriben el sobre —desalineando SPF—. Para la transición en sí, DMARCbis proporciona un modo de prueba explícito (t=y), sucesor de la antigua etiqueta pct desaparecida del estándar, que permite anunciar una política estricta señalando a la vez a los receptores una fase de ensayo.

En resumen

spf=pass y dmarc=fail en la misma línea no son ni un bug ni una contradicción: SPF validó el dominio del sobre y DMARC constata que ese dominio no corresponde al From: mostrado. El pass existe, pero beneficia al dominio equivocado. Tres configuraciones producen lo esencial del síntoma —la plataforma que sigue con su sobre por defecto, el reenvío que reescribe el MAIL FROM, el subdominio o dominio primo mal alineado— y dos correcciones acaban con él: el dominio de retorno personalizado, que realinea SPF, y la firma DKIM con el d= del propio dominio, que mantiene el veredicto robusto incluso a través de los reenvíos. Un solo mecanismo alineado le basta a DMARC; tener los dos es el margen de seguridad que convierte p=reject en un paso sereno.

El diagnóstico no exige abrir un solo archivo XML: un análisis DMARC gratuito del dominio pone de relieve, fuente a fuente, los passes que no benefician al dominio correcto y el estado real de la alineación. Crear una cuenta permite después seguir, informe tras informe, cómo cada fuente entra en alineación, hasta el día en que el paso a p=reject ya no es un salto al vacío, sino una formalidad.