Alignment de autenticación y revisión de políticas para senders multi-dominio — el detalle que rompe DMARC y la mayoría no entiende

El patrón de soporte que vemos repetidamente: el equipo configura SPF, DKIM y DMARC siguiendo guías estándar. Las pruebas con herramientas básicas (mail-tester) reportan SPF pass, DKIM pass. Pero los reportes DMARC empiezan a llegar diciendo "fail". Confusión: si los componentes individuales pasan, ¿por qué falla el agregado? La respuesta es alignment — el detalle técnico que casi ninguna guía explica claramente y que es la causa #1 de fallos DMARC en setups multi-dominio. Este post lo explica con propósito operativo.

Qué es alignment exactamente

DMARC requiere que SPF o DKIM (o ambos) pasen y que el dominio que pasó esté alineado con el dominio del From visible. La autenticación sola no basta — debe ser autenticación del dominio correcto.

Hay dos tipos de alignment, uno por cada mecanismo:

SPF alignment: el dominio del MAIL FROM (envelope sender, también llamado Return-Path) debe coincidir con el dominio del From visible. Si el From dice "noreply@su-empresa.com" pero el MAIL FROM es "bounce@bounces.proveedor.com", SPF puede pasar (proveedor.com tiene registro SPF válido para sus IPs) pero DMARC falla alignment SPF.

DKIM alignment: el dominio en el campo d= de la firma DKIM debe coincidir con el dominio del From visible. Si el From dice "noreply@su-empresa.com" pero la firma DKIM tiene d=proveedor.com, DKIM puede pasar (firma válida con clave de proveedor.com) pero DMARC falla alignment DKIM.

Para que DMARC pase, al menos uno de los dos alignments debe estar correcto. Si ambos fallan alignment, DMARC falla independientemente de que SPF y DKIM individualmente reporten pass.

Modos strict vs relaxed

Cada alignment tiene dos modos definidos en RFC 7489:

Strict (s): el dominio debe coincidir exactamente. From "noreply@su-empresa.com" requiere DKIM con d=su-empresa.com exacto, no subdominio.

Relaxed (r): el dominio puede ser el mismo o un subdominio del mismo dominio organizacional. From "noreply@su-empresa.com" acepta DKIM con d=mail.su-empresa.com o d=marketing.su-empresa.com.

Configuración en el registro DMARC: aspf=s (SPF strict), aspf=r (SPF relaxed, default), adkim=s (DKIM strict), adkim=r (DKIM relaxed, default).

Para la mayoría de operaciones, relaxed es la elección sana — permite usar subdominios para distintos propósitos sin romper alignment. Solo casos con requisitos de seguridad muy específicos (banca, sector público regulado) usan strict obligatoriamente.

Causas frecuentes de alignment failure

Cuatro causas que cubren la mayoría de casos:

Causa 1 — SPF pasa con dominio del proveedor pero DKIM no está configurado. El proveedor envía con su MAIL FROM (bounce@bounces.proveedor.com), su SPF pasa, pero no firma DKIM con dominio del cliente. DMARC falla por: SPF no aligned (dominio proveedor ≠ dominio From), DKIM no aligned o no presente. Resultado: DMARC fail.

Solución: configurar custom DKIM en el proveedor para firmar con d=su-empresa.com (subdominio del cliente), no d=proveedor.com.

Causa 2 — Custom DKIM configurado pero MAIL FROM no es subdominio del cliente. El proveedor firma DKIM con d=su-empresa.com correctamente, pero MAIL FROM sigue siendo bounce@bounces.proveedor.com. DKIM aligned pasa, alignment relaxed acepta el caso. Pero algunos receptores estrictos no lo aceptan, y DMARC en modo strict falla.

Solución más completa: configurar custom Return-Path en el proveedor para usar bounces.su-empresa.com (subdominio del cliente). Esto requiere registros DNS específicos: CNAME apuntando a infraestructura del proveedor que procesa los bounces.

Causa 3 — Múltiples proveedores, configuración inconsistente. La empresa usa varios proveedores (transactional via SendGrid, marketing via Mailgun, alerts internos via SMTP propio). Si un proveedor está bien configurado para alignment pero otro no, los emails desde ese proveedor fallan DMARC mientras los otros pasan. Reportes DMARC muestran este patrón claramente — passes desde unas IPs, fails desde otras.

