6 fallos más comunes de DKIM y DMARC y cómo solucionarlos

SPF (Sender Policy Framework) es solo una pieza del rompecabezas de la autenticación de correo electrónico. Puedes tener un registro SPF perfecto y aun así ver que tus correos van a spam, son rechazados o fallan DMARC. ¿La razón? DKIM (DomainKeys Identified Mail) y DMARC (Domain-based Message Authentication, Reporting, and Conformance) introducen sus propios modos de fallo que afectan incluso a administradores de correo electrónico experimentados.

Vemos esto constantemente en las organizaciones que utilizan Red Sift OnDMARC. Un equipo de marketing configura SPF correctamente pero nunca activa la firma DKIM. Un equipo de TI publica un registro DMARC en p=none y lo deja así durante un año. Un remitente externo firma los correos con su propio dominio en vez del tuyo, rompiendo la alineación. No son casos excepcionales. Son la realidad cotidiana de la autenticación de emails en 2026.

Con los nuevos requisitos de autenticación de email en 2026, SPF por sí solo no siempre te salvará de tener problemas de entrega de correo. Siempre que sea posible, tener DKIM Y SPF configurados es la mejor forma de asegurar tasas óptimas de entrega.

El calendario de aplicación hace que esto sea urgente. Google y Yahoo empezaron a exigir SPF, DKIM y DMARC para remitentes masivos en febrero de 2024 [1]. Microsoft siguió en mayo de 2025, rechazando emails no compatibles con el código de error 550 5.7.515 [2]. No son recomendaciones suaves. Gmail pasó de advertencias educativas a rechazos directos en noviembre de 2025 y Microsoft empezó a rechazar directamente, en vez de enviar al correo no deseado.

Las cifras de adopción muestran cuánto le falta aún al sector. Un estudio sobre 5,5 millones de dominios reveló que solo el 22,7% tenía un registro DKIM detectable, siendo este el protocolo de autenticación de email central menos adoptado [3]. Y aunque la adopción de DMARC crece, el 69,6% de los dominios aún carecen de registro DMARC, y solo el 6% aplica p=reject [3]. El análisis propio de Red Sift sobre 73,3 millones de dominios muestra que solo el 2,5% han implementado p=reject [4].

Mientras tanto, las pérdidas por ciberdelitos no paran de crecer. El Informe de Delitos en Internet del FBI de 2025 registró más de 20,8 mil millones de dólares en pérdidas totales (un 26% más que en 2024), con phishing y suplantación de identidad como la categoría de crimen más denunciada, con 191.561 quejas [5]. El compromiso de correo empresarial supuso más de 3.000 millones de pérdidas en 24.768 incidentes [5]. Configuraciones correctas de SPF y DKIM, junto con la aplicación total de DMARC, son como detienes a los atacantes de suplantar tu dominio y llegar a tus clientes. Tener DKIM en todas las fuentes legítimas de envío permite que el reenvío no rompa la autenticación ni ocasione problemas de entrega.

La presión de cumplimiento también es real. PCI DSS v4.0.1 exige DMARC en cuarentena o rechazo para entidades que procesan pagos [6]. CISA, el NCSC del Reino Unido, el ASD de Australia y el CCCS de Canadá exigen DMARC para dominios gubernamentales. Para un resumen completo, consulta nuestro resumen de mandatos globales de DMARC. Las aseguradoras de ciberseguridad cada vez exigen la aplicación de DMARC como condición de suscripción.

Aquí tienes los seis fallos de DKIM y DMARC que más vemos y cómo solucionar cada uno exactamente.

Cómo se ve: Tus informes DMARC o cabeceras muestran dkim=fail (hash del cuerpo no verificado). La firma DKIM existe, la clave pública está en DNS, pero la verificación falla igual.

Por qué pasa: DKIM funciona calculando un hash del cuerpo del correo justo en el momento de firmar (la etiqueta bh= en la cabecera DKIM-Signature). El servidor receptor consulta luego la clave pública vinculada al selector que firmó el mensaje y recalcula el hash. Si algo cambia entre el firmado y la entrega, los hashes no coinciden y DKIM falla.

Los causantes normales son sistemas intermedios que modifican el mensaje después de que tu servidor envía el mail firmado:

• Paredes de seguridad para email que reescriben URLs para análisis seguros (Microsoft Defender, Barracuda y plataformas similares)
• Filtros antispam que añaden o modifican cabeceras
• Software de listas de correo que añade pies, cabeceras de lista, enlaces para desuscribirse, o reescribe el dominio SMTP MailFrom y retira o reemplaza la firma DKIM original por la suya propia
• Herramientas DLP (prevención de fuga de datos) que escanean y a veces modifican el contenido saliente
• Reenvío automático donde el servidor reenvía y modifica el cuerpo del mensaje

