SPF, DKIM y DMARC: qué son, cómo configurarlos y por qué tu dominio los necesita

SPF, DKIM y DMARC son tres registros DNS que permiten al servidor que recibe un correo comprobar que lo enviaste tú. SPF lista los servidores autorizados, DKIM firma cada mensaje y DMARC indica qué hacer con lo que no supera ninguna de las dos y te envía informes. Sin ellos, cualquiera puede suplantar tu dominio.

Para comprobarlo en tu web: Auditoría SEO

No son un factor de posicionamiento, pero forman parte de la categoría de seguridad y confianza del posicionamiento web: protegen la marca que el SEO trabaja para dar a conocer.

¿Qué tiene que ver el correo con tu web?

Más de lo que parece. Google, en sus normas para remitentes, recomienda configurar siempre la autenticación del correo para el dominio que aloja tu web pública1. Hay dos motivos prácticos:

• Suplantación. Si tu dominio no publica DMARC, un estafador puede enviar correos con tu dirección en el remitente y no hay ninguna política que pida al receptor rechazarlos. Tus clientes ven tu nombre, no el suyo.
• Entregabilidad. Los avisos del formulario de contacto, las facturas, los restablecimientos de contraseña y las newsletters salen con tu dominio. Gmail dice que los mensajes no autenticados pueden ir a spam o ser rechazados1.

Lo que no hacen es mejorar tus posiciones: ninguna documentación de Google los cita como señal de búsqueda.

SPF: qué servidores pueden enviar en tu nombre

SPF (Sender Policy Framework) es un registro TXT en la raíz del dominio que enumera los servidores autorizados a enviar correo con él. El receptor lo comprueba contra el dominio del sobre del mensaje (el Return-Path), no contra el remitente que ve el usuario2. Un ejemplo para un dominio que envía desde su proveedor de correo y desde una herramienta de newsletters:

; Registro TXT en example.com (el nombre de los proveedores es ilustrativo)
example.com.  IN TXT  "v=spf1 include:_spf.proveedor-correo.example include:envios.newsletter.example -all"
;  v=spf1        -> versión; sin esto el registro se ignora
;  include:...   -> autoriza los servidores que publica cada proveedor (cada include cuenta como una consulta)
;  -all          -> todo lo demás falla; ~all sería «probablemente no autorizado» (softfail)

Dos reglas que se incumplen a menudo. Un dominio solo puede tener un registro SPF: si hay dos, la comprobación da error permanente2. Y cada herramienta nueva que envía correo (el CRM, la tienda, la plataforma de facturas) tiene que entrar en ese único registro.

El límite de 10 consultas DNS

SPF limita a 10 los mecanismos que obligan a hacer una consulta DNS durante la evaluación: include, a, mx, ptr, exists y el modificador redirect. Si se superan, el resultado es permerror y el SPF deja de servir. Las consultas que vuelven vacías (las void lookups) se recomienda limitarlas a dos2.

El límite cuenta los include anidados: si el registro de tu proveedor incluye a su vez otros tres, gastas cuatro. Para quedarte por debajo, borra los proveedores que ya no usas, evita ptr y sustituye a y mx por rangos ip4: o ip6: cuando sepas las direcciones, porque no cuentan.

DKIM: la firma de cada mensaje

DKIM (DomainKeys Identified Mail) añade a cada correo una firma criptográfica que el receptor verifica con una clave pública publicada en el DNS. La clave vive en un subdominio con la forma selector._domainkey.example.com, y el selector lo elige quien firma: puede haber varios a la vez, uno por proveedor o por periodo3.

; Clave pública DKIM para el selector «s2026» (la clave real es mucho más larga)
s2026._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

Google exige claves de al menos 1.024 bits para enviar a cuentas personales de Gmail y recomienda 2.048 si tu proveedor lo permite1. En la práctica, cada servicio que envía por ti te da el registro que tienes que publicar.

Por qué DKIM no se puede comprobar desde fuera

Para leer una clave DKIM hay que saber su selector, y el selector solo aparece en la firma de un mensaje (la etiqueta s= de la cabecera DKIM-Signature). El DNS no ofrece una lista de los subdominios bajo _domainkey, así que, sin un correo tuyo delante, nadie puede saber si tienes DKIM ni con qué selector. Por eso las herramientas que analizan una web desde fuera comprueban SPF y DMARC, que están en nombres fijos, y no DKIM.

DMARC: la política y los informes

DMARC es un registro TXT en _dmarc.example.com que dice qué debe hacer el receptor con los correos que fallan la validación y adónde enviar los informes. En mayo de 2026 la IETF publicó la nueva especificación, el RFC 9989, que sustituye al RFC 74894.

; Registro TXT en _dmarc.example.com
_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:informes-dmarc@example.com"
;  p=none     -> solo observar: no pide ningún trato a lo que falla
;  rua=...    -> buzón donde recibes los informes agregados
;  adkim/aspf -> alineación; si no se indican, es relajada (r)
;  sp / np    -> política para subdominios y para subdominios que no existen

Alineación: la condición que más falla

Un correo supera DMARC si pasa SPF o DKIM y el dominio validado coincide con el del remitente visible (el From:). En modo relajado, el que se aplica por defecto, basta con que compartan el dominio organizativo: envios.example.com se alinea con example.com; en modo estricto tienen que ser idénticos4.

