SPF, DKIM y DMARC: qué hace realmente cada uno

Alguien te reenvía una captura: un correo con una factura, el nombre de tu empresa en el remitente y un enlace de pago que no es vuestro. Revisas los registros del servidor de salida. No salió nada. Ese mensaje nunca tocó vuestra infraestructura: el atacante simplemente escribió vuestro dominio en el campo De, igual que uno puede poner cualquier remite en un sobre.

Ese es el agujero que existen para tapar SPF, DKIM y DMARC. Se nombran casi siempre de un tirón, como si fueran tres versiones de la misma idea, y ese encuadre es justo lo que los vuelve confusos. Ni son redundantes ni son intercambiables. Cada uno responde a una pregunta distinta, y solo el tercero tiene que ver con la dirección que ven de verdad tus destinatarios.

Las dos direcciones de remitente que nadie te menciona

Antes de que los registros tengan sentido hay que dejar clara una pieza del mecanismo que hay debajo, porque casi todo resultado desconcertante de DMARC acaba aquí: un correo tiene dos direcciones de remitente y no tienen por qué coincidir.

• El remitente del sobre, también llamado MAIL FROM y que, una vez entregado, queda como cabecera Return-Path. Es de nivel SMTP: la dirección que declara el servidor emisor durante el saludo y adonde van los rebotes. Tu destinatario no la ve nunca.
• La cabecera From, la que dibuja el cliente de correo. Es la que lee una persona y en la que confía.

Son campos independientes. Una newsletter que envías legítimamente a través de una plataforma de marketing suele llevar el remitente del sobre en bounces.mailer-provider.com y la cabecera From en tuempresa.com: perfectamente normal, no es una falsificación. Pero ese hueco es también toda la oportunidad del atacante: pasar la autenticación en un dominio que controla y mostrar uno que no.

Retén esa distinción. Es la razón de que SPF por sí solo no frene la suplantación, y la razón de que DMARC tuviera que inventar la alineación.

SPF: qué servidores pueden enviar por este dominio

SPF (Sender Policy Framework, RFC 7208) publica en el DNS la lista de direcciones IP autorizadas a enviar correo por un dominio, en forma de registro TXT:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.25 -all

Se lee de izquierda a derecha: el correo desde los rangos de Google Workspace pasa, el de los rangos de SendGrid pasa, el de ese servidor concreto pasa, y -all dice que todo lo demás falla. El servidor receptor toma la IP que se conecta, recorre la lista y devuelve un resultado.

Ese mecanismo final pesa mucho más de lo que su tamaño sugiere:

En la práctica pesan tres límites. Primero, SPF tiene un presupuesto de diez términos que consultan al DNS (RFC 7208 §4.6.4). include, a, mx, ptr, exists y redirect gastan uno cada uno, y include gasta de forma recursiva, así que cuatro o cinco proveedores SaaS te pueden pasar de largo sin que te enteres. A partir de diez, la evaluación devuelve PermError, que cuenta como fallo de SPF. El registro no parece roto por ninguna parte; simplemente deja de funcionar para algunos remitentes.

Segundo, y más de fondo: SPF autentica el remitente del sobre, no la cabecera From. Un atacante registra un dominio desechable, publica para él un registro SPF impecable, envía desde su propio servidor y pasa SPF, mientras la cabecera From dice el nombre de tu empresa. SPF hizo bien su trabajo. Su trabajo nunca fue proteger la dirección que ve quien lee.

Tercero, una incomodidad práctica: SPF se rompe con el reenvío. Cuando un destinatario reenvía tu mensaje automáticamente, el servidor que reenvía lo retransmite desde su IP, que no está en tu registro. SPF falla sin que tú hayas hecho nada mal.

Para ver tu propio presupuesto desplegado, incluidos los include dentro de include que lo consumen, pega tu dominio en el comprobador de SPF y DMARC: recorre el árbol entero y cuenta cada término que gasta una consulta. Lee ese total como un techo y no como un veredicto: la evaluación se detiene en el primer mecanismo que casa, así que pasar de diez rompe las rutas de envío que llegan más allá de la décima consulta, no todo tu correo.

DKIM: una firma que sobrevive al viaje

DKIM (DomainKeys Identified Mail, RFC 6376) adjunta una firma criptográfica al propio mensaje. El servidor emisor firma un conjunto de cabeceras más el cuerpo con una clave privada y añade una cabecera DKIM-Signature:. La clave pública vive en el DNS; el receptor la recupera y verifica.

La cabecera de la firma indica dónde está su propia clave:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
  h=from:to:subject:date; bh=...; b=...

d= es el dominio firmante y s= es el selector. Juntos apuntan al nombre DNS selector1._domainkey.example.com, donde está la clave pública. Separar la ubicación de la clave en un selector es lo que permite que un dominio use varias claves a la vez: una por proveedor, o una antigua y una nueva durante una rotación.