Este es uno de los fallos de DKIM más difíciles de diagnosticar porque la firma en sí es válida: la clave coincide, el selector es correcto y el registro existe en DNS. El problema es que el cuerpo del mensaje cambió después de ser firmado.

Cómo solucionarlo:

El principio fundamental: la firma DKIM debe realizarse como último paso antes de que el mensaje salga de tu infraestructura. Si algún sistema modifica el mensaje tras firmarlo, la firma se rompe.

• Reordena tu flujo de correo. Si tienes una puerta de seguridad que reescribe URLs, asegúrate de que la firma DKIM se realice después de esa reescritura, no antes. A menudo implica configurar la puerta de correo para firmar en nombre de tu dominio y no depender de que tu servidor de correo firme primero.
• Usa c=relaxed/relaxed para la canonización. DKIM soporta dos modos de canonización: simple y relaxed. El modo relaxed tolera cambios menores de espacios o formato de cabecera. Configura ambos en modo relaxed (c=relaxed/relaxed) para reducir falsos fallos.
• Identifica el sistema que modifica. Compara el hash dkIM del cuerpo en la firma original (bh=) con lo que el receptor calcula. Si difieren, algo en el trayecto modificó el cuerpo. Examina tu flujo de correo desde la aplicación emisora hasta cualquier puerta, filtro o relay para identificarlo.
• Para listas de correo y reenvíos, confía en DKIM + ARC. Las listas de correo modificarán tus mensajes (es su función). Esto no se puede evitar. ARC (Authenticated Received Chain) conserva los resultados de autenticación originales a través de las cadenas de reenvío, y proveedores principales como Gmail y Microsoft evalúan ARC al decidir la entrega. De tu lado, asegúrate de que DKIM esté siempre configurado y la entrega directa pase. Usa Red Sift Investigate para verificar que tus mensajes pasen los checks de hash antes de cualquier reenvío. Para más sobre cómo el reenvío afecta la autenticación, consulta nuestra guía de configuración de SPF, DKIM y DMARC.

Cómo se ve: Las cabeceras muestran dkim=fail (no hay clave para la firma) o dkim=permerror. El servidor receptor no encuentra o no puede interpretar tu clave pública DKIM en DNS.

Por qué pasa: DKIM depende de una clave pública publicada en DNS en una localización concreta: selector._domainkey.yourdomain.com. Cuando el receptor no puede encontrar o interpretar ese registro, la verificación DKIM falla totalmente. Este es el fallo más frecuente de DKIM y ocurre por varias razones:

• El registro DNS nunca se creó. Alguien activó la firma DKIM pero nunca añadió la clave pública en DNS. Google Workspace, por ejemplo, requiere que generes la clave DKIM en el Admin Console y luego añadas el registro TXT o CNAME en DNS manualmente. Si omites ese paso, la firma ocurre pero la verificación siempre falla.
• El registro está en la zona DNS incorrecta. Si gestionas DNS en varios sitios (registrador, Cloudflare, proveedor de hosting), quizá el registro DKIM esté en una zona inactiva. El servidor receptor busca en el DNS autoritativo y no encuentra nada.
• Claves de 2048 bits truncadas. Las claves públicas DKIM RSA de 2048 bits son largas y pueden superar el límite de 255 caracteres en una cadena TXT DNS. Si tu proveedor de DNS trunca la clave en vez de dividirla en varias cadenas entrecomilladas, la verificación falla porque la clave está incompleta.
• Selector no coincidente. La etiqueta s= en la cabecera DKIM-Signature define el selector para la consulta DNS. Si el selector de la firma no coincide con el del registro DNS, la consulta no devuelve nada. Esto es frecuente si tu ESP rota selectores y el antiguo permanece en DNS pero el nuevo nunca se añadió.

Cómo solucionarlo:

Empieza identificando el selector. Busca la cabecera DKIM-Signature de un correo enviado (en Gmail, haz clic en "Mostrar original"). Encuentra la etiqueta s=; ese es tu selector. Puedes consultar DNS manualmente o usar el Analizador de Dominios de Red Sift OnDMARC.

Introduce tu dominio y el selector a comprobar y verás el registro DKIM completo junto a cualquier problema de configuración.

dig TXT selector._domainkey.yourdomain.com +short

