GuíasAutenticación

DMARC falla aunque SPF y DKIM pasan

Las dos comprobaciones dicen «pass» y DMARC sigue diciendo «fail». La causa es un dominio que no coincide con el de tu dirección From. Un email de prueba muestra cuál, y la solución es un ajuste en quien envía el correo.

Actualizado el 5 de octubre de 20269 min de lectura

En resumen

DMARC solo pasa si SPF o DKIM pasan para el dominio de tu dirección From. Un «pass» para el dominio de tu proveedor no cuenta.
Abre en Gmail un mensaje enviado con Show original y compara smtp.mailfrom, header.i y header.from en la cabecera Authentication-Results.
Arregla primero DKIM: activa la firma con tu propio dominio en todos los servicios que envían en tu nombre. Una firma DKIM sobrevive al reenvío; SPF, no.
Por defecto, un subdominio se parece lo suficiente. Si tu registro DMARC contiene adkim=s o aspf=s, no.
El calentamiento no arregla la alineación. Los emails de calentamiento se envían a través de tu buzón y fallan con él.

DMARC no pregunta si SPF y DKIM han pasado. Pregunta si uno de los dos ha pasado para el dominio de tu dirección From. Si SPF pasó para el dominio de rebote de tu proveedor y DKIM pasó para el dominio de firma de tu proveedor, las dos líneas dicen «pass» y DMARC sigue diciendo «fail». La solución está en quien envía: haz que firme con tu dominio o usa una dirección de rebote en tu dominio. Con una de las dos cosas basta.

Esa coincidencia se llama alineación (alignment). Es la parte de DMARC que un comprobador de DNS no puede ver. Si tu correo está alineado solo se ve en un mensaje enviado de verdad. Esta página enseña a leer uno.

Tres dominios viajan con cada email

Un email lleva tu dominio en hasta tres sitios. Cada comprobación mira uno distinto.

Un banderín azul marino con el emblema de un sobre, una saca de correo con una etiqueta de latón y una carta con un sello de lacre, uno al lado del otro en un muelle; el sello repite el emblema del banderín, la etiqueta no — El banderín es la línea From, la etiqueta de la saca es el Return-Path y el sello de lacre es la firma DKIM. DMARC quiere que la etiqueta o el sello coincidan con el banderín.

Dónde	También se llama	Quién lo mira
La línea From que ve tu lector	Header From, `header.from`	DMARC. Es la vara de medir de los otros dos.
El Return-Path	Remitente del sobre (envelope sender), MAIL FROM, dirección de rebote (bounce address), `smtp.mailfrom`	SPF. Comprueba si el servidor que envía puede usar este dominio.
El valor `d=` de la cabecera DKIM-Signature	Dominio de firma (signing domain), `header.d` o `header.i`	DKIM. Comprueba si la firma de este dominio es válida.

SPF (RFC 7208) y DKIM (RFC 6376) responden cada uno a una pregunta acotada, y ninguna de las dos menciona tu línea From. Un servicio de newsletters puede pasar SPF para su propio dominio de rebote y firmar con su propia clave, y el mensaje puede seguir afirmando que viene de ti. DMARC cierra ese hueco. El RFC 9989, el estándar de DMARC desde mayo de 2026, solo acepta un resultado si el dominio que hay detrás coincide con el dominio From, y explica el motivo en el caso de DKIM con una frase:

DMARC exige que la alineación de identificadores se aplique al identificador autenticado por DKIM porque un mensaje puede llevar una firma válida de cualquier dominio, incluso de uno usado por un actor malintencionado.

Lo mismo vale para SPF, ya que cualquiera puede publicar un registro SPF para un dominio que le pertenece. Así que la regla es: DMARC pasa si SPF pasa y su dominio está alineado, o si DKIM pasa y su dominio está alineado.

Encuentra la discrepancia en un mensaje real

Necesitas un email enviado igual que se envía tu correo real y una dirección de Gmail para recibirlo.

Envía un mensaje desde el buzón o la herramienta en cuestión a una dirección de Gmail que puedas abrir.
Ábrelo en Gmail en un ordenador. Junto a Reply (Responder), haz clic en More (Más) y después en Show original (Mostrar original). Google describe los mismos pasos en Rastrear un email con su cabecera completa.
Busca la cabecera Authentication-Results, en la que el servidor receptor anota el resultado de sus comprobaciones (RFC 8601). Compara tres valores: el dominio que sigue a smtp.mailfrom=, el dominio que sigue a header.i=@ (algunos receptores escriben header.d=) y el dominio que sigue a header.from=. Cómo leer las cabeceras de un email recorre esa línea paso a paso.

