SPF, DKIM y DMARC: la guía definitiva en español

Configuras el correo de tu dominio, envías tu primera campaña y la mitad acaba en spam. El culpable suele ser el mismo: falta de autenticación. SPF, DKIM y DMARC son los tres registros DNS que demuestran a Gmail, Outlook y Yahoo que eres quien dices ser. Esta guía te explica qué hace cada uno, cómo encajan y en qué orden configurarlos.

Qué son SPF, DKIM y DMARC y por qué van juntos

Los tres son mecanismos de autenticación de correo: sirven para que el servidor que recibe tu mensaje verifique que salió de una fuente legítima y que nadie lo ha manipulado por el camino. Ninguno resuelve el problema por sí solo, y por eso se implementan como un conjunto. SPF dice qué servidores pueden enviar en tu nombre, DKIM firma cada mensaje para probar que es tuyo y que llegó intacto, y DMARC le dice al receptor qué hacer cuando algo no cuadra.

La analogía que mejor funciona: SPF es la lista de invitados de un evento, DKIM es el sello lacrado de un sobre, y DMARC es el guardia de seguridad que decide si deja pasar al invitado o lo echa cuando la lista y el sello no coinciden.

¿Por qué importa tanto ahora? Porque los grandes proveedores han pasado de recomendar la autenticación a exigirla. Un dominio sin estos tres registros no solo es vulnerable a la suplantación: parte con desventaja en cada filtro antispam, porque el receptor no tiene forma de confirmar que el correo es legítimo. Configurarlos es, hoy, el requisito de entrada para que tus mensajes se tomen en serio en lugar de arrancar bajo sospecha.

Registro	Qué verifica	Dónde vive
SPF	Qué IPs o servidores pueden enviar en nombre del dominio	TXT en el dominio raíz
DKIM	Que el mensaje no se ha alterado y salió de tu dominio	TXT en selector._domainkey
DMARC	Qué hacer si SPF o DKIM fallan, y a dónde reportarlo	TXT en _dmarc

SPF: autoriza quién puede enviar en tu nombre

El registro SPF (Sender Policy Framework) es una lista de servidores autorizados a enviar correo con tu dominio en el remitente. Se publica como un único registro TXT en la raíz del dominio. Cuando un servidor recibe un correo tuyo, consulta ese TXT y comprueba si la IP que envió está en la lista.

Tipo	Host	Valor
TXT	@	v=spf1 include:_spf.google.com ~all

Cada parte tiene un significado: v=spf1 marca la versión, include:_spf.google.com delega la autorización en los servidores de Google, y ~all es el qualifier final. Los qualifiers más habituales son -all (rechazo estricto de cualquier IP no listada), ~all (softfail, se acepta pero se marca como sospechoso) y ?all (neutral, no recomendado). Ten en cuenta un límite que rompe muchas configuraciones: SPF permite un máximo de 10 consultas DNS. Si encadenas demasiados include, la validación falla con un error de permerror y tu SPF deja de contar.

Un detalle clave: SPF valida el dominio del Return-Path (el remitente del sobre), no el From que ve el usuario. Esa distinción es la que después obliga a DMARC a introducir el concepto de alineación. Si quieres el detalle completo de sintaxis y errores, tienes la guía paso a paso del registro SPF.

DKIM: la firma que prueba que el mensaje es tuyo

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada correo que envías. Funciona con un par de claves: la privada la guarda tu servidor de correo y firma con ella una parte del mensaje; la pública la publicas en tu DNS para que cualquier receptor pueda verificar la firma. Si el contenido firmado se altera en tránsito, la verificación falla.

Tipo	Host	Valor
TXT	google._domainkey	v=DKIM1; k=rsa; p=MIGfMA0GCSq...

El fragmento antes de ._domainkey se llama selector (aquí google) y permite tener varias claves activas a la vez, algo útil cuando rotas claves o usas varios proveedores. El correo firmado lleva una cabecera DKIM-Signature con el selector y el dominio (d=), y el receptor usa esos datos para localizar tu clave pública. Publicar y verificar tu clave paso a paso lo cubre la guía de configuración de DKIM.

DMARC: la política que decide qué pasa cuando algo falla

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la capa que ata SPF y DKIM. Le dice al servidor receptor qué hacer con los correos que no pasan la autenticación y le pide que te envíe informes de todo lo que se envía en tu nombre. Se publica como TXT en el subdominio _dmarc.

Tipo	Host	Valor
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:informes@tudominio.com

La pieza central es la política p, que admite tres valores: p=none (no hagas nada, solo repórtame), p=quarantine (manda a spam lo que falle) y p=reject (rechaza directamente). Siempre se empieza por p=none para observar sin romper nada, y se sube de nivel cuando los informes confirman que tu correo legítimo pasa. El parámetro rua indica a dónde llegan los informes agregados. Cómo leer esos informes y cuándo endurecer la política lo tienes en la guía de las políticas de DMARC.

El concepto que casi nadie explica: la alineación

Aquí está la trampa que hace que muchas configuraciones parezcan correctas pero fallen. Que SPF o DKIM pasen no es suficiente para DMARC: además tienen que estar alineados con el dominio que el usuario ve en el From. La alineación de SPF exige que el dominio del Return-Path coincida con el del From. La alineación de DKIM exige que el dominio de la firma (d=) coincida con el del From.