Si la consulta no devuelve nada, el registro falta. Si devuelve una clave parcial, está truncada.

• Para registros ausentes: Entra en la consola de administración de tu servicio de correo, busca la página de configuración de DKIM y copia el registro de clave pública. Añádelo en tu zona DNS activa como registro TXT en selector._domainkey.yourdomain.com.
• Para claves truncadas: Divide la clave en cadenas entrecomilladas de máximo 255 caracteres dentro de un solo registro TXT. La mayoría de proveedores DNS modernos gestionan esto automáticamente con DKIM vía CNAME.
• Para selectores no coincidentes: Verifica que el selector en tu sistema de correo coincide con el del DNS. Si tu ESP cambió el selector, actualiza DNS para reflejarlo.
• Usa DKIM basado en CNAME si es posible. En vez de publicar la clave pública como registro TXT, muchos ESP permiten delegar DKIM vía CNAME, apuntando tu selector a su DNS. Así, cuando ellos rotan claves, lo actualizan por su parte y tu DNS no necesita cambios.

Cómo se ve: DKIM funcionó durante meses y de repente falla. Las cabeceras muestran dkim=fail sin cambios de DNS ni configuración.

Por qué pasa: Las claves DKIM no son permanentes. Necesitan rotarse periódicamente por motivos de seguridad y, si la rotación sale mal, la autenticación falla silenciosamente.

Tres escenarios frecuentes:

• El ESP rotó claves sin avisarte. Si usas DKIM basado en TXT (la clave pública está en tu DNS), el ESP puede rotar la clave privada cuando quiera. Si emite una nueva clave privada pero tú no actualizas la pública en DNS, la firma no verifica. Es el fallo más frustrante porque en tu lado no cambia nada.
• Claves de 1024 bits rechazadas o marcadas. NIST recomienda mínimo 2048 bits para RSA, y el sector ya ha adoptado ese estándar [7]. Algunos receptores ya marcan/rechazan firmas con claves de 1024 bits. Si configuraste DKIM hace años y nunca actualizaste, podría ser tu caso.
• La etiqueta x= de expiración activada. Las firmas DKIM pueden llevar una etiqueta x= opcional que especifica su expiración. Si el correo se demora en tránsito (por ejemplo, en cola), y llega tras esa fecha, la verificación falla aunque todo lo demás esté correcto.

Cómo solucionarlo:

• Pasa a claves de 2048 bits. Si aún usas 1024, actualiza ya. En Microsoft 365, usa el PowerShell Rotate-DkimSigningConfig para aumentar el tamaño. En Google Workspace, genera una nueva clave 2048 en Admin Console \> Apps \> Google Workspace \> Gmail \> Authenticate email. La guía de configuración de protocolos de correo cubre la gestión DKIM en detalle.
• Utiliza DKIM vía CNAME para evitar líos con la rotación. Delegando DKIM por CNAME a tu ESP, la rotación de claves ocurre en su infraestructura. Nunca tendrás que actualizar DNS. Red Sift OnDMARC va más allá gestionando todas tus configuraciones DKIM desde una sola plataforma.
• Rota claves programadamente. La buena práctica (recomendada por M3AAWG) es rotar claves DKIM cada 6-12 meses para claves de 2048 bits. Usa nombres de selector descriptivos con fecha (como jan2026) para identificar cuándo se creó la clave.
• Evita o pon valores amplios en x=. Si usas la etiqueta de expiración, asegúrate de dar margen suficiente para retrasos de entrega. Muchos optan por omitir x= para evitar este modo de fallo.

Cómo se ve: DKIM pasa (dkim=pass), pero DMARC igual falla. Los reportes DMARC muestran DKIM autenticando pero falla la alineación.

Por qué pasa: Este es el fallo DKIM más común en DMARC y afecta a casi toda empresa que usa servicios de correo externos.

DMARC no solo comprueba que DKIM pase. Comprueba la alineación: el dominio en la etiqueta d= de la firma DKIM debe coincidir (o ser subdominio) del dominio que aparece en el remitente From. Cuando un tercero firma con su propio dominio y no el tuyo, DKIM pasa pero DMARC falla alineación.

Así ocurre.

• Usas SendGrid para mandar campañas desde marketing@yourdomain.com.
• SendGrid firma por defecto con d=sendgrid.net.
• El receptor verifica DKIM: la firma concuerda con la clave pública de SendGrid, así que dkim=pass.
• Luego DMARC revisa la alineación: ¿sendgrid.net coincide con yourdomain.com?
• No. La alineación falla. Si SPF también falla alineación (que ocurre a menudo con servicios externos), DMARC falla completamente.

