SPF, DKIM y DMARC: la guía definitiva para que tu correo no acabe en spam

El problema de origen: SMTP no autentica a nadie

El protocolo SMTP se diseñó en 1982 sobre una premisa que hoy resulta ingenua: todos los servidores de la red son de confianza. En SMTP puro, cualquier máquina de internet puede conectarse al servidor de correo de un banco y presentar un mensaje que dice venir de facturacion@tubanco.com. No hay contraseña, no hay firma, no hay verificación. Esa es la razón de que el phishing siga siendo el vector de entrada de la mayoría de incidentes de seguridad corporativos.

SPF, DKIM y DMARC son tres capas añadidas a posteriori, en forma de registros DNS, que resuelven tres preguntas distintas:

SPF: ¿esta IP tiene permiso para enviar correo en nombre de este dominio?
DKIM: ¿el mensaje llegó intacto y firmado por quien controla el dominio?
DMARC: si SPF o DKIM fallan, ¿qué hago con el mensaje, y coincide el dominio con el que ve el usuario?

Desde febrero de 2024 Gmail y Yahoo exigen autenticación a cualquier remitente con volumen relevante, y Microsoft ha aplicado requisitos equivalentes. Ya no es una buena práctica opcional: sin estos registros, tu correo transaccional simplemente no llega.

SPF: la lista de remitentes autorizados

SPF (RFC 7208) es un registro TXT en el dominio raíz que enumera los orígenes autorizados:


v=spf1 mx ip4:203.0.113.10 include:_spf.google.com -all

Los mecanismos se evalúan de izquierda a derecha:

ip4: / ip6: autorizan direcciones o rangos concretos.
a autoriza las IPs del registro A del dominio.
mx autoriza los servidores que reciben tu correo (habitual, porque muchos también envían).
include: delega en la política de un tercero: Google Workspace, Microsoft 365, SendGrid, Mailgun.
El mecanismo final define qué pasa con todo lo demás: -all es fail (rechazar), ~all es softfail (aceptar marcando) y ?all es neutral, es decir, ninguna protección.

Los dos errores que rompen SPF en producción

Dos registros SPF. Solo puede existir un TXT que empiece por v=spf1 en un dominio. Si añades uno nuevo al contratar un proveedor de mailing en lugar de fusionar los includes en el existente, el resultado es permerror y la autenticación falla entera. Es el fallo más frecuente en migraciones.

Más de 10 consultas DNS. Los mecanismos include, a, mx, ptr y exists requieren resolución DNS, y el RFC limita el total a 10 —contando las cadenas anidadas de tus proveedores—. Un dominio con Google Workspace, un CRM, una herramienta de facturación y un servicio de newsletter se pasa del límite con facilidad. Soluciones: sustituir includes por rangos ip4: cuando el proveedor los publique de forma estable, o usar aplanamiento (flattening) automatizado con revisión periódica.

DKIM: firma criptográfica del mensaje

DKIM (RFC 6376) actúa sobre el mensaje, no sobre la IP. El servidor de salida firma un conjunto de cabeceras (From, Subject, Date, To…) y un hash del cuerpo con una clave privada, y añade una cabecera DKIM-Signature. La clave pública se publica en DNS:


mail._domainkey.ejemplo.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO..."

La parte mail es el selector, y es lo que permite convivir varias claves a la vez: cada proveedor usa el suyo (google, s1, k1, selector1). El receptor lee el selector de la cabecera de firma, busca la clave pública correspondiente y recalcula el hash.

La gran ventaja de DKIM sobre SPF es que sobrevive al reenvío. Cuando una lista de correo o un reenvío automático retransmite tu mensaje, la IP de salida cambia y SPF falla; la firma DKIM, si el intermediario no altera las cabeceras firmadas, sigue siendo válida.

Buenas prácticas: claves RSA de 2048 bits (1024 se considera débil), rotación al menos anual publicando un selector nuevo antes de retirar el viejo, y no firmar cabeceras que los intermediarios reescriben habitualmente.

DMARC: la política y la alineación

Aquí está la pieza que da sentido a las dos anteriores. Un atacante puede publicar un SPF válido para su dominio y enviarte correo que pasa SPF... mostrando From: soporte@tubanco.com en el cliente de correo. SPF valida el remitente del sobre (Return-Path), no el que ve el usuario.

DMARC (RFC 7489) cierra ese hueco exigiendo alineación: el dominio del From: visible debe coincidir con el dominio que autenticó SPF o DKIM. Y define qué hacer si no coincide:


_dmarc.ejemplo.com. IN TXT "v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc@ejemplo.com; adkim=r; aspf=r; fo=1"

p: política para el dominio (none, quarantine, reject); sp hace lo mismo con los subdominios.
pct: porcentaje de mensajes a los que se aplica la política, útil para desplegar de forma gradual.
rua: destino de los informes agregados XML diarios (los envían Google, Microsoft, Yahoo y casi todos los grandes).
adkim / aspf: alineación relajada (r, basta el dominio organizativo) o estricta (s, coincidencia exacta).

Plan de despliegue en cuatro fases

1. Inventario. Lista todo lo que envía correo con tu dominio: servidor propio, Workspace/365, CRM, ERP, facturación, formularios web, monitorización, herramientas de marketing. Casi siempre aparecen dos o tres olvidados. 2. SPF y DKIM. Publica el SPF unificado y activa la firma DKIM en cada proveedor. Verifica con un envío a Gmail: en Mostrar original deben aparecer PASS en SPF y DKIM y dmarc=pass cuando llegue la fase 3. 3. DMARC en modo observación. Publica p=none; rua=mailto:... y deja pasar dos o tres semanas. Los informes agregados delatan los orígenes legítimos que se te habían escapado y los intentos de suplantación. 4. Endurecimiento progresivo. p=quarantine; pct=25 → 50 → 100 → p=reject. Sin prisa, revisando informes entre cada salto.

No te olvides de los dominios que no envían correo

Los dominios aparcados, las variantes defensivas de tu marca y los subdominios sin uso son el objetivo favorito de los suplantadores porque nadie los vigila. Blíndalos con dos registros:


ejemplo-parked.com.        IN TXT "v=spf1 -all"
_dmarc.ejemplo-parked.com. IN TXT "v=DMARC1; p=reject; sp=reject;"

BIMI y el siguiente paso

Con DMARC en p=reject se abre la puerta a BIMI, el estándar que muestra el logotipo verificado de tu marca junto al mensaje en Gmail y Apple Mail. Requiere además un certificado VMC de una autoridad reconocida, pero es la mejor recompensa visible de haber hecho los deberes de autenticación.

Genera los tres registros ya formateados con nuestro generador de SPF, DKIM y DMARC, y si necesitas emitir claves o certificados relacionados, el generador de comandos OpenSSL y el generador de CSR te dan las órdenes exactas.