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

SPF dice qué servidores pueden enviar correo por tu dominio. DKIM firma cada mensaje para que los receptores puedan comprobar qué dominio lo envió y que no se modificó en el camino. DMARC une ambos a la dirección From que la gente realmente ve: un mensaje pasa DMARC solo si SPF o DKIM pasa para un dominio que coincide con el dominio del From, y el registro DMARC les dice a los receptores qué hacer cuando no es así.

Puedes revisar los tres para cualquier dominio ahora mismo con nuestro verificador de SPF, verificador de DKIM y verificador de DMARC, todos gratuitos. El resto de esta guía explica qué leen esas herramientas y por qué importa cada resultado.

La versión corta en una tabla

	SPF	DKIM	DMARC
Estándar	RFC 7208 (2014)	RFC 6376 (2011)	RFC 7489 (2015), reemplazado por el RFC 9989 (mayo de 2026)
Qué comprueba	El remitente del sobre (MAIL FROM) y el nombre HELO	Una firma en el encabezado DKIM-Signature	Que SPF o DKIM pasó para el dominio del From
Dónde vive	Registro TXT en example.com	Registro TXT en selector._domainkey.example.com	Registro TXT en _dmarc.example.com
Sobrevive al reenvío	Normalmente no	Sí, si el mensaje no se modifica	Sí, a través de DKIM
Les dice a los receptores qué hacer	Solo débilmente (-all vs. ~all)	No	Sí: none, quarantine o reject

Existen tres registros porque cada uno, por sí solo, deja un hueco. SPF y DKIM autentican un dominio, pero no necesariamente el de la línea From. DMARC cierra ese hueco.

SPF: quién puede enviar

SPF es una lista de servidores autorizados a enviar correo usando tu dominio en el remitente del sobre. El servidor receptor busca el registro TXT del dominio que aparece en el comando MAIL FROM (la dirección a la que van los rebotes, que a menudo se muestra como Return-Path) y comprueba si la IP que se conecta está en la lista. El RFC 7208 también permite comprobar el nombre HELO.

Un registro típico para una empresa en Google Workspace que además envía boletines a través de una plataforma de marketing:

example.com.  TXT  "v=spf1 include:_spf.google.com include:spf.esp-example.net -all"

De izquierda a derecha:

• v=spf1 identifica el registro como SPF. Solo puede haber un registro así por dominio.
• include: incorpora la lista SPF de otro dominio, aquí la de Google y la de la plataforma de correo.
• -all significa que todo lo que no esté en la lista debe fallar (fail). ~all significa softfail: sospechoso, pero no rechazar solo por SPF. ?all es neutral y casi no les da información a los receptores.

Dos límites hacen tropezar a mucha gente. La sección 4.6.4 del RFC 7208 dice que las implementaciones "MUST limit the total number" (DEBEN limitar el número total) de términos que consultan el DNS (include, a, mx, ptr, exists y redirect) a 10, y superarlo es un error permanente. También dice que las consultas que no devuelven nada, llamadas "void lookups" (consultas vacías), DEBERÍAN limitarse a dos. Si con los años fuiste acumulando includes, nuestro ejemplo práctico sobre cómo resolver el exceso de consultas DNS muestra cómo volver por debajo del límite, y los errores comunes de SPF cubre el resto.

Lo que SPF no puede hacer: no dice nada sobre la dirección From que ve el lector. Un spammer puede usar su propio dominio en MAIL FROM, pasar SPF para ese dominio y poner tu dominio en el encabezado From. Y cuando un mensaje se reenvía, la IP del servidor que reenvía no está en tu registro, así que SPF normalmente falla.

DKIM: una firma que viaja con el mensaje

DKIM agrega una firma criptográfica a cada mensaje. El servidor que envía firma ciertos encabezados y el cuerpo con una clave privada, y añade un encabezado DKIM-Signature. Dos etiquetas de ese encabezado son las más importantes para entenderlo:

• d= es el dominio firmante, el dominio que se hace responsable del mensaje.
• s= es el selector, que le dice al receptor dónde encontrar la clave pública.

El receptor obtiene la clave pública del DNS en selector._domainkey.domain, por ejemplo:

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

v=DKIM1 es la versión, k=rsa el tipo de clave y p= la clave pública en sí (recortada aquí). Si la firma se verifica, el receptor sabe que el dominio d= firmó el mensaje y que las partes firmadas no se alteraron. Un p= vacío significa que la clave fue revocada.

Como la firma vive dentro del mensaje, DKIM sobrevive al reenvío normal. Se rompe cuando un intermediario cambia contenido firmado, algo que suelen hacer las listas de correo que agregan pies de página o etiquetas en el asunto.

La longitud de la clave importa. El RFC 8301 dice que los firmantes "MUST use RSA keys of at least 1024 bits" (DEBEN usar claves RSA de al menos 1024 bits) y "SHOULD use RSA keys of at least 2048 bits" (DEBERÍAN usar claves RSA de al menos 2048 bits). Nuestro estudio sobre la longitud de las claves DKIM midió cuántos dominios siguen usando claves de 1024 bits. El verificador de DKIM encuentra automáticamente los selectores comunes y decodifica la longitud de la clave. Aquí están las guías de configuración para las dos plataformas más grandes: Google Workspace y Microsoft 365.

Lo que DKIM no puede hacer: igual que SPF, autentica el dominio d=, que puede ser cualquier dominio. Un mensaje firmado por d=bulk-sender.net con From: you@example.com pasa DKIM, pero no demuestra nada sobre example.com.

DMARC: unir ambos a la dirección From

DMARC responde la pregunta que los otros dos dejan abierta: ¿este mensaje vino realmente del dominio del encabezado From? Un mensaje pasa DMARC cuando se cumple cualquiera de estas condiciones:

1. SPF pasa y el dominio de MAIL FROM está alineado con el dominio del From, o
2. DKIM pasa y el dominio d= está alineado con el dominio del From.

Basta con un resultado positivo alineado. Tanto el RFC 7489 como el RFC 9989 lo definen así.

Cómo funciona la alineación

La alineación tiene dos modos, que se configuran por separado para SPF (aspf) y DKIM (adkim):

• Relajado (r, el predeterminado): los dos dominios comparten el mismo dominio organizativo. bounces.example.com se alinea con example.com.
• Estricto (s): los dos dominios deben ser idénticos.

Así se ve en un boletín enviado a través de una plataforma externa:

Encabezado	Valor	Resultado
From	news@example.com	El dominio que protege DMARC
MAIL FROM	bounce-123@mail.platform.net	SPF pasa para platform.net, no alineado
DKIM d=	example.com (DKIM personalizado configurado)	DKIM pasa, alineado
DMARC		Pasa, a través de DKIM

Si quitas el DKIM personalizado, la plataforma firma con su propio dominio. Ahora SPF y DKIM pasan, ninguno está alineado y DMARC falla. Es la falla de DMARC más común en dominios pequeños: en los encabezados todo "pasa" y aun así el mensaje falla. Nuestra guía para leer los encabezados de un correo muestra dónde encontrar cada uno de estos valores.

El registro DMARC

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

• v=DMARC1 debe ir primero.
• p= es la política para el correo que falla: none (solo monitorear), quarantine (tratarlo como sospechoso, normalmente a la carpeta de spam) o reject (rechazarlo).
• rua= es adonde los receptores envían los informes agregados diarios, que muestran cada fuente que envía en nombre de tu dominio y si pasó.

p=none no cambia nada en la entrega. Existe para que puedas recopilar informes y corregir a los remitentes legítimos antes de aplicar la política. Nuestros ejemplos comentados de registros DMARC cubren las demás etiquetas, y cómo pasar de p=none a p=reject cubre la implementación.

Qué cambió en 2026

El RFC 9989, publicado en mayo de 2026, reemplazó al RFC 7489 como estándar de DMARC. Pasó DMARC de Informational a Standards Track, eliminó las etiquetas pct, rf y ri, añadió una etiqueta t para el modo de prueba y una etiqueta psd, e incorporó la etiqueta np para subdominios inexistentes. También sustituye la dependencia de la Public Suffix List por un "DNS Tree Walk" (recorrido del árbol DNS) para encontrar el dominio organizativo. Para la mayoría de los dueños de dominios el cambio práctico es pequeño: los registros con pct siguen funcionando en los receptores que no se han actualizado, y el nuevo enfoque de prueba se explica en la guía de implementación enlazada arriba.

Qué exigen Gmail, Yahoo y Microsoft

Los tres grandes proveedores de buzones publican hoy reglas de autenticación, leídas en sus propias páginas en octubre de 2026:

Proveedor	Todos los remitentes	Remitentes masivos
Gmail	"Set up SPF or DKIM" (configura SPF o DKIM)	SPF y DKIM; registro DMARC, se acepta p=none; From alineado con el dominio de SPF o DKIM (unos 5000 mensajes o más al día a cuentas personales de Gmail)
Yahoo	"Implement SPF or DKIM at a minimum" (implementa como mínimo SPF o DKIM)	SPF y DKIM; "a valid DMARC policy with at least p=none" (una política DMARC válida con al menos p=none) y DMARC debe pasar; se acepta la alineación relajada
Outlook.com	No se especifica	Más de 5000 correos al día: SPF debe pasar, DKIM debe pasar, DMARC al menos p=none alineado con SPF o DKIM

Fíjate en la redacción de Microsoft. DMARC en sí se cumple con un solo resultado positivo alineado, pero las reglas de alto volumen de Microsoft piden que pasen tanto SPF como DKIM. Un dominio que solo pasa DMARC a través de DKIM cumple la regla de Gmail y puede no cumplir la de Microsoft. Los detalles están en los requisitos de Gmail y Yahoo y en los requisitos de Outlook.

Cómo revisar tu propio dominio en cinco minutos

1. SPF. Pasa tu dominio por el verificador de SPF. Quieres exactamente un registro v=spf1, todos los servicios que envían por ti incluidos, 10 consultas DNS o menos y un final -all o ~all.
2. DKIM. Pasa el verificador de DKIM. Quieres una clave válida para cada plataforma que envía como tu dominio, de 2048 bits donde la plataforma lo permita. Si no encuentra una plataforma, busca su selector en su documentación de configuración.
3. DMARC. Pasa el verificador de DMARC. Quieres un registro en _dmarc, una política y una dirección rua que alguien lea de verdad. Si no tienes registro, el generador de DMARC te crea uno.
4. Alineación. Envía un mensaje desde cada plataforma a una dirección de Gmail, abre "Mostrar original" y confirma que SPF o DKIM pasa para tu propio dominio, no para el de la plataforma.
5. Revisa los informes. Los informes agregados mostrarán remitentes que habías olvidado, como un sistema de facturación o un CRM, antes de que pases a aplicar la política.

Los tres registros son baratos de publicar y solo valen algo juntos. SPF y DKIM demuestran que algún dominio envió un mensaje; DMARC es lo que hace que ese dominio sea el tuyo.