DMARC pasa si al menos uno de los dos (SPF o DKIM) pasa y está alineado. Por eso una herramienta de terceros que envía en tu nombre puede tener SPF válido y aun así fallar DMARC: el sobre usa el dominio del proveedor, no el tuyo. La solución habitual es firmar con DKIM usando tu dominio o configurar un dominio de envío personalizado. Puedes elegir alineación relajada (r, admite subdominios) o estricta (s, coincidencia exacta) con los parámetros aspf y adkim.

Un ejemplo de alineación que falla

Imagina que envías tu newsletter desde hola@tudominio.com con una plataforma de terceros. Esa plataforma usa su propio dominio en el Return-Path (algo como bounces.plataforma.com), así que, aunque el SPF de la plataforma dé pass, el dominio no coincide con tu From y la alineación de SPF falla. Si la plataforma tampoco firma con DKIM usando tu dominio, DMARC dará fail y, con una política estricta, tu newsletter acabaría en spam pese a tener SPF y DKIM técnicamente correctos. La solución es configurar en la plataforma un dominio de envío propio (un subdominio tuyo) y firmar DKIM con él. Este tipo de detalle es justo lo que descubres al leer los informes de DMARC.

Cómo configurarlos según tu proveedor

El sitio donde publicas estos registros es el panel DNS de tu dominio, pero los valores concretos te los da tu proveedor de correo. Los dos casos más comunes en cold email y en empresas son Google Workspace y Microsoft 365, y cada uno tiene sus particularidades: Google genera el DKIM desde la consola de administración con un selector propio, y Microsoft usa CNAME en lugar de TXT para el DKIM. Tienes las guías dedicadas para dejar los tres registros listos en Google Workspace y para hacer lo propio en Microsoft 365, con los valores exactos de cada plataforma.

Si además gestionas tú los registros DNS del dominio y quieres entender el resto de entradas que rodean al correo (MX, CNAME, PTR), te viene bien repasar qué hace cada registro DNS del correo.

Comprueba que los tres funcionan antes de enviar

Publicar los registros no garantiza que estén bien. La propagación DNS tarda, un carácter de más rompe la sintaxis y la alineación es fácil de pasar por alto. Antes de lanzar cualquier campaña, valida los tres con una herramienta de diagnóstico y con un envío de prueba real a una cuenta de Gmail, donde puedes ver la autenticación en los detalles del mensaje. El proceso completo, con herramientas gratuitas, está en la guía para verificar SPF, DKIM y DMARC.

Gmail y Yahoo ya lo exigen

Desde 2024, Gmail y Yahoo obligan a los remitentes que superan cierto volumen diario a tener SPF, DKIM y DMARC configurados y alineados, además de una cabecera de baja con un clic y una tasa de spam por debajo del 0,3 %. La tendencia es que el umbral baje y que estos requisitos se conviertan en el mínimo para cualquiera que haga outreach. Tienes el desglose actualizado en los requisitos de Gmail y Yahoo para remitentes.

Errores frecuentes al implementar los tres registros

• Publicar dos SPF. Solo puede haber uno; si combinas proveedores, une los include en un único registro.
• Cortar la clave DKIM. El valor p= es largo y algunos paneles lo parten; debe quedar íntegro o la firma no valida.
• Saltar directamente a p=reject. Sin revisar los informes, bloqueas correo legítimo que no sabías que se enviaba en tu nombre.
• Olvidar un remitente. Facturación, CRM o soporte suelen enviar por servicios distintos; si no están autenticados, fallan.
• No proteger los subdominios. El parámetro sp de DMARC define la política de subdominios; sin él, alguien puede suplantar correo.tudominio.com.
• Dar por hecho que funciona sin verificar. La propagación DNS tarda y un envío de prueba a Gmail es la única confirmación real.

La mayoría de estos fallos no dan un error visible: simplemente hacen que tu correo pierda señales de confianza y baje su entregabilidad poco a poco.

Cuánto tarda en surtir efecto

Publicar los registros es cuestión de minutos, pero verlos activos y notar el efecto lleva más. La propagación DNS suele tardar de unos minutos a un par de horas, aunque el TTL de tu zona puede alargarla hasta 24-48 horas en el peor caso. A partir de ahí, SPF y DKIM funcionan de inmediato en cada envío. DMARC, en cambio, necesita tiempo de observación: conviene dejar la política en p=none al menos dos o tres semanas para acumular informes suficientes antes de endurecerla. Es decir, la autenticación técnica es rápida; el despliegue seguro de DMARC es deliberadamente lento.

La autenticación es la base, no el tejado

SPF, DKIM y DMARC son imprescindibles, pero no bastan por sí solos. Autenticar tu dominio le dice al receptor que el correo es legítimo; no le dice que sea deseado. Un dominio recién autenticado pero sin historial sigue siendo un desconocido para los filtros, y por eso puedes tenerlo todo en verde y aun así acabar en la carpeta de spam. La reputación se construye con el tiempo, con volumen creciente y con interacción real.

Ahí es donde entra el calentamiento o warmup de la cuenta: enviar y recibir correos de forma gradual para que Gmail y Outlook construyan confianza en tu dominio. PreheatMail automatiza justo eso, generando conversaciones reales entre cuentas del pool con comportamiento humano, para que tu reputación crezca mientras la autenticación hace su parte. Puedes ver cómo funciona el proceso en detalle.

Resumen accionable: publica un único SPF con los include de tus proveedores y cierra con ~all; activa DKIM y verifica que firma con tu dominio; añade DMARC en p=none, lee los informes y sube a quarantine o reject cuando confirmes la alineación; valida todo con un envío de prueba; y no olvides que sobre esa base necesitas reputación. Con eso, tus correos dejan de ser sospechosos por defecto.