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

ejemplo.es.  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 el DNS del dominio firmante 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.ejemplo.es.  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 del 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@ejemplo-empresa.es en la cabecera. SPF pasado (para el sobre, malo.com). DKIM pasado (firmado por malo.com). Sin embargo, el lector ve la dirección del director de la empresa suplantada. 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:.

Repitamos el ataque con DMARC implementado. El correo del atacante pasa SPF y DKIM para malo.com, pero malo.com no coincide con ejemplo-empresa.es en el From:: la alineación falla, así que DMARC falla, y la política publicada (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, leer 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 su papel se explica en una guía dedicada.

Por qué los tres son necesarios

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

• SPF declara los 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— devuelve los informes que revelan cada fuente que dice hablar en nombre del dominio.

Retirar una deja 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. Publicar primero SPF y DKIM, y asegurarse de que las fuentes legítimas pasan y se alinean. Luego publicar DMARC en p=none para recopilar los informes, corregir las fuentes no alineadas que revelan, y finalmente subir la política hacia quarantine y después reject. Desarrollamos esta progresión paso a paso en alcanzar p=reject sin romper los emails. Y para visualizar la sintaxis exacta que publicar en cada peldaño, nuestros ejemplos de registros DMARC comentados van 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. Imaginemos un CRM que envía un recibo como facturacion@ejemplo-empresa.es 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 el 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 para el del remitente. Es un paso SPF técnicamente válido que no hace nada por DMARC, porque no está alineado con el From:.
2. DKIM verifica la firma. Si el CRM se ha configurado para firmar con d=ejemplo-empresa.es —generalmente mediante un CNAME facilitado por el proveedor—, la firma se verifica contra la clave pública publicada en el DNS de la empresa, y el dominio firmante es el suyo.
3. La alineación es el paso decisivo. ¿Se ha alineado SPF? Solo si el dominio de sobre coincidía con ejemplo-empresa.es, lo que generalmente no ocurre con un tercero. ¿Se ha alineado DKIM? Sí: d=ejemplo-empresa.es 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 los colores del cliente. Así, en la lectura de los informes agregados, una fuente que muestra DKIM alineado es una fuente resuelta; una fuente que falla en ambas alineaciones es la próxima tarea.

La constatación se hace en las cabeceras

No hace falta un laboratorio para observar las tres capas en acción: cada mensaje recibido lleva el veredicto. Basta con abrir las cabeceras completas de un email y buscar en ellas 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 del dominio de la empresa, uno de un remitente tercero, una newsletter— hace la lógica de alineación tangible como ningún esquema: el identificador evaluado por cada capa aparece negro sobre blanco, y con él la razón exacta del veredicto DMARC. 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. Ante este error, nuestra guía dedicada al límite de búsquedas DNS de SPF detalla el procedimiento, empezando por la consolidación de los include:.
• DKIM mal alineado. Una firma válida no basta: hace falta que el dominio firmante (d=) coincida con el 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. Pasar a strict sin haber comprobado que las fuentes firman bien sobre el dominio raíz rompe 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: el apilamiento SPF + DKIM + DMARC sigue siendo válido tal cual, DMARCbis lo precisa, no lo reescribe. Para el detalle de las novedades, ver qué es DMARC.

Las tres capas de un vistazo

Queda situar un dominio en las tres capas. Nuestro analizador gratuito verifica SPF, DKIM y DMARC juntos y muestra exactamente dónde están las brechas, incluido si las fuentes se alinean realmente, no solo si los registros existen. La comparación con la postura de todo un sector es posible 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, el 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 al dominio hasta la aplicación completa. Analizar un dominio o empezar aquí.