Solución: revisar configuración alignment para cada proveedor independientemente. Custom DKIM en cada uno, custom Return-Path en cada uno donde sea posible.

Causa 4 — DKIM key rotation rota alignment temporalmente. Al rotar clave DKIM, si el selector nuevo no se publica antes de que el proveedor empiece a firmar con él, hay ventana donde la firma falla. Si la firma falla, DKIM no aligned, y DMARC depende solo de SPF alignment.

Solución: rotation con overlap. Publicar nuevo selector en DNS, esperar 24-48h para propagación, después configurar proveedor para usar nuevo selector. Mantener selector antiguo activo en DNS durante 2-3 semanas adicionales por bounces atrasados.

Diagnóstico via reportes DMARC

Los reportes DMARC RUA (Reporting URI for Aggregate reports) son la herramienta principal de diagnóstico. Reciben XML diario o cada pocos días con estadísticas agregadas: cuántos mensajes desde qué IPs pasaron/fallaron SPF y DKIM, con qué alignment.

Estructura típica del XML:

<record>
  <row>
    <source_ip>198.51.100.10</source_ip>
    <count>523</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>su-empresa.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>proveedor.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.proveedor.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Lectura: 523 mensajes desde IP 198.51.100.10 con From su-empresa.com. SPF pasó autenticación (con dominio bounces.proveedor.com) y DKIM pasó (con dominio proveedor.com). Pero DMARC policy_evaluated dice dkim: fail — porque el dominio DKIM (proveedor.com) no alinea con header_from (su-empresa.com). Resultado: DMARC fail por alignment.

Procesamiento manual de XML es inviable a escala. Herramientas como dmarcian, EasyDMARC, Postmark DMARC Monitoring o Valimail parsean los reportes y entregan dashboards entendibles. Para empezar, dmarcian tiene tier gratuito útil para diagnosticar.

Pattern típico para multi-dominio sender

Para empresa con varias marcas o subdominios enviando desde varios proveedores, el setup correcto:

Cada dominio principal con su DMARC propio. su-empresa.com, su-marca-secundaria.com, su-otro-dominio.com cada uno con registro DMARC en _dmarc.{dominio}.

Política DMARC alineada por estrategia. Dominio principal con p=reject (máxima protección). Dominios secundarios pueden estar en quarantine o reject según madurez.

Custom DKIM por dominio en cada proveedor. Si su-empresa.com envía desde SendGrid, configurar custom DKIM con d=su-empresa.com. Si su-marca-secundaria.com envía desde Mailgun, custom DKIM con d=su-marca-secundaria.com. Cada combinación dominio+proveedor con su configuración.

Custom Return-Path por dominio donde sea posible. bounces.su-empresa.com vía CNAME a infraestructura del proveedor.

Subdominios para usos específicos. mail.su-empresa.com para transactional, marketing.su-empresa.com para campaigns. Cada subdominio con su DKIM y configuración alineada. DMARC con adkim=r relaxed permite que subdominios pasen alignment con el dominio principal.

El cálculo de prioridad — qué arreglar primero

Para empresa con problemas de alignment generalizados, no se arregla todo simultáneamente. Prioridad típica:

1. Identificar fuentes de mayor volumen problemático. Reportes DMARC ordenados por count desc — qué IPs envían más mensajes que fallan alignment. Atender esas primero.

2. Custom DKIM en proveedores principales. Configurar firma con dominio del cliente en SendGrid/Mailgun/Postmark/Amazon SES — el cambio que mayor impacto tiene.

3. Custom Return-Path donde el proveedor lo soporta. Mejora alignment SPF, segunda línea de defensa.

4. Política DMARC progresiva. Solo después de que alignment está estable, mover de p=none a p=quarantine, después a p=reject. Saltar pasos garantiza que mensajes legítimos se rechacen.

5. Monitoreo continuo. Reportes DMARC procesados continuamente. Cualquier nueva fuente de fallo (proveedor nuevo agregado sin alignment, cambio de configuración rota algo) detectada inmediatamente.

Alignment correcto es invisible operativamente — los emails llegan, los reportes muestran pass, la marca está protegida. Alignment incorrecto es ruido constante: emails legítimos rechazados, brand exposure a phishing, conversaciones recurrentes de "por qué este email no llegó". La diferencia es entender el detalle técnico y aplicarlo sistemáticamente en cada proveedor.