SPF, DKIM y DMARC: cómo funcionan los tres juntos

tu-dominio.com.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

DKIM: la firma que prueba la integridad

DKIM (DomainKeys Identified Mail) adopta otro enfoque. El servidor de envío firma cada mensaje con una clave privada; el destinatario recupera la clave pública correspondiente en tu DNS y verifica la firma. Si es válida, quedan probadas dos cosas: el mensaje no ha sido alterado en tránsito, y ha sido firmado por el titular de la clave de ese dominio.

selector1._domainkey.tu-dominio.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clave pública)"

DKIM sobrevive mucho mejor al reenvío que SPF, porque la firma viaja con el mensaje. Pero —y ahí está la trampa que DMARC corrige— una firma DKIM válida solo prueba que algún dominio ha firmado el mensaje. Por sí sola no exige que ese dominio sea el de tu From:.

La brecha que ambos dejan abierta

Aquí está el ataque que SPF y DKIM, por separado, no detienen. Un atacante registra malo.com, le configura un SPF y un DKIM impecables, y envía un correo que pasa ambos controles, para malo.com. Luego pone From: director@tu-empresa.com en la cabecera. SPF pasado (para el sobre, malo.com). DKIM pasado (firmado por malo.com). Sin embargo, el lector ve la dirección de tu director. Las dos capas están en verde, y la suplantación pasa. Hace falta algo que relacione la autenticación con el dominio visible. Ese algo es DMARC.

DMARC: la alineación lo relaciona todo

DMARC añade una regla decisiva por encima de SPF y DKIM: la alineación. Un mensaje pasa DMARC solo si pasa SPF o DKIM y el dominio autenticado coincide con el dominio del From:.

Repite el ataque con DMARC implementado. El correo del atacante pasa SPF y DKIM para malo.com, pero malo.com no coincide con tu-empresa.com en el From:: la alineación falla, así que DMARC falla, y tu política (idealmente p=reject) rechaza el mensaje. Ese mismo control de alineación es lo que hace a DMARC más fuerte que la suma de sus partes. Para la visión de conjunto fundamental, lee qué es DMARC.

Existen dos formas de alineación:

• Alineación SPF: el dominio del Return-Path coincide con el dominio del From:.
• Alineación DKIM: el dominio firmante (d=) coincide con el dominio del From:.

DMARC solo necesita una sola alineación (y paso) para autenticar el mensaje. En la práctica, la alineación DKIM es el objetivo más fiable, porque sobrevive al reenvío allí donde SPF falla. Quedan casos raros en los que un relay reescribe el mensaje y rompe ambas —algunas listas de distribución, en particular—; para esos, un mecanismo complementario llamado ARC toma el relevo, y te explicamos su papel en una guía dedicada.

Por qué quieres los tres

Una configuración robusta usa cada capa para lo que mejor hace:

• SPF declara tus servidores de envío legítimos y da al destinatario un primer control rápido.
• DKIM prueba la integridad y el origen, y sigue funcionando a través de reenvíos y listas de distribución.
• DMARC relaciona ambos con el dominio visible, dice a los destinatarios qué hacer en caso de fallo y —sobre todo— te envía los informes que revelan cada fuente que dice ser tú.

Quita una y tienes un agujero: SPF sin DMARC no protege el From:; DKIM sin DMARC no impone la alineación; DMARC sin SPF/DKIM funcionales no tiene nada que alinear.

Ponerlos en orden

La buena secuencia de despliegue sigue las dependencias. Publica primero SPF y DKIM y asegúrate de que tus fuentes legítimas pasan y se alinean. Luego publica DMARC en p=none para recopilar los informes, corrige las fuentes no alineadas que revelan, y finalmente sube la política hacia quarantine y después reject. Desarrollamos esta progresión paso a paso en alcanzar p=reject sin romper tus emails. Y para visualizar la sintaxis exacta que publicar en cada peldaño, echa mano de nuestros ejemplos de registros DMARC comentados, del más prudente al más estricto.

Un ejemplo concreto: seguir un mensaje

La teoría se aclara más rápido con un caso concreto. Imagina que tu CRM envía un recibo como facturacion@tu-empresa.com desde los servidores del proveedor CRM. Así es como las tres capas evalúan ese mensaje:

