DMARC falla pero SPF y DKIM pasan: cómo encontrar la causa

Abres un informe DMARC o la cabecera de un mensaje y ves spf=pass y dkim=pass junto a dmarc=fail. Nada está roto como parece: ambas comprobaciones pasaron, pero no para el dominio que le importa a DMARC. Esta guía es un camino de resolución de problemas para esa situación exacta. Parte de que ya sabes qué es la alineación y quieres encontrar cuál de las causas habituales tienes, en el orden en que son más probables.

La respuesta corta#

DMARC pasa cuando SPF o DKIM pasa y se alinea con el dominio de la dirección From visible. "Pasar" y "estar alineado" son preguntas distintas. SPF se compara con el dominio del Return-Path (el remitente del sobre), y DKIM se compara con el dominio d= de la firma. Si tu servicio de correo firma con su propio dominio y rebota a través de su propio dominio, ambas comprobaciones pasan y ninguna se alinea. La solución es casi siempre la misma: configurar un dominio de firma DKIM personalizado en tu propio dominio, y un dominio de return-path personalizado si quieres que SPF también se alinee. Revisa las etiquetas del modo estricto, el reenvío y los subdominios solo después de eso. Para el concepto en sí, consulta la explicación de SPF, DKIM y DMARC.

Con qué se compara cada comprobación#

Cada mensaje lleva tres dominios que importan, y DMARC los empareja de dos en dos. La mayor parte de la confusión desaparece cuando puedes nombrar cuál usa cada comprobación.

Así se ve el fallo clásico en un mensaje recibido. El From es tuyo, ambas comprobaciones pasan, y los otros dos dominios pertenecen al remitente:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=bounce.mail.vendor.example;
  dkim=pass header.d=mail.vendor.example;
  dmarc=fail header.from=yourdomain.com

El analizador de cabeceras de correo muestra los veredictos de SPF, DKIM y DMARC y los campos From y Return-Path. Lee tú mismo el valor d= de DKIM en la línea DKIM-Signature. Si solo tienes un informe agregado, la misma información está en auth_results (resultados y dominios en bruto) frente a policy_evaluated (el veredicto alineado). La guía para leer informes explica esa separación.

El camino de decisión#

Recorre esta lista hacia abajo y detente en el primer paso que coincida. Cada paso es una causa raíz distinta con una solución distinta.

1. DKIM pasa, pero d= es el dominio del remitente. Es la causa más común y la mejor solución. Activa la firma DKIM personalizada (a veces llamada dominio de marca o dominio autenticado) en el servicio de envío para que firme con d=tudominio.com o un subdominio suyo. DKIM viaja con el mensaje, así que sigue alineándose tras el reenvío.
2. SPF pasa, pero el Return-Path es el dominio del remitente. SPF solo puede alinearse si el remitente del sobre es tu dominio. Configura un dominio de return-path (de rebotes) personalizado en el servicio, normalmente un subdominio como bounce.tudominio.com apuntado al proveedor mediante CNAME o mediante los registros MX y TXT que te den. Añadir al proveedor a tu propio registro SPF no lo soluciona: SPF se comprueba contra el dominio del Return-Path, que es el del proveedor, así que tu registro nunca se consulta para ese mensaje.
3. Ambos son personalizados pero DMARC sigue fallando. Mira adkim y aspf en tu registro DMARC. Si alguno es s (estricto), la coincidencia debe ser exacta, así que una firma de mail.tudominio.com no se alinea con un From tudominio.com. O firmas con el dominio From exacto o quitas la etiqueta estricta.
4. Falla solo en algunas fuentes o solo en algunos receptores. Sospecha de reenvío, de una lista de correo o de una pasarela de seguridad que reescribe el correo. Consulta la sección sobre reenvío más abajo.
5. Falla solo en un subdominio. Comprueba si el subdominio tiene su propio SPF y DKIM, y qué registro DMARC se le aplica. Consulta la sección de subdominios.
6. No pasa nada en absoluto. Eso no es alineación. Falta SPF o DKIM, o está roto, para esa fuente, y es un problema distinto y más simple.

Relajado frente a estricto, en la práctica#

El valor por defecto es relajado en ambos. Con alineación relajada los dos dominios solo necesitan compartir un Organizational Domain, así que un Return-Path de bounce.tudominio.com se alinea con un From de news.tudominio.com. Con alineación estricta deben ser idénticos.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Deja ambos en r salvo que tengas una razón por escrito. El modo estricto rara vez detiene un ataque real que el modo relajado permitiría, y es una causa frecuente de que falle correo legítimo de subdominios. Un detalle cambió en el estándar actual: el RFC 9989 (mayo de 2026) deja obsoleto el RFC 7489 y define el Organizational Domain mediante un recorrido del árbol DNS en lugar de una lista de sufijos públicos. Si usas dominios poco habituales con muchas etiquetas, comprueba cómo lo aplican tus receptores.