Este es el patrón de un mensaje que pasa SPF y DKIM y falla DMARC. La cabecera está abreviada y usa dominios de ejemplo:

From: anna@example.com
Return-Path: <bounces@send.vendor-mail.example>

Authentication-Results: mx.google.com;
       dkim=pass header.i=@vendor-mail.example header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=fail header.from=example.com

Léela desde abajo. El dominio From es example.com. SPF pasó, pero para send.vendor-mail.example. DKIM pasó, pero la firma pertenece a vendor-mail.example. Ninguno es example.com, así que nada responde por el nombre de la línea From.

Una vez configurado el servicio para firmar con tu dominio, el mismo mensaje se ve así:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@send.vendor-mail.example;
       dmarc=pass header.from=example.com

SPF sigue apuntando al servicio externo. No pasa nada. DKIM ahora coincide, y un «pass» alineado es todo lo que DMARC necesita.

Cuánto parecido basta: alineación relajada y estricta

Los dos dominios no tienen que ser idénticos. Por defecto la alineación es relajada (relaxed): basta con que ambos pertenezcan al mismo dominio registrado, que el estándar llama dominio organizativo. La alineación estricta (strict) exige una coincidencia exacta. Lo eliges con las etiquetas adkim para DKIM y aspf para SPF en tu registro DMARC.

SPF o DKIM pasó para	Dominio From	Relajada (por defecto)	Estricta
`example.com`	`example.com`	Alineado	Alineado
`mail.example.com`	`example.com`	Alineado	No alineado
`example.com`	`news.example.com`	Alineado	No alineado
`vendor-mail.example`	`example.com`	No alineado	No alineado

El estándar señala que «a casi todos los propietarios de dominios la alineación relajada les ha bastado para cubrir sus necesidades». Revisa tu propio registro de todos modos. El registro de ejemplo que encabeza la página Configurar DMARC de Google termina en adkim=s; aspf=s, así que un registro copiado de ahí es estricto. Si el tuyo tiene esas dos etiquetas y una herramienta envía desde un subdominio, quítalas. La propia Google advierte en esa página de que la alineación estricta «puede hacer que los mensajes de subdominios asociados se rechacen o se envíen a spam».

De dónde suele venir la discrepancia

Un servicio que envía desde sus propios servidores

Las plataformas de newsletters, los CRM, las herramientas de facturación y los servicios de atención al cliente envían tu correo desde su infraestructura. Hasta que conectas tu dominio, lo habitual es que usen una dirección de rebote en su dominio y firmen con su propia clave. La documentación de Amazon dice sin rodeos por qué aquí la alineación de SPF es poco frecuente: el Return-Path «se usa para los rebotes y las quejas que el proveedor (SES) rastrea con una dirección de su propiedad» (Amazon SES). El ajuste que lo arregla tiene un nombre distinto en cada servicio y termina en unos pocos registros DNS por tu parte.

Servicio	Antes de conectar tu dominio	El ajuste que hay que buscar
Twilio SendGrid	El correo aparece como enviado «via sendgrid.net».	Domain authentication (autenticación del dominio): registros CNAME para un subdominio de rebote y dos claves DKIM.
Amazon SES	El Return-Path es un subdominio de `amazonses.com`.	Easy DKIM para la firma y un custom MAIL FROM domain (dominio MAIL FROM personalizado) para SPF.
Mailchimp	El dominio está verificado, pero no autenticado.	Email domain authentication (autenticación del dominio de email): dos registros CNAME para DKIM.

Son las descripciones de los propios servicios a octubre de 2026. Otros servicios funcionan de forma parecida. Busca en su ayuda «authenticate domain», «custom DKIM» o «branded sending domain».

Tu proveedor de correo firma con su propio dominio, o no firma

Con un buzón en tu propio dominio, el Return-Path suele ser tu propia dirección, así que SPF queda alineado en cuanto tu registro SPF incluye al proveedor. El valor que sigue a smtp.mailfrom= te lo dice. DKIM es la parte que hay que activar.

Google Workspace. Hasta que activas DKIM para tu dominio, Google ha firmado con uno de sus propios dominios. Una versión anterior de la página de ayuda de Google decía que Gmail firma entonces «con esta clave de dominio DKIM predeterminada: d=*.gappssmtp.com». La página actual ya no nombra el dominio, así que revisa tu propia cabecera: un header.i que termina en gappssmtp.com significa que tu clave no está activa. Genérala en la consola de administración, en Apps, Google Workspace, Gmail, Authenticate email (autenticar el correo), añade el registro TXT que te muestra y haz clic en Start authentication (iniciar la autenticación) (Configurar DKIM).
Microsoft 365. La documentación de Microsoft, actualizada en agosto de 2026, afirma: «Actualmente no se aplica ninguna firma DKIM al correo saliente de dominios personalizados». Publicas dos registros CNAME y activas la firma en el portal de Defender (Cómo usar DKIM para el correo de tu dominio personalizado).

El registro que añades para una clave DKIM siempre queda bajo _domainkey, con un nombre que elige el proveedor. En Google Workspace tiene este aspecto, con la clave abreviada:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Una herramienta que se conecta a tu buzón y envía a través de él no añade ninguna firma propia. El correo de una herramienta así es idéntico al que escribes a mano, de modo que la solución está en el proveedor del buzón y no en la herramienta.

El mensaje se reenvió

Cuando un destinatario reenvía tu correo automáticamente, llega desde un servidor que tu registro SPF no incluye. SPF falla, o pasa para el dominio de quien reenvía. Una firma DKIM sobrevive al viaje mientras nadie modifique el mensaje. Las listas de correo que añaden un pie o una etiqueta en el asunto también rompen la firma. Esto no lo puedes arreglar por tu lado. Las preguntas frecuentes para remitentes de Google dicen que en Gmail «la alineación de DMARC no es obligatoria para los mensajes reenviados ni para los de listas de correo». Es el motivo para tener DKIM alineado y no depender solo de SPF.

Una carta sellada pasa de un barco postal a otro; cada barco tiene su propia saca de correo con su etiqueta, y el sello de lacre de la carta está intacto — El reenvío cambia la saca y su etiqueta. El sello de la carta sigue intacto.

No es tu correo

Si tus informes DMARC muestran fallos desde servidores que nunca has usado, puede que alguien esté enviando con tu dirección. Esos mensajes tienen que fallar. No hay nada que arreglar, y son el argumento para una política más estricta más adelante.

Arregla primero DKIM y después SPF

Cualquiera de los dos te da un «pass». DKIM es el que más conviene tener, porque viaja con el mensaje. Las buenas prácticas de M3AAWG lo formulan como regla: «Firma todo el correo saliente con una clave DKIM alineada con el dominio de la cabecera RFC5322.From». El RFC 9989 recomienda usar ambos.

Haz una lista de todo lo que envía con tu dominio. Buzones, la herramienta de newsletters, el CRM, las facturas, el formulario de contacto de tu web. Tus informes DMARC nombran los que se te olvidaron.
Prueba cada uno con la comprobación de cabecera de arriba y anota cuál de los dos dominios no es tuyo.
Activa la firma con tu dominio allí donde header.i muestre otro nombre y publica los registros que te dé el servicio. Elige una clave de 2048 bits si tu proveedor de DNS la admite. Gmail exige al menos 1024 bits y recomienda 2048.
Configura un dominio de rebote personalizado donde el servicio lo ofrezca, en un subdominio como bounce.example.com. Eso alinea también SPF.
Envía de nuevo la prueba y busca dmarc=pass. Los cambios de DNS pueden tardar un rato. Google da hasta 48 horas para que una clave DKIM nueva empiece a funcionar.

Lo que no funciona es añadir el servicio a tus propios registros. Un include: del servicio en tu registro SPF no cambia nada si el Return-Path está en el dominio del servicio, porque SPF consulta el registro de ese dominio y no el tuyo. Un registro DMARC tampoco puede enumerar terceros de confianza. El estándar dice que para eso no hay «ningún mecanismo generalmente aceptado».

Si la cabecera muestra dmarc=pass y el mensaje sigue llegando a spam, la autenticación ya no es la causa. SPF, DKIM y DMARC pasan, pero el email sigue llegando a spam continúa desde ahí.

Lo que cuesta un DMARC que falla mientras tu política es p=none

Con p=none pides a los receptores que no hagan nada ante un fallo, así que nada se rechaza por tu política. Aun así cuenta en tu contra de dos maneras.

Normas para remitentes masivos. Gmail, Yahoo y Outlook.com exigen correo alineado a los remitentes masivos, lo que para Gmail y Outlook.com significa a partir de 5000 mensajes al día. Las preguntas frecuentes para remitentes de Google recogen el error temporal 4.7.32 para el correo cuya cabecera From «no está alineada ni con el dominio organizativo autenticado de SPF ni con el de DKIM», y nombran como consecuencia «códigos de fallo temporal o permanente, o el envío a la carpeta de spam».
Bloquea el paso siguiente. En cuanto pasas a p=quarantine o p=reject, cada mensaje tuyo sin alinear debe tratarse como spam o rechazarse. En Gmail el rebote dice «Unauthenticated email from domain-name is not accepted due to domain's DMARC policy», error 5.7.26 (Solucionar problemas de DMARC).

Si no tienes ningún registro DMARC, empieza por el registro que hay que añadir. Además activa los informes que muestran la alineación de todos tus remitentes a la vez.

Lo que el calentamiento puede hacer aquí y lo que no

Un calentamiento no arregla la alineación. WarmupBay se conecta a tu buzón y envía desde él, así que sus emails de calentamiento los envía y los firma tu proveedor exactamente igual que el correo que escribes tú. Si tu buzón falla DMARC, fallan con él. Arregla primero los registros.

WarmupBay ayuda con lo de antes y con lo de después. Cuando conectas un buzón, comprueba SPF, DKIM y DMARC del dominio, y detiene el calentamiento si pasadas 72 horas siguen faltando. Cuando están en su sitio, tu buzón intercambia unos pocos emails al día con otros de una red compartida, y el panel muestra dónde llegaron: bandeja de entrada, una pestaña de Gmail o spam, por separado para Google y para otros proveedores. No prueba el correo de tu herramienta de newsletters ni de tu CRM, porque ese nunca pasa por tu buzón, y aún no puede conectar buzones de Microsoft 365 ni de Outlook.com. Es gratis para 10 emails de calentamiento al día. Conecta tu buzón cuando la cabecera muestre dmarc=pass.

Preguntas frecuentes

SPF pasa y está alineado, DKIM no está alineado. ¿Basta con eso?

Para DMARC, sí. Basta con un «pass» alineado. Deja de bastar cuando un destinatario reenvía tu correo, porque entonces SPF ya no coincide. Google escribe además en sus preguntas frecuentes para remitentes que la alineación tanto con SPF como con DKIM probablemente acabará siendo un requisito, así que configura DKIM para tu dominio de todos modos.

¿Por qué DMARC falla con unos destinatarios y pasa con otros?

Porque el correo les llega por rutas distintas o desde remitentes distintos. Un destinatario que reenvía a otro buzón, o una lista de correo, cambia lo que ven SPF y, a veces, DKIM. También puede ser que uno de varios servicios de envío aún no esté configurado. Los informes agregados recogen los resultados por servidor de envío y muestran de qué caso se trata.

¿La dirección Reply-To influye en DMARC?

No. DMARC usa solo el dominio de la cabecera From. La dirección Reply-To, el nombre visible y la cabecera Sender no forman parte de la comprobación.

¿Cómo veo los problemas de alineación sin abrir cabeceras?

En los informes agregados de DMARC. Cada registro tiene un bloque policy_evaluated con un resultado dkim y otro spf, que son los resultados tras la prueba de alineación. El bloque auth_results que hay debajo muestra los resultados en bruto y los dominios a los que se referían. Un «pass» en bruto junto a un «fail» evaluado es exactamente el caso de esta página. Recibes los informes añadiendo una dirección rua a tu registro DMARC.

La cabecera dice dkim=fail o dkim=neutral. ¿Es el mismo problema?

No. En ese caso la firma misma no se ha verificado, y eso es otro fallo. Si el texto dice body hash did not verify, la página de solución de problemas de Google nombra la causa: el mensaje se modificó después de firmarse, por ejemplo en una pasarela que añade un pie. La alineación trata de una firma que es válida pero pertenece a otro dominio.

¿Necesito una clave DKIM distinta para cada servicio que envía en mi nombre?

En la práctica, sí. Cada servicio firma con su propia clave y la publica con su propio nombre de selector bajo _domainkey en tu dominio, de modo que varias claves conviven sin conflicto. Con SPF es distinto: un dominio solo puede tener un registro.