Pasa con casi todos los ESP, CRM y plataformas SaaS que envían correos. Mailchimp, HubSpot, Salesforce, Zendesk, Freshdesk, Intercom: todos firman con su propio dominio por defecto salvo que configures DKIM personalizado.

Cómo solucionarlo:

En cada servicio que envíe por tu dominio, configura la firma DKIM personalizada para que la etiqueta d= use tu dominio:

• La mayoría de ESP (Mailchimp, SendGrid, HubSpot, etc.): Busca "Domain Authentication" o "Custom DKIM" en la configuración de la plataforma. El ESP te dará registros CNAME o TXT para tu DNS. Una vez listo, firmarán con d=yourdomain.com en vez del suyo.
• Google Workspace: DKIM firma con tu dominio por defecto, pero debes activarlo en la consola y añadir el registro DNS.
• Microsoft 365: El DKIM personalizado debe activarse desde el portal Defender de Microsoft 365. Microsoft proporciona dos registros CNAME selector por dominio.

Tras configurar DKIM personalizado en cada remitente, revisa tu modo de alineación DMARC. DMARC tiene dos modos (con la etiqueta adkim=):

• Relaxed (adkim=r): El dominio de la firma DKIM puede ser subdominio del remitente From. mail.yourdomain.com alinea con yourdomain.com. Es la opción por defecto y recomendada para casi todas las organizaciones.
• Strict (adkim=s): El dominio firmado debe coincidir exactamente con From. Usa solo si requieres máxima seguridad.

Red Sift OnDMARC identifica qué remitentes pasan DKIM pero fallan alineación, mostrando el d= [dominio] no coincidente que causa el problema. Para una explicación más detallada de cómo interactúan DKIM, SPF y DMARC, consulta nuestra guía comparativa.

Cómo se ve: Tu registro DMARC existe, recibes informes, pero la política es p=none. Correos suplantados con tu dominio se entregan sin filtro. Tu dominio es técnicamente "DMARC-enabled" pero no "DMARC-protected".

Por qué pasa: Quedarse en p=none es el fallo de DMARC más extendido, y no es técnico, es de operativa.

Las organizaciones publican DMARC en p=none para recolectar reportes agregados. Es el paso inicial correcto. Pero luego nunca activan la política de aplicación. Las causas: los informes son difíciles de leer (XML crudo), el equipo no identifica todos los remitentes legítimos, nadie quiere bloquear correos válidos y la prioridad se pierde. Pueden pasar meses o años y el registro sigue en p=none, sin proteger nada.

Las cifras son contundentes. De 5,5 millones de dominios analizados, el 17,6% tienen DMARC en p=none [3]. Red Sift con 73,3 millones halló que solo el 14,9% están en proceso de aplicar DMARC y un 2,5% en p=reject [4]. La mayoría están solo monitorizando.

Una política p=none es herramienta de informes, no de seguridad. Le dice a los servidores destinatarios que entreguen todo, sin importar la autenticación, y que te envíen solo reportes. Los atacantes pueden suplantar tu dominio a placer y sus mensajes llegarán siempre.

Cómo solucionarlo:

El camino de p=none a p=reject es directo si tienes la herramienta adecuada. Recomendamos este método con Red Sift OnDMARC:

1. Identifica todos los remitentes legítimos. Usa los informes DMARC agregados para crear el inventario de todas las entidades que envían como tu dominio. OnDMARC lo hace automáticamente clasificando remitentes y mostrando el estado de autenticación.
2. Soluciona la autenticación remitente a remitente. Configura SPF y DKIM en todas las fuentes válidas. Asegúrate de que al menos uno (mejor ambos) pase con alineación para cada origen.
3. Pasa a p=quarantine. Cuando todos estén autenticados, pon la política en cuarentena. Así los emails fallidos van a spam y no a bandeja de entrada. Vigila una o dos semanas para detectar omisiones.
4. Pasa a p=reject. Tras confirmar que no se bloquea correo legítimo, activa el rechazo. Así los destinatarios bloquean los fallos DMARC totalmente.
5. Aplica la etiqueta pct= para un despliegue gradual. Si da miedo pasar a rejection directo, usa pct=25 para aplicar la política a solo el 25% del tráfico fallido al principio. Sube progresivamente (50%, 75%, 100%) según ganes confianza.

Con la plataforma adecuada, una organización suele alcanzar p=reject en 6-8 semanas. Sin ella, muchos nunca llegan. Nuestra guía paso a paso de aplicación DMARC detalla el proceso completo.