Como la prueba viaja dentro del mensaje, DKIM aguanta el reenvío: reenvía un mensaje firmado y la firma sigue verificando, siempre que no haya cambiado nada. La otra cara es esa misma: DKIM se rompe con las modificaciones. Las listas de correo que añaden un pie o reescriben el asunto invalidan la firma que dejan pasar.

Dos detalles útiles al leer una firma: h= enumera exactamente qué cabeceras se firmaron, y una firma que no cubre From no vale casi nada, porque el atacante puede cambiar el remitente visible sin tocarla. Y l= fija un límite de longitud del cuerpo, firmando solo los primeros N bytes; lo que se añada más allá queda sin firmar y sin que nadie lo note.

Hay una asimetría más que conviene tener presente al auditar un dominio: el DNS no ofrece ninguna forma de listar los selectores que publica un dominio. Puedes consultar un selector que ya conozcas, pero no enumerarlos. Cualquier herramienta que informe sobre DKIM está sondeando nombres habituales o pidiéndote los tuyos, así que «no se encontró clave» significa «ninguno de los nombres que probé coincidió», nunca «este dominio no tiene DKIM».

DMARC: atar las comprobaciones al remitente visible

Aquí es donde los dos anteriores se vuelven útiles. SPF autentica el sobre. DKIM autentica un dominio firmante. Ninguno está obligado a tener nada que ver con la cabecera From, y la cabecera From es lo único que lee el destinatario.

DMARC (RFC 9989) cierra ese hueco con una regla llamada alineación: un pass de SPF o de DKIM solo cuenta si el dominio que autenticó coincide con el dominio de la cabecera From.

Un mensaje pasa DMARC cuando se cumple cualquiera de estas dos cosas:

• SPF pasa y el dominio del remitente del sobre se alinea con el dominio de From, o
• DKIM pasa y el dominio d= de la firma se alinea con el dominio de From.

Con una basta, y por eso DKIM por sí solo mantiene el correo reenviado pasando después de que SPF se haya roto.

Ahora el ataque del principio se desmonta. El dominio desechable del atacante sigue pasando SPF, pero ese dominio no se alinea con la cabecera From, así que no aporta nada a DMARC. Sin ningún pass alineado, DMARC falla, y la política que hayas publicado decide qué hace el receptor al respecto.

La alineación tiene dos modos, que se fijan por mecanismo con aspf y adkim:

• Relajada (r, la de por defecto): basta con que coincidan los dominios organizativos. mail.example.com se alinea con example.com.
• Estricta (s): los dominios deben coincidir exactamente. mail.example.com no se alinea con example.com.

Para casi todo el mundo, relajada es el valor correcto. La estricta merece elegirse a conciencia: descarta toda una clase de abuso basado en subdominios, pero tumba cualquier correo en el que el dominio autenticado sea un subdominio del que aparece en la cabecera From, que es justo la forma que tiene la mayoría de los envíos vía SaaS.

De dónde sale el dominio organizativo ha cambiado. RFC 9989 lo determina con un recorrido del árbol DNS (consultando nombres cada vez más cortos en busca de un registro de política) en lugar de consultar la Public Suffix List, como hacía RFC 7489. Para un empresa.com corriente la respuesta es la misma por ambos caminos, así que la mayoría de dominios no nota nada. Importa en los bordes: sufijos de varias etiquetas y organizaciones que publican política en varios niveles de su espacio de nombres.

La política en sí es un registro TXT en _dmarc.tudominio.com:

v=DMARC1; p=reject; sp=reject; np=reject; adkim=r; aspf=r;
  rua=mailto:informes-dmarc@tudominio.com

np es la que más merece añadirse a propósito. A los atacantes les encanta inventarse subdominios que nunca creaste: facturacion.tuempresa.com no tiene ningún registro DNS, así que nada de tu configuración real de correo lo limita. np=reject corta esa vía sin tocar los subdominios que sí usas.

Y t es la etiqueta que la gente malinterpreta. t=y no significa «ignora mi política». Pide a los receptores que no apliquen directamente la política publicada. RFC 9989 prevé un escalón menos estricto: reject pasa a quarantine y quarantine a none, aunque el tratamiento final sigue siendo decisión del receptor. Es un freno de despliegue: con t=y, tu p=reject solicita cuarentena hasta que retires la etiqueta.