El fallo típico: una herramienta de newsletters envía con su propio dominio en el sobre y firma con el suyo. SPF y DKIM pasan, pero para el dominio del proveedor, no para el tuyo, y DMARC falla. La solución es configurar en la herramienta tu dominio de envío y tu propia firma DKIM.

De p=none a quarantine y reject

El RFC explica por qué se empieza en p=none: en casi cualquier organización se olvida algún servidor o algún proveedor que envía en su nombre, y los informes sirven para encontrarlos antes de aplicar la política4. Pero p=none no protege de la suplantación: es una fase, no un destino. El antiguo pct, que aplicaba la política a un porcentaje de mensajes, desaparece en el RFC 9989; para probar una política se usa ahora t=y, que pide aplicar un escalón menos4.

Los informes rua

Los receptores que envían informes agregados deberían hacerlo al menos una vez cada 24 horas4. Llegan en XML y dicen cuántos correos con tu dominio han visto, desde qué IP y si pasaron SPF, DKIM y la alineación. Están pensados para leerlos con un programa, así que lo habitual es usar un servicio que los resuma. En ellos aparecen tanto tus envíos mal configurados como los intentos de suplantación.

¿Qué exigen Gmail, Yahoo y Outlook?

Microsoft anunció primero que mandaría esos correos a la carpeta de no deseado y, antes de la fecha, cambió de criterio y decidió rechazarlos6. Si envías muchos menos de 5.000 correos al día, las normas para remitentes masivos no te obligan, aunque Gmail sí pide a todos SPF o DKIM y cumplir el resto mejora la entrega igualmente.

¿Por qué proteger un dominio que no envía correo?

Porque es el más fácil de suplantar. Si un dominio no tiene SPF ni DMARC, nada indica a los receptores que los correos que dicen venir de él son falsos. Pasa con los dominios aparcados, los de campañas antiguas o las variantes que compraste para protegerte. La guía del Gobierno británico recomienda publicar en ellos cuatro registros como estos7:

; Dominio que nunca envía correo
example.org.                    IN TXT  "v=spf1 -all"
;  -> ningún servidor está autorizado
_dmarc.example.org.             IN TXT  "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:informes-dmarc@example.com"
;  -> rechazar todo lo que diga venir del dominio o de sus subdominios
*._domainkey.example.org.       IN TXT  "v=DKIM1; p="
;  -> clave DKIM vacía: ninguna firma es válida
example.org.                    IN MX   0 .
;  -> «MX nulo»: el dominio no acepta correo

Cómo comprobar tus registros

Desde la terminal, con dig (cambia example.com por tu dominio):

# SPF: busca una sola línea que empiece por v=spf1
dig +short TXT example.com

# DMARC: busca v=DMARC1 y fíjate en el valor de p=
dig +short TXT _dmarc.example.com

# DKIM: solo si conoces el selector (míralo en la etiqueta s= de un correo tuyo)
dig +short TXT s2026._domainkey.example.com

Declaración de interés: este blog es de SmoothSeen. Dentro de la categoría de seguridad y confianza de su análisis de posicionamiento web, SmoothSeen comprueba si tu dominio publica SPF y DMARC, y avisa si el DMARC se ha quedado en p=none. No comprueba DKIM, por el motivo del selector que explicamos arriba. En la misma categoría revisa las cabeceras de seguridad HTTP y si la web se sirve por HTTPS sin contenido mixto, que tratamos en la guía de HTTPS y SEO.

Preguntas frecuentes

¿Necesito DMARC si mi empresa solo envía correos normales, sin newsletters?

Sí. Las normas más estrictas de Gmail, Yahoo y Outlook se aplican a los remitentes masivos, pero DMARC protege a cualquier dominio de la suplantación, y eso no depende de cuánto envíes. Además, los correos del día a día también llegan mejor autenticados. Empieza con p=none y un buzón para los informes, y endurece la política cuando sepas quién envía en tu nombre.

¿Qué es mejor en SPF, ~all o -all?

-all declara que cualquier servidor no listado falla; ~all (softfail) solo indica que probablemente no está autorizado. Si aún no tienes claro qué servicios envían en tu nombre, ~all es más prudente mientras revisas los informes de DMARC. En un dominio que no envía correo, usa -all sin dudarlo, como recomienda la guía del Gobierno británico.

¿Un DMARC con p=none me protege de la suplantación?

No. Con p=none el dueño del dominio no expresa ninguna preferencia sobre los correos que fallan, así que el receptor decide por su cuenta. Su valor está en los informes, que te dicen quién envía con tu dominio. Es el primer paso hacia p=quarantine y p=reject, que son las políticas que sí piden apartar o rechazar los correos falsos.

¿Configurar SPF, DKIM y DMARC mejora el SEO?

No hay ninguna declaración de Google que lo diga, y no conviene esperarlo. Lo que sí hacen es proteger tu marca: evitan que alguien use tu dominio para estafar a tus clientes y ayudan a que tus correos lleguen a la bandeja de entrada. Es confianza, y la confianza se pierde rápido cuando circula un correo falso con tu nombre.

Qué hacer ahora

Ejecuta las dos primeras órdenes de dig sobre tu dominio y sobre los que tengas sin uso. Si falta el DMARC, publica uno con p=none y un buzón de informes hoy mismo, y apunta en el calendario revisarlo dentro de un mes. Después, sigue con el resto de la seguridad de tu web en la guía de posicionamiento web.