Cómo se ve: SPF y DKIM muestran pass en cabeceras o reportes DMARC, pero DMARC igual falla. Es uno de los fallos más confusos, ya que todo parece en orden pero no lo está.

Por qué pasa: DMARC exige alineación, no solo autenticar. SPF y DKIM pueden aprobar sus pruebas, pero si los dominios autenticados no coinciden con el remitente visible en From, DMARC falla.

Se realizan dos comprobaciones de alineación al mismo tiempo:

• Alineación SPF: El dominio en Return-Path (envelope-from) debe coincidir o ser subdominio de From.
• Alineación DKIM: El dominio en la etiqueta d= de la firma DKIM debe coincidir o ser subdominio de From.

DMARC pasa si al menos una comprobación de alineación tiene éxito. Falla solo si ninguna alinea.

Un ejemplo real:

• Tu empresa envía mails a clientes desde support@yourdomain.com por Zendesk.
• Zendesk usa su propio dominio (Return-Path @zendesk.com).
• SPF revisa el registro de Zendesk, localiza la IP y SPF aprueba, pero el dominio es zendesk.com, no yourdomain.com.
• La alineación falla. Zendesk también firma con d=zendesk.com por defecto. DKIM aprueba con la clave de Zendesk, pero falla alineación porque zendesk.com no es yourdomain.com.
• Ambos protocolos aprueban autenticación pero fallan alineación. DMARC falla.

Este patrón se repite con casi todos los remitentes de terceros no configurados con autenticación personalizada.

Cómo solucionarlo:

Necesitas que uno de los protocolos pase y alinee. Lo más fiable es corregir ambos:

• Para alineación DKIM: Configura la firma DKIM personalizada en todo remitente externo para que la etiqueta d= use tu dominio. (Ver fallo #4 arriba para instrucciones específicas.)
• Para alineación SPF: Configura cada remitente para que use tu dominio (o subdominio) como Return-Path. Esto depende de la plataforma. Salesforce requiere deshabilitar gestión de rebotes. HubSpot y Marketo permiten personalizar envelope-from.
• Usa alineación relaxed por defecto. Con aspf=r y adkim=r (ambos valores por defecto en DMARC), los subdominios cuentan como alineados. Si tu plataforma manda con Return-Path bounce.yourdomain.com y el From es yourdomain.com, pasa la alineación relaxed.

El diagnóstico es simple: revisa los informes DMARC agregados. Muestran autenticación (pass/fail) alineada a resultados de alineación para ambos (SPF y DKIM). Si ves pass + alineación fail, ya sabes qué protocolo y remitente revisar.

Red Sift OnDMARC lo desglosa por remitente, mostrando de un vistazo qué servicios pasan autenticación pero fallan alineación y cuál es el desajuste. Consulta tu estado con Red Sift Investigate para ver tu situación actual.

Para depurar errores, la cabecera Authentication-Results de los emails recibidos te dice exactamente qué ocurrió. Esto es lo que debes buscar:

Para un monitoreo continuo más allá de las comprobaciones individuales de correo electrónico, los informes agregados de DMARC te ofrecen una visión completa de todas las fuentes de envío. Red Sift OnDMARC transforma los informes XML en bruto en paneles de control útiles, y nuestra guía de las mejores herramientas de autenticación de correo electrónico cubre recursos adicionales para cada etapa de la implementación.

Los fallos de DKIM y DMARC siguen patrones previsibles. Discordancias en el hash del cuerpo, registros DNS faltantes, lagunas en la rotación de claves, desajustes de alineación, políticas estancadas y la brecha de alineación entre aprobar la autenticación y aprobar DMARC. Todos pueden diagnosticarse con los encabezados de los correos electrónicos e informes DMARC, y todos pueden corregirse.

El mayor riesgo no es la complejidad. Es la inacción. Un registro DMARC en p=none te da visibilidad pero cero protección. Cada día que tu dominio permanece en p=none es un día más en que los atacantes pueden suplantarte sin consecuencia alguna.

[1] Una actualización sobre los requisitos para emisores masivos \- Google

[2] Fortalecimiento del ecosistema de correo electrónico \- Microsoft Community Hub

[3] DKIM Fail: Cómo solucionar errores de alineación y verificación \- DMARCguard

[4] SPF Flattening: El problema oculto en la infraestructura de correo electrónico \- AutoSPF

[5] Informe anual IC3 2025

[6] Resumen de cambios de PCI DSS v4.0.1

[7] RFC 6376 \- DomainKeys Identified Mail (DKIM) Signatures