Si aprendiste DMARC antes de 2026, contrasta tu registro con la especificación vigente. DMARC se revisó en mayo de 2026 y se publicó como RFC 9989 (protocolo), RFC 9990 (informes agregados) y RFC 9991 (informes de fallo), que en conjunto dejan obsoleto RFC 7489 y elevan DMARC a protocolo del proceso de estándares. La revisión eliminó las etiquetas pct, rf y ri (t sustituye aquello para lo que se usaba pct) y pasó p de obligatoria a recomendada. Si falta p o p, sp o np no son válidas, el receptor solo continúa como p=none cuando hay un rua válido; de lo contrario no procesa DMARC. Los registros v=DMARC1 existentes siguen funcionando: los receptores ignoran las etiquetas eliminadas en lugar de rechazar el registro. Límpialas en tu próxima edición del DNS.

Todo junto: cómo se juzga un mensaje

Para un mensaje entrante, un receptor hace aproximadamente esto:

1. Lee el dominio de la cabecera From. Todo lo demás se mide contra él.
2. Evalúa SPF sobre el dominio del remitente del sobre frente a la IP que se conecta. Anota si pasa o falla y qué dominio se comprobó.
3. Verifica las firmas DKIM que haya. Anota si pasan o fallan y el d= de cada una.
4. Comprueba la alineación. ¿Coincide con el dominio de From el dominio comprobado por SPF? ¿Coincide algún d= que haya pasado?
5. Cualquier pass alineado → DMARC pasa. El uso del dominio queda autenticado; la entrega y el filtrado habituales siguen dependiendo de las reglas del receptor.
6. Ningún pass alineado → DMARC falla. Consulta la política p solicitada por el remitente (o sp/np). Con t=y se espera un escalón más suave, pero el receptor decide el tratamiento final.

En el paso 4 viven las sorpresas, y ahí se explica el resultado que hace pensar en un fallo del sistema: que aparezcan spf=pass y dmarc=fail a la vez no es una contradicción. Es la firma habitual del correo enviado a través de un proveedor al que nunca se le configuró la alineación: el remitente del sobre es el dominio de rebotes del proveedor, SPF pasa en ese dominio y nada lo ata a tu cabecera From. Se arregla configurando en ese proveedor la firma DKIM con d=tudominio.com, que es lo que busca la mitad alineada de la comprobación.

Leer tu propia configuración

Hay dos direcciones que conviene revisar, y cada una pide pruebas distintas.

Hacia fuera: lo que publicas. Los tres registros son DNS público, así que puede leerlos cualquiera, tú incluido. Pasa tu dominio por el comprobador de SPF y DMARC: despliega el árbol SPF frente al presupuesto de diez consultas, lee el registro DMARC etiqueta a etiqueta, verifica que las direcciones de informe externas te hayan autorizado a enviarles y sondea selectores DKIM habituales. Para los registros en crudo, sin interpretar, la herramienta de consulta DNS consulta el TXT de tudominio.com y de _dmarc.tudominio.com directamente.

Hacia dentro: qué le pasó de verdad a un mensaje. Un registro publicado te dice la regla, no el veredicto sobre un correo concreto. Eso está en las cabeceras, donde el servidor receptor anota lo que encontró:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.provider.com;
  dkim=pass header.d=tuempresa.com;
  dmarc=pass header.from=tuempresa.com

Léelo con calma y el modelo entero queda a la vista en un solo sitio: SPF pasó en el dominio del proveedor, DKIM pasó en el tuyo, y como el d= de DKIM se alinea con header.from, DMARC pasa. Guarda cualquier mensaje como código fuente y pega las cabeceras en el analizador de cabeceras de correo para obtener este desglose: funciona por completo en tu navegador, así que el mensaje no sale de tu equipo. Para el recorrido completo, incluida la cadena Received y las marcas de un remitente falso, mira cómo leer las cabeceras de un correo.

La versión corta

• SPF responde a «¿puede esta IP enviar por este dominio?». Se comprueba contra el remitente del sobre, invisible para los destinatarios, con un tope de diez consultas DNS, y se rompe con el reenvío.
• DKIM responde a «¿firmó este mensaje una clave que publicó este dominio?». Viaja con el mensaje, aguanta el reenvío, se rompe con las modificaciones y sus selectores no se pueden enumerar.
• DMARC responde a «¿pertenece ese pass de SPF o DKIM al dominio que ve realmente quien lee?». Eso es la alineación, y es el único de los tres que protege la cabecera From. Además indica a los receptores qué hacer ante un fallo y te manda informes.

Necesitas los tres, y los necesitas alineados. SPF y DKIM sin DMARC autentican direcciones que nadie mira; DMARC sin un SPF o un DKIM que pase y esté alineado no hace más que rechazar tu propio correo.

Una vez encajan las piezas, la siguiente pregunta es operativa: cómo pasar de una política que no hace nada a p=reject sin mandar tus propias facturas a un agujero negro por el camino. Eso es un problema de despliegue más que de protocolo, y pasar de p=none a p=reject es la respuesta escalonada a esa pregunta.