Por qué el reenvío rompe una comprobación pero no la otra#

Cuando un mensaje se reenvía, el servidor que reenvía lo envía desde su propia IP. SPF se evalúa contra la IP que se conecta, así que SPF falla o deja de alinearse. Por eso una fuente puede mostrar un DMARC sano en un receptor y fallos en otro: los fallos son las copias reenviadas.

DKIM normalmente sobrevive al reenvío, porque la firma viaja dentro del mensaje. Se rompe cuando el reenviador o una lista de correo cambia lo que se firmó, por ejemplo añadiendo un pie de página o editando el asunto. Por eso el consejo es siempre el mismo: alinea DKIM para cada fuente, de modo que DMARC pueda pasar incluso cuando SPF no puede.

No puedes arreglar el reenvío del todo desde tu lado. Es normal que queden pequeños fallos que se remontan a reenviadores y listas, una razón más para juzgar el progreso por tendencia y por fuente y no por un mal día.

Desajustes en subdominios#

Un subdominio no hereda el registro SPF de su dominio padre, y las claves DKIM se buscan bajo cada selector y dominio, así que un subdominio que envía correo necesita su propia autenticación. La política DMARC es distinta: si el subdominio no publica un registro DMARC propio, los receptores encuentran el del dominio padre, y la etiqueta sp= del padre (si existe) fija la política del subdominio.

Dos comprobaciones resuelven la mayoría de los problemas de subdominios. Primero, confirma que el servicio de envío firma con un dominio que coincide con el subdominio From, o con el padre en modo relajado. Segundo, si has puesto sp=reject en el padre, confirma que cada subdominio emisor está pasando antes de confiar en ello. La guía del subdominio de envío explica cómo estructurarlo para que cada flujo de correo quede aislado.

Encontrar rápido la fuente que falla#

La parte cara de un fallo de alineación no es la solución, sino encontrar qué fuente la necesita. Tus informes agrupan el correo por IP de envío, así que una fuente que firma con su propio dominio aparece como una fila con un porcentaje DMARC bajo.

Los informes DMARC de Qualisend muestran cada fuente con porcentajes separados de DMARC, DKIM y SPF, y marcan las filas por debajo del 100 %. Una fuente que firma y rebota por los dominios del proveedor muestra porcentajes bajos de DMARC, DKIM y SPF a la vez, que es el patrón del paso 1 o 2 de arriba. La página no muestra el dominio d= ni el Return-Path de cada fila, así que aún tienes que tomar un mensaje de esa fuente y leer sus cabeceras para ver cuál de los dos dominios es el incorrecto. Además, solo informa de lo que devuelven los receptores, así que un receptor que no envía informes agregados es invisible en ella.

Para una primera mirada sin cuenta, el analizador de informes DMARC gratuito lee un archivo de informe en tu navegador. Para probar un remitente de extremo a extremo, envía un mensaje al test de entregabilidad de correo gratuito y lee sus resultados de autenticación.

Una lista de comprobación por servicio#

Cada servicio de envío usa sus propias palabras para los ajustes, pero el trabajo son los mismos cuatro elementos. Comprueba cada uno en la documentación del propio servicio en lugar de fiarte de una chuleta, porque los menús y los valores por defecto cambian.

• Dominio DKIM personalizado. Busca "autenticar tu dominio", "dominio de envío de marca" o "DKIM". Publica las claves que te da. Un nombre de selector nuevo no entra en conflicto con los que ya tienes.
• Dominio de return-path personalizado. Busca "dominio de rebotes personalizado", "return-path" o "marca de enlaces". A menudo es un ajuste separado de DKIM.
• Dirección From. Confirma que el From usa tu dominio. Un From en un dominio de correo gratuito, enviado a través de un tercero, no puede alinearse con nada tuyo.
• Un cambio a la vez. Haz el cambio, envía una prueba, lee la cabecera y luego revisa el siguiente informe. Varios cambios a la vez hacen imposible ver cuál funcionó.

Cuándo parar y cuándo preocuparse#

Estás listo para pensar en la aplicación de la política cuando cada fuente legítima pasa DMARC mediante al menos una comprobación alineada, y los fallos que quedan pertenecen a reenviadores o a correo que no reconoces. Si aún estás averiguando cómo llegar ahí, la guía de configuración de DMARC tiene el orden de despliegue, y la guía de requisitos para remitentes explica por qué un DMARC alineado importa ahora para el correo masivo.

La alineación le dice a los receptores que el correo es realmente tuyo, pero no dice nada de la lista que hay detrás. Cuando todas tus fuentes estén pasando, comprueba unas cuantas direcciones con el verificador de correo gratuito, que revisa sintaxis, registros MX y errores tipográficos de una dirección cada vez. Para una lista entera, el plan gratuito de la página de precios te da 100 créditos que ejecutan la verificación completa, porque un dominio perfectamente alineado sigue necesitando una lista sana para llegar a la bandeja de entrada.