¿Qué son SPF, DKIM y DMARC, y por qué tus correos llegan a spam?
Los tres registros DNS que deciden si un servidor de correo se fía de tus mensajes, cómo encajan entre sí y los errores de configuración que mandan a spam correos perfectamente legítimos.
Por Javier Tenjo, Desarrollador full stack
En esta página
Un día, sin que nadie haya tocado nada, los presupuestos que envías empiezan a llegar a la carpeta de spam de tus clientes. O un cliente te reenvía un correo «tuyo» que pide un cambio de cuenta bancaria que tú nunca escribiste. Las dos cosas tienen la misma raíz: el correo electrónico se diseñó sin ninguna forma de comprobar quién envía qué.
El protocolo con el que viaja el correo (SMTP) deja que cualquier servidor escriba el remitente que quiera, igual que nada te impide poner una dirección falsa en el remite de un sobre. SPF, DKIM y DMARC son tres capas que se añadieron con los años para cubrir ese hueco. Las tres viven en el DNS de tu dominio, y los servidores que reciben tu correo las consultan antes de decidir si lo entregan, lo mandan a spam o lo rechazan.
SPF: la lista de quién puede enviar
SPF (Sender Policy Framework) es un registro TXT en la raíz del dominio que enumera los servidores autorizados a enviar correo en su nombre. Tiene este aspecto:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Se lee de izquierda a derecha: el correo que sale de los servidores de Google Workspace está autorizado, el que sale de SendGrid también, y todo lo demás se trata según el cierre. Ese cierre importa más de lo que parece:
-all: lo que no está en la lista se rechaza.~all: lo que no está en la lista se acepta, pero marcado como sospechoso. Es el ajuste más habitual.?all: neutral. En la práctica no protege nada.+all: autoriza a todo el mundo. Es peor que no tener SPF, porque además parece que lo hay.
Un detalle que casi nadie conoce: SPF no comprueba la dirección que ve el destinatario en el campo «De», sino la del sobre (el Return-Path), que es adonde vuelven los rebotes. Muchas plataformas de envío ponen su propio dominio en ese sobre, así que tu SPF puede estar perfecto y aun así no intervenir en esos correos. Para eso está DMARC, pero antes falta la firma.
DKIM: la firma que demuestra que no se alteró
DKIM (DomainKeys Identified Mail) añade a cada mensaje una firma criptográfica. El servidor que envía firma con una clave privada que solo él conoce, y la clave pública se publica en el DNS, en un nombre con la forma selector._domainkey.tudominio.com. El receptor descarga esa clave, comprueba la firma y sabe dos cosas: que el mensaje lo firmó alguien con permiso sobre el dominio y que nadie lo modificó por el camino.
El selector es lo que permite que un mismo dominio tenga varias firmas a la vez: una para el correo de la oficina, otra para la herramienta de boletines, otra para la plataforma de facturación. Cada proveedor elige el nombre del suyo, y por eso no hay forma de «listar» todos los DKIM de un dominio desde fuera: hay que saber qué selector buscar.
Sobre el tamaño de la clave, lo recomendado hoy son 2048 bits.
DMARC: qué hacer cuando algo no cuadra
SPF y DKIM dicen si un mensaje pasa o falla una comprobación, pero no dicen qué hacer con él. DMARC (Domain-based Message Authentication, Reporting and Conformance) es la política que lo decide, y vive en un TXT en _dmarc.tudominio.com:
v=DMARC1; p=quarantine; rua=mailto:dmarc@tudominio.com
La etiqueta p fija qué pasa con el correo que falla:
| Política | Qué pasa con el correo que falla | Para qué sirve |
|---|---|---|
p=none |
Se entrega igual | Observar y recibir informes |
p=quarantine |
Va a spam | Paso intermedio |
p=reject |
Se rechaza | Protección completa |
La etiqueta rua es la otra mitad del valor de DMARC: es la dirección a la que los grandes proveedores de correo mandan informes periódicos con todo lo que ha llegado en nombre de tu dominio, desde qué servidores y si pasó o no las comprobaciones. Sin rua no ves nada.
El camino sensato es empezar en none con informes, leerlos unas semanas hasta descubrir todos los servicios legítimos que envían por ti (el CRM, el software de facturación, el formulario de la web), configurarlos bien y después subir a quarantine y, por último, a reject. Saltar directamente a reject sin ese inventario es una forma rápida de que tus propias facturas dejen de llegar.
La alineación: la pieza que une las otras dos
Esta es la parte que más confunde y la que más importa. DMARC no se conforma con que SPF o DKIM pasen: exige que pasen para el mismo dominio que ve el destinatario en el campo «De». Eso es la alineación.
Un ejemplo. Envías un boletín desde una plataforma de marketing con remitente hola@tudominio.com. La plataforma usa su propio dominio en el sobre y firma con su propio DKIM. SPF pasa (para el dominio de la plataforma) y DKIM pasa (también para el de la plataforma), pero ninguno de los dos está alineado con tudominio.com, así que DMARC falla. Con p=reject, ese boletín no llega.
La solución está casi siempre en el panel del proveedor: una opción de «autenticar dominio» o «dominio de envío propio» que te da unos registros DKIM, y a veces un CNAME para el sobre, que publicas en tu DNS. Basta con que uno de los dos, SPF o DKIM, pase y esté alineado. Por defecto la alineación es relajada (aspf=r y adkim=r), de modo que un subdominio como correo.tudominio.com cuenta como alineado con tudominio.com.
¿Qué exigen Gmail y Yahoo desde 2024?
En 2024 Gmail y Yahoo empezaron a aplicar requisitos que convirtieron estos registros de recomendación en condición de entrega. A cualquier remitente le piden SPF o DKIM. A quien envía en volumen (Google sitúa el umbral en torno a 5.000 mensajes al día hacia cuentas de Gmail), bastante más:
- SPF y DKIM configurados.
- Un registro DMARC publicado, aunque sea con
p=none. - El dominio del «De» alineado con SPF o con DKIM.
- Baja con un clic en los correos comerciales y una tasa de denuncias por spam baja.
Microsoft anunció exigencias parecidas para Outlook en 2025. Aunque tu empresa no envíe miles de correos al día, la dirección es clara: los receptores se fían cada vez menos de un dominio sin estos tres registros.
¿Cuáles son los errores más frecuentes?
Dos registros SPF. Al contratar un servicio nuevo, alguien añade un segundo TXT v=spf1 en vez de editar el que ya había. El estándar solo admite uno: con dos, el resultado es un error y equivale a no tener ninguno. Hay que fundirlos en un único registro.
Pasarse de diez consultas. Cada include, a, mx o redirect del SPF obliga al receptor a hacer una consulta DNS, y los include de los proveedores suelen llevar otros dentro. El límite es diez. Pasado ese número, el SPF da un error permanente aunque el registro parezca correcto. Ocurre a menudo en empresas que han ido sumando herramientas sin quitar las que dejaron de usar.
DMARC en none para siempre. Publicarlo fue el primer paso y nadie dio el segundo. Mientras siga en none, el correo que suplanta tu dominio se entrega igual.
Olvidar los dominios que no envían. Un dominio que no manda correo debería publicar v=spf1 -all y un DMARC en reject. Así nadie puede usarlo para hacerse pasar por ti.
¿Cómo comprobar los tuyos?
El comprobador de SPF, DKIM y DMARC lee los registros MX, SPF y DMARC de cualquier dominio directamente del DNS público, cuenta las consultas que cuesta evaluar el SPF frente al límite de diez y explica cada hallazgo junto con lo que hay que hacer. Para DKIM necesitas el selector de tu proveedor; si reconoce quién recibe el correo del dominio, te sugiere por cuál empezar.
Si acabas de cambiar un registro y todavía ves el valor viejo, es la caché del DNS haciendo su trabajo. La comprobación de propagación DNS te dice si los resolutores públicos ya tienen la versión nueva.
Dejar bien estos tres registros es una tarde de trabajo entre el panel del DNS y los de tus proveedores de envío. A cambio, tus correos llegan a la bandeja de entrada y tu dominio deja de estar disponible para quien quiera hacerse pasar por ti.