1. SPF verifica el dominio de sobre (Return-Path) contra tu registro publicado. La mayoría de las plataformas de terceros usan su propio dominio de rebote para el sobre: SPF pasa, pues, pero para el dominio del CRM, no el tuyo. Es un paso SPF técnicamente válido que no hace nada por DMARC, porque no está alineado con tu From:.
2. DKIM verifica la firma. Si has configurado el CRM para firmar con d=tu-empresa.com —generalmente mediante un CNAME facilitado por el proveedor—, la firma se verifica contra la clave pública de tu DNS, y el dominio firmante es el tuyo.
3. La alineación es el paso decisivo. ¿Se ha alineado SPF? Solo si el dominio de sobre coincidía con tu-empresa.com, lo que generalmente no ocurre con un tercero. ¿Se ha alineado DKIM? Sí: d=tu-empresa.com coincide con el dominio del From:.
4. Veredicto DMARC. DMARC solo necesita un paso alineado. DKIM alineado y pasado: el mensaje pasa DMARC, aunque SPF no se haya alineado en absoluto. El recibo se entrega y es de confianza.

Este ejemplo explica una regla que sorprende a muchos equipos: la alineación DKIM es el caballo de tiro de los despliegues reales. Los remitentes terceros alinean rara vez SPF (su sobre es el suyo), pero casi siempre se les puede llevar a alinear DKIM mediante un dominio de firma con tu marca. Así, cuando lees tus informes agregados, una fuente que muestra DKIM alineado es una fuente resuelta; una fuente que falla en ambas alineaciones es tu próxima tarea.

Míralo tú mismo en las cabeceras

No hace falta un laboratorio para observar las tres capas en acción: cada mensaje recibido lleva el veredicto. Abre las cabeceras completas de un email de tu bandeja y busca la línea añadida por el servidor destinatario, generalmente llamada Authentication-Results. Da el resultado SPF con el dominio de sobre verificado, el resultado DKIM con el dominio firmante, y el veredicto DMARC final. Leer así algunos mensajes reales —uno procedente de tu propio dominio, uno de un remitente tercero, una newsletter— hace la lógica de alineación tangible como ningún esquema: ves con tus propios ojos qué identificador ha evaluado cada capa, y por qué DMARC ha concluido lo que ha concluido. Es también el primer reflejo, el más rápido, cuando un mensaje aislado se comporta mal.

Tres errores que rompen el apilamiento

Incluso con los tres registros publicados, siempre son los mismos detalles los que hacen caer el edificio:

• SPF que supera diez resoluciones DNS. Demasiados include: apilados y SPF devuelve un PermError: más allá del límite, la evaluación se detiene y el control falla en bloque. Si ves este error, consulta nuestra guía dedicada al límite de búsquedas DNS de SPF, y piensa en consolidar tus include:.
• DKIM mal alineado. Una firma válida no basta: hace falta que el dominio firmante (d=) coincida con tu From:. La firma por defecto de una plataforma compartida (d=plataforma.com) pasa DKIM pero no se alinea: es la causa n.º 1 de un DMARC que falla cuando «todo está en verde».
• Confundir strict y relaxed. En alineación relaxed (adkim=r/aspf=r), un subdominio de envío basta; en strict (s), hace falta una coincidencia exacta. Pasa a strict sin haber comprobado que tus fuentes firman bien sobre el dominio raíz, y romperás correo legítimo.

¿Y DMARCbis en todo esto?

En mayo de 2026, DMARCbis (RFC 9989) modernizó DMARC, sin tocar el principio de alineación descrito aquí. SPF y DKIM conservan exactamente el mismo papel. Del lado de DMARC, la etiqueta pct desaparece (sustituida por t=y para el modo de prueba), una nueva etiqueta np cubre los subdominios inexistentes, y el DNS Tree Walk sustituye a la Public Suffix List para determinar el dominio organizacional. Dicho de otro modo: tu apilamiento SPF + DKIM + DMARC sigue siendo válido tal cual, DMARCbis lo precisa, no lo reescribe. Para el detalle de las novedades, ve qué es DMARC.

Ve tus tres capas de un vistazo

¿Quieres saber cómo se sitúa tu dominio en las tres, ahora mismo? Nuestro analizador gratuito verifica SPF, DKIM y DMARC juntos y muestra exactamente dónde están las brechas, incluido si tus fuentes se alinean realmente, no solo si los registros existen. También puedes comparar tu postura con la de todo un sector en el Observatorio DMARC, donde se ve que la alineación —no la existencia de los registros— es lo que distingue a los dominios de verdad protegidos.

Y cuando llega el momento de tapar esas brechas, Thomas, tu CISO virtual, identifica cada fuente de envío, genera los registros SPF, DKIM y DMARC precisos que hay que publicar (etiquetas DMARCbis incluidas), y guía a tu dominio hasta la aplicación completa. Analiza tu dominio → o empieza aquí.