DKIM frente a SPF frente a DMARC no es una elección entre alternativas: los tres estándares responden a preguntas distintas y solo funcionan en conjunto. SPF enumera qué servidores pueden enviar correo en nombre del dominio del sobre; DKIM añade una firma hecha con una clave publicada bajo un dominio; DMARC exige que al menos uno de los dos pase la comprobación para un dominio que coincida con la dirección From: visible, y publica la política del propietario del dominio y las direcciones a las que se envían los informes.
De un vistazo
| SPF | DKIM | DMARC | |
|---|---|---|---|
| Especificación | RFC 7208 (2014) | RFC 6376 (2011), RFC 8301, RFC 8463 | RFC 9989, 9990, 9991 (mayo de 2026), que sustituyen al RFC 7489 |
| Pregunta que responde | ¿Puede esta IP enviar en nombre del dominio del sobre? | ¿Firmó este dominio este contenido, sin modificaciones? | ¿Coincide un dominio autenticado con el dominio de From:, y qué pasa si no? |
| Identidad comprobada | MAIL FROM (Return-Path) y HELO | El dominio d= de DKIM-Signature | El dominio del encabezado From: |
| Dónde se publica | TXT en el dominio | TXT en selector._domainkey.domain | TXT en _dmarc.domain |
| Sobrevive al reenvío simple | No (la IP del reenviador no figura en la lista) | Sí, si el mensaje no se modifica | Sí, a través de DKIM |
| Sobrevive a las listas de correo que editan los mensajes | No | No (cambian el cuerpo o los encabezados firmados) | Solo si la lista reescribe From: o el receptor confía en ARC |
| Límites estrictos | 10 términos que consultan el DNS por evaluación, 2 consultas vacías (void lookups) | RSA de al menos 1024 bits (se recomiendan 2048); rsa-sha1 prohibido | Recorrido del árbol DNS de 8 consultas como máximo |
| Efecto por sí solo | Solo un resultado; deciden los receptores | Solo un resultado; deciden los receptores | Política del propietario del dominio: none, quarantine, reject |
| Informes | Ninguno | Ninguno | Informes agregados en XML (rua), informes de fallos (ruf) |
Cómo funciona cada uno
SPF se evalúa durante la sesión SMTP: el receptor toma el dominio del remitente del sobre (o el de HELO en el caso de los rebotes), obtiene su registro TXT y comprueba si la IP que se conecta coincide con los términos ip4, ip6, a, mx e include de la lista. El resultado es pass, fail (-all), softfail (~all), neutral, none o un error. Cada include, a, mx, ptr, exists y redirect cuesta una consulta DNS, y más de 10 hacen que el resultado sea permerror (RFC 7208 §4.6.4), lo que rompe SPF para todo el correo del dominio.
DKIM calcula el hash del cuerpo canonicalizado (bh=) y de los encabezados indicados (h=) y los firma con la clave privada del dominio. El receptor obtiene la clave pública de un registro TXT cuyo nombre se forma con el selector s= y el dominio d= (por ejemplo, google._domainkey.github.com) y verifica la firma. El RFC 8301 prohíbe rsa-sha1 y exige claves de al menos 1024 bits; el RFC 8463 añade ed25519-sha256, que suele publicarse junto a una firma RSA porque la compatibilidad de los verificadores es incompleta.
DMARC se ejecuta después de ambos: pasa cuando SPF pasa para un dominio alineado con From: o cuando una firma DKIM se verifica para un dominio alineado con From:. La alineación es relajada por defecto (mismo dominio organizativo, de modo que mail.example.com queda alineado con example.com) o estricta con aspf=s y adkim=s.
El siguiente script lee registros reales (20 de octubre de 2026, dig 9.10.6 y OpenSSL 3.6.5).
echo "== SPF: google.com and its include"
dig +short TXT google.com | grep "v=spf1"
dig +short TXT _spf.google.com
echo "== DMARC: google.com and github.com"
dig +short TXT _dmarc.google.com
dig +short TXT _dmarc.github.com
echo "== DKIM: key size behind two github.com selectors"
for sel in google pf2023; do
printf '%s: ' "$sel"
dig +short TXT "$sel._domainkey.github.com" | tr -d '" \n' | sed 's/.*p=//' \
| openssl base64 -d -A | openssl pkey -pubin -inform DER -noout -text | head -1
done
== SPF: google.com and its include
"v=spf1 include:_spf.google.com ~all"
"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"
== DMARC: google.com and github.com
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
"v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1"
== DKIM: key size behind two github.com selectors
google: Public-Key: (2048 bit)
pf2023: Public-Key: (1024 bit)
Merece la pena fijarse en tres detalles. El SPF de Google termina en ~all (softfail), mientras que su política DMARC es reject: cuando DMARC se aplica, decide el resultado de DMARC, así que el calificador de SPF importa poco. GitHub todavía publica pct=100, una etiqueta que el RFC 9989 eliminó; los receptores ignoran las etiquetas desconocidas y 100 era el valor predeterminado, así que no hace ningún daño. Y uno de los selectores de GitHub todavía usa una clave de 1024 bits, el mínimo que permite el RFC 8301. El analizador de autenticación de correo ejecuta las mismas comprobaciones para cualquier dominio.
La alineación decide el resultado
La tabla muestra flujos habituales para un mensaje con From: news@example.com.
| Flujo | SPF | DKIM | DMARC |
|---|---|---|---|
Tu propio servidor, que firma como example.com | pass, alineado | pass, alineado | pass |
Proveedor de servicios de correo con su propio dominio de rebote, que firma como example.com | pass para el dominio del proveedor, no alineado | pass, alineado | pass (DKIM) |
| Proveedor que firma solo con su propio dominio | pass, no alineado | pass, no alineado | fail |
| Reenviado sin cambios por una regla del buzón | fail (IP del reenviador) | pass, alineado | pass (DKIM) |
| La lista de correo añade un pie de página o una etiqueta en el asunto | fail o no alineado | fail (hash del cuerpo) | fail, salvo que se reescriba From: o se confíe en ARC |
From: suplantado desde el servidor de otra persona | fail o none | none | fail, se aplica la política |
La tercera fila es el error de despliegue más común: un remitente pasa SPF y DKIM, pero falla DMARC porque ninguno de los dominios autenticados es tuyo. Configura cada proveedor para que firme con una clave bajo tu dominio (normalmente, un CNAME que apunta a la clave del proveedor) y usa un dominio de rebote personalizado si también quieres que SPF quede alineado.
Reenvío, listas de correo y ARC
SPF autentica el último salto, así que cualquier reenvío lo rompe; los esquemas de reescritura del remitente (Sender Rewriting Scheme) arreglan SPF para el propio dominio del reenviador, pero nunca lo alinean. DKIM autentica el contenido, así que sobrevive a los servidores intermedios que no tocan el mensaje y falla cuando las listas añaden pies de página o etiquetas. ARC (RFC 8617, experimental) permite que un intermediario selle los resultados de autenticación que vio, y los receptores que confían en ese sellador pueden aceptar el mensaje pese al fallo de DMARC; el visor de cadenas ARC muestra la cadena. La debilidad que queda es la repetición de DKIM (DKIM replay): un mensaje con una firma válida puede volver a enviarse a destinatarios nuevos, un problema que un grupo de trabajo del IETF aborda en sus borradores de DKIM2.
Qué exigen los proveedores de correo
Desde el 1 de febrero de 2024, Gmail exige a todos los remitentes usar SPF o DKIM, DNS directo e inverso válidos, TLS y una tasa de spam notificada inferior al 0,3 %. Los remitentes de 5000 o más mensajes al día a cuentas personales de Gmail necesitan además SPF y DKIM, un registro DMARC (basta con p=none), un From: alineado con SPF o DKIM y la opción de darse de baja con un clic (RFC 8058) en el correo de marketing. Yahoo introdujo normas equivalentes al mismo tiempo. Microsoft aplicó los mismos umbrales a Outlook.com a partir del 5 de mayo de 2025 y rechaza con 550 5.7.515 el correo que no los cumple. Los logotipos BIMI exigen además DMARC en quarantine o reject.
El RFC 9989 (mayo de 2026) llevó DMARC al Standards Track (la vía de estándares) y cambió el registro: pct, rf y ri desaparecen, t=y sustituye a pct=0 para las pruebas, np fija una política para los subdominios inexistentes, psd marca los dominios de sufijo público y un recorrido del árbol DNS sustituye a la Public Suffix List para encontrar el dominio organizativo.
Para qué sirve cada uno
- SPF: autoriza tus propios servidores de salida y los proveedores que usan tu dominio como dirección de rebote; publica
v=spf1 -allen los dominios y subdominios que nunca envían correo. - DKIM: firma todo el correo saliente con tu propio dominio, incluido el que se envía a través de proveedores; rota los selectores al menos una vez al año y sustituye las claves de 1024 bits por claves de 2048 bits.
- DMARC: primero recopila informes y después aplica la política; añade
np=reject(osp=reject) para que los atacantes no puedan usar subdominios inventados. - Dominios aparcados:
v=spf1 -all,v=DMARC1; p=reject;y ningún selector DKIM. - La protección del transporte y la del contenido son problemas distintos: usa MTA-STS para TLS entre servidores y S/MIME u OpenPGP para la firma de extremo a extremo.
Notas de migración
- Haz inventario de los remitentes con los informes agregados de DMARC en
p=nonedurante 2 a 4 semanas; cada fuente legítima debe mostrar DKIM alineado, SPF alineado o ambos. - Arregla DKIM primero: activa la firma con dominio propio en cada proveedor, publica claves de 2048 bits (el generador de registros DKIM las divide en cadenas de 255 caracteres) y verifica con el depurador de DKIM.
- Recorta SPF por debajo de 10 consultas eliminando los mecanismos include que no se usan; aplánalo en rangos de IP solo si puedes mantenerlos actualizados de forma automática.
- Aplica la política de forma gradual:
p=quarantinecont=ypara observar, despuésp=quarantiney despuésp=reject; mantén el flujo de informesrua. - Protege los subdominios con
sponpy publica registros nulos en todos los dominios que no deban enviar correo.
Referencias
- RFC 7208, SPF (§4.6.4, límites de consultas)
- RFC 6376, DKIM, RFC 8301, actualización criptográfica de DKIM, RFC 8463, Ed25519 para DKIM
- RFC 9989, DMARC, RFC 9990, informes agregados, RFC 9991, informes de fallos
- RFC 8617, ARC
- RFC 8058, baja con un clic
- Google: directrices para remitentes de correo
- Microsoft: refuerzo de los requisitos del ecosistema de correo para remitentes de gran volumen