¿DMARC falla pero SPF y DKIM pasan? La corrección de la alineación (2026)

Publicado 2026-07-08

Cifras a fecha de 2026-06-29 · metodología v7. Datos agregados del censo sobre 261 millones de dominios calificados. Consulte cómo calificamos.

DMARC necesita más que un pase: el dominio que pasó SPF o DKIM debe coincidir con su dominio From. La mayoría del correo con “SPF pasa, DMARC falla” pasó SPF en el dominio de rebote del proveedor, no en el suyo. Solo el 7,4% de 261.086.232 dominios calificados pasa SPF con alineación bajo una política DMARC con aplicación, según el censo de Defaults.Exposed (2026-06-29).

La corrección es más rápida de lo que la confusión sugiere. Lea la cabecera Authentication-Results para ver qué pata — SPF o DKIM — está pasando en el dominio equivocado; luego, o bien active la firma DKIM con dominio personalizado de su servicio de envío (normalmente unos pocos CNAME, y la corrección que sobrevive al reenvío), o bien configure su ruta de retorno personalizada para que SPF pase en su dominio. Una sola pata alineada es todo lo que DMARC necesita.

¿Cómo puede fallar DMARC cuando SPF y DKIM pasan los dos?

Porque DMARC nunca pregunta “¿pasó SPF?”. Pregunta: ¿pasó SPF o DKIM para un dominio que coincide con la dirección From que ve su destinatario? Esa condición extra se llama alineación, y es la razón de ser de DMARC — sin ella, cualquiera podría pasar SPF en un dominio de su propiedad mientras muestra el suyo en la cabecera From.

Cada comprobación autentica un dominio distinto:

Comprobación	Dominio que evalúa realmente	Dónde verlo
SPF	El Return-Path (RFC5321.MailFrom, la dirección de rebote/envelope-from) — no la cabecera From	`smtp.mailfrom=` en Authentication-Results
DKIM	El dominio de la etiqueta `d=` de la firma — el que el firmante haya elegido	`header.d=` en Authentication-Results
DMARC	El dominio de su cabecera From — y exige que el dominio de SPF o el `d=` de DKIM coincida con él	`header.from=` en Authentication-Results

Así es como las piezas suelen torcerse: su plataforma de boletines o su CRM envía con un Return-Path como [email protected], SPF se comprueba contra vendor.com y pasa, DKIM pasa con d=vendor.com — y DMARC falla, porque ninguno de los dominios que pasaron coincide con yourcompany.com. Todas las comprobaciones dijeron la verdad; ninguna le autenticó a usted. Editar su propio registro SPF no puede arreglar esto — nunca se consultó. Es la misma trampa tratada en SPF falla para sus herramientas SaaS.

El censo muestra qué pocos remitentes completan este último paso: 27.640.987 de 261.086.232 dominios calificados (10,59%) tienen siquiera una política DMARC con aplicación, y solo el 7,4% pasa SPF con alineación bajo una. Entre los 77,5 millones de dominios cuyo SPF termina en softfail (~all), apenas el 9,2% está bajo una política DMARC con aplicación; entre los publicadores de hardfail (-all), 12.142.351 tienen aplicación mientras que 42.514.532 no. La mayoría de los dominios se queda en “SPF pasa” — lo cual, sin un DMARC que actúe sobre ello, no protege casi nada.

¿Cómo leo Authentication-Results para ver qué pata está desalineada?

Envíese un mensaje a través del servicio que falla, abra el código fuente en bruto y localice la cabecera Authentication-Results. Un resultado desalineado típico se ve así:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=yourcompany.com

Léalo en tres comparaciones:

Pata SPF: ¿smtp.mailfrom= termina en su dominio? Aquí es bounces.espmail.net — desalineada.
Pata DKIM: ¿header.d= termina en su dominio? Aquí es espmail.net — desalineada.
Veredicto DMARC: header.from= es el dominio que DMARC defiende. Ninguna pata coincidió con él, así que dmarc=fail — aunque ambas comprobaciones individuales digan pass.

La pata que ya involucre su propio dominio (o que pueda llegar a hacerlo) es la que hay que arreglar. Solo necesita una.

¿Cuál es la diferencia entre alineación relajada y estricta?

DMARC ofrece dos modos de coincidencia, configurados con las etiquetas aspf (SPF) y adkim (DKIM) de su registro DMARC:

Relajada (r, la predeterminada): los dos dominios deben compartir el mismo dominio organizativo — el dominio registrable según la Public Suffix List. bounce.yourcompany.com se alinea con yourcompany.com; también lo hace un d=mail.yourcompany.com de DKIM. Por eso funcionan las rutas de retorno personalizadas y el DKIM personalizado de los proveedores, que viven en subdominios.
Estricta (s): los dominios deben coincidir exactamente, carácter por carácter. bounce.yourcompany.com ya no se alinea con yourcompany.com.

Si su registro no menciona aspf ni adkim, está en modo relajado — y casi con seguridad querrá quedarse ahí. El modo estricto no añade seguridad significativa para la mayoría de los remitentes y rompe en silencio a todo remitente legítimo por subdominio que usted configure. Si DMARC está fallando y su registro contiene aspf=s o adkim=s, eso por sí solo puede ser el fallo.

¿Cómo arreglo la alineación de DMARC?

Ejecute el análisis gratuito en defaults.exposed antes de tocar el DNS. Le muestra su registro y política DMARC, si su SPF y su DKIM están configurados para alinearse y qué más está roto — para que arregle primero la pata correcta.
Pruebe cada servicio de envío y lea su Authentication-Results (como se indica arriba). Liste todas las fuentes — proveedor de correo, herramienta de boletines, CRM, aplicación de facturación — y anote por fuente si smtp.mailfrom y header.d son su dominio o el del proveedor.
Active la firma DKIM con dominio personalizado en cada proveedor — la corrección que perdura. Todo servicio de envío serio ofrece “autenticación de dominio”: unos pocos registros CNAME que le permiten firmar como d=yourcompany.com (o un subdominio, que se alinea en modo relajado). El DKIM alineado suele ser la corrección más fácil y la única que sobrevive al reenvío, porque el reenvío rompe SPF por diseño.
Para la alineación de SPF, active la ruta de retorno personalizada del proveedor (a menudo llamada dominio de rebote personalizado) — típicamente un CNAME como bounce.yourcompany.com apuntando al proveedor. SPF pasa entonces en su dominio organizativo y se alinea. Hágalo donde se ofrezca, pero trátelo como la segunda pata, no como sustituto del DKIM alineado.
Deje la alineación en modo relajado salvo que tenga una razón concreta y bien entendida para aspf=s/adkim=s.
Vuelva a analizar, confirme ambas patas y avance hacia la aplicación. Una política DMARC de p=none informa pero no bloquea nada; una vez que sus remitentes reales se alineen, la ruta completa hacia una política que le proteja está en la página de arreglar DMARC, y guías por proveedor como DMARC en IONOS cubren los clics en el panel de DNS.

¿Debería arreglar la alineación de SPF o la de DKIM?

Necesita una pata alineada por cada fuente de envío. Si solo puede hacer una, la elección no está reñida:

Corrección	Qué implica	¿Sobrevive al reenvío?
DKIM alineado (firma con dominio personalizado)	Unos pocos CNAME en el panel de “autenticación de dominio” del proveedor	Sí — la firma viaja con el mensaje
SPF alineado (ruta de retorno/dominio de rebote personalizado)	Un CNAME, donde el proveedor lo ofrezca	No — la IP de cualquier reenviador reemplaza a la del proveedor

El caso especial que conviene conocer: Google Workspace y Microsoft 365 firman su correo con DKIM de forma predeterminada con sus propios dominios de reserva (gappssmtp.com, onmicrosoft.com) — así que DKIM muestra pass mientras DMARC sigue fallando. Es la instancia concreta más común de todo este problema, y tiene su propia guía: DKIM pasa pero DMARC sigue fallando: la trampa de la firma predeterminada.

Preguntas frecuentes

¿Tienen que alinearse tanto SPF como DKIM para que DMARC pase? No — un solo pase alineado es suficiente. La buena práctica es alinear ambos de todos modos, para que cuando el reenvío rompa la pata SPF, la pata DKIM siga aportando el pase de DMARC. De 261.086.232 dominios calificados en el censo de 2026-06-29, solo el 3,87% completa la tríada SPF + DMARC + DKIM.

El panel de mi ESP dice que SPF y DKIM están “verificados” — ¿por qué DMARC sigue fallando? “Verificado” suele significar que los envíos propios del proveedor pasan en los dominios del proveedor. A menos que haya completado sus pasos de dominio personalizado (CNAME de DKIM, ruta de retorno personalizada), el correo se autentica como el proveedor, no como usted — y DMARC compara contra su dominio From.

¿Basta un registro SPF estricto -all sin alineación? No. Un calificador estricto refuerza el veredicto de SPF sobre el dominio del Return-Path, pero DMARC sigue necesitando que ese dominio sea el suyo. Según el censo de 2026-06-29, solo 12.142.351 de los dominios que publican -all están bajo una política DMARC con aplicación — los otros 42.514.532 tienen un registro estricto sobre el que ninguna política actúa.

¿Debería pasar a alineación estricta (aspf=s/adkim=s) para más seguridad? Casi nunca. La alineación relajada ya exige el mismo dominio registrable, que un suplantador no controla. El modo estricto sobre todo rompe sus propios remitentes por subdominio — compruébelo siempre que la alineación falle de forma inesperada.

DMARC falla solo en el correo que los destinatarios reenvían — ¿misma corrección? Eso es la pata SPF muriendo en tránsito: el servidor del reenviador no está en el registro SPF de nadie para su ruta de retorno. No puede arreglar SPF para el correo reenviado; el DKIM alineado es la respuesta, ya que la firma sobrevive intacta al reenvío. Detalles en el correo reenviado falla SPF.

Envíe el informe al propietario

Si está arreglando esto para un cliente o para su empresa, cierre el círculo con pruebas. Vuelva a ejecutar el análisis gratuito cuando los CNAME estén activos y reenvíe el informe calificado al propietario del negocio: fechado, en lenguaje claro, mostrando SPF, DKIM y DMARC alineados y pasando. Ese es el documento que necesitarán para la renovación del ciberseguro y el próximo cuestionario de seguridad de proveedores — la prueba de una configuración que funciona, no solo “añadí unos registros DNS”.

Compruebe su dominio → · DKIM pasa pero DMARC sigue fallando → · Arreglar DMARC → · Cómo calificamos → · Solo datos agregados. Datos almacenados y procesados en la UE.