SPF, DKIM y DMARC: por qué tus correos van a spam
Si tus correos caen en spam, casi siempre es SPF, DKIM o DMARC. Qué comprueba cada registro y cómo revisar tu dominio en dos minutos.
Cuando tus correos legítimos acaban en spam, la causa más frecuente no es el texto del mensaje: es que el servidor que lo recibe no puede demostrar que salió de ti. Esa demostración son tres registros DNS que trabajan juntos. SPF declara qué servidores pueden enviar en nombre de tu dominio. DKIM firma criptográficamente cada mensaje. DMARC le dice al destinatario qué hacer cuando alguno falla, y te manda informes de lo que ocurre. Puedes consultar los registros SPF, DKIM y DMARC de tu dominio en unos segundos y ver cuál de los tres tienes mal —o directamente ausente.
Qué hace cada registro, en una frase
Los tres viven en el DNS de tu dominio y los tres son públicos: cualquiera puede consultarlos, incluido el servidor que decide si tu correo entra o no.
- SPF (Sender Policy Framework) es un registro TXT del tipo
v=spf1 include:_spf.google.com -all. Es una lista blanca: estos servidores pueden enviar por mí, el resto no. - DKIM (DomainKeys Identified Mail) añade una cabecera
DKIM-Signaturea cada mensaje, calculada con una clave privada que solo tiene tu servidor de envío. La clave pública se publica en el DNS bajo un selector, comogoogle._domainkey.tudominio.com, y es una cadena en Base64 —esa maraña de caracteres que puedes reconocer con el codificador Base64—. El receptor calcula un resumen del mensaje con SHA-256, igual que hace un generador de hashes, y comprueba la firma: si el contenido se alteró por el camino, no cuadra. - DMARC (Domain-based Message Authentication, Reporting and Conformance) se publica en
_dmarc.tudominio.comcon la formav=DMARC1; p=none; rua=mailto:informes@tudominio.com. Define la política (none,quarantine,reject) y la dirección a la que quieres recibir los informes agregados.
La alineación: la pieza que casi nadie mira
Aquí está el malentendido que más tiempo hace perder. DMARC no se conforma con que SPF o DKIM "pasen": exige además alineación de dominio. El destinatario compara el dominio que aparece en el From visible —el que ve la persona— con el dominio que validó SPF (que es el del Return-Path, no el From) y con el dominio del campo d= de la firma DKIM. DMARC pasa si al menos uno de los dos coincide.
Eso explica el caso que desconcierta a todo el mundo: envías desde una plataforma de newsletters, el análisis dice "SPF: pass", y DMARC falla igualmente. Lo que pasó es que SPF validó el dominio de la plataforma, no el tuyo. La solución es configurar el dominio de retorno personalizado que casi todas ofrecen, o firmar con DKIM usando tu propio dominio. En modo relaxed —el predeterminado— basta con que coincida el dominio organizativo, así que un subdominio como mail.tudominio.com alinea sin problema.
Qué exigen Gmail y Yahoo desde 2024
En febrero de 2024 Google y Yahoo endurecieron a la vez sus requisitos para remitentes, y ese es el listón que se aplica hoy. Para cualquier remitente: autenticación con SPF o DKIM, DNS inverso (PTR) válido en la IP de envío, conexión con TLS y un From que no suplante a otro dominio. Sin eso, el rechazo o la carpeta de spam son cuestión de tiempo.
Para remitentes masivos —Google fija el umbral en unos 5.000 mensajes diarios a direcciones de Gmail— los requisitos suben: SPF y DKIM, un registro DMARC publicado (aunque sea con p=none), alineación de al menos uno de los dos mecanismos, cabecera de baja en un clic conforme al RFC 8058 que se procese en un plazo de dos días, y mantener la tasa de quejas por spam por debajo del umbral que publica Google en Postmaster Tools. Si envías campañas, mide bien de dónde viene el tráfico: un constructor de URLs con UTM te ahorra mezclar problemas de entregabilidad con problemas de atribución.
Los errores que se repiten
- Dos registros SPF. Al contratar un proveedor nuevo se añade otro TXT con
v=spf1en vez de fusionarlo en el existente. Resultado:permerrory SPF inválido por completo. - Terminar en
+all. Autoriza al mundo entero a enviar por tu dominio; es peor que no tener SPF. Usa-all(rechazo) o, mientras despliegas,~all(softfail). - Pasarse de 10 consultas DNS. SPF limita a diez las búsquedas que provoca la evaluación, y cada
includeanidado cuenta. Cuatro o cinco proveedores acumulados y te vas del límite:permerrorotra vez. Se arregla podando includes de servicios que ya no usas y aplanando los que puedas. p=noneeterno. Publicar DMARC en observación y no volver a tocarlo durante dos años es tener un detector de humo desconectado: ves los informes —si es que los lees— pero cualquiera puede seguir suplantando tu dominio sin consecuencias.- DMARC sin
rua. Sin dirección de informes pierdes lo único que te permite saber quién envía en tu nombre antes de endurecer la política.
Cómo comprobar tu dominio en dos minutos
Abre el verificador de SPF, DKIM y DMARC, escribe tu dominio y revisa cuatro cosas. Primero, el registro TXT que empieza por v=spf1: que haya uno solo y que no acabe en +all. Segundo, _dmarc: que exista y qué política declara. Tercero, DKIM: introduce tu selector —la herramienta trae los habituales, google, default, k1— y confirma que devuelve una clave pública. Cuarto, los MX, para verificar que el correo entrante apunta donde crees.
El detalle que sorprende: DKIM no se puede descubrir por DNS. No existe forma de listar los selectores de un dominio, así que si ninguno de los presets responde, saca el tuyo del campo s= de la cabecera DKIM-Signature de un correo que ya hayas enviado. La consulta se hace desde tu navegador contra un resolutor DNS-over-HTTPS público; no pasa por ningún servidor de Docuboxer y no se guarda nada.
Un despliegue sensato de DMARC
Publica p=none con rua y deja pasar entre dos y cuatro semanas de informes. Ahí aparecerán fuentes que habías olvidado: la facturación, el CRM, el formulario de la web, la herramienta de firma. Arregla la alineación de cada una, pasa a p=quarantine con pct=25, sube a 100, y solo entonces a p=reject. Saltar directo a reject con fuentes sin identificar es la forma más rápida de que tus propias facturas dejen de llegar.
La parte honesta: los tres no te garantizan la bandeja de entrada
SPF, DKIM y DMARC responden a una sola pregunta: ¿este mensaje sale de quien dice salir? No dicen nada sobre si el mensaje es deseado. Un atacante puede registrar un dominio parecido al tuyo, autenticarlo impecablemente y enviar phishing con SPF, DKIM y DMARC en verde —por eso conviene saber también cómo se cuelan los códigos QR maliciosos, que hoy viajan sobre todo por correo—.
Y en el otro sentido: con los tres registros perfectos puedes seguir cayendo en spam si tu reputación es mala. Envíos a listas compradas, direcciones que ya no existen, gente que te marca como spam, picos bruscos de volumen desde una IP nueva. Los registros son el billete de entrada; el asiento lo decide tu comportamiento como remitente durante meses. Cualquiera que te prometa la bandeja de entrada "garantizada" por configurar DNS te está vendiendo humo.
Preguntas frecuentes
¿Necesito los tres registros o basta con SPF?
Con solo SPF te quedas corto. SPF se rompe cuando un correo se reenvía, porque el servidor intermedio no está en tu lista de autorizados; DKIM sobrevive al reenvío porque la firma viaja dentro del mensaje. DMARC es el que une los dos y le dice al receptor qué hacer cuando ambos fallan. Lo razonable es publicar SPF y DKIM, y encima DMARC.
¿Puedo tener dos registros SPF en el mismo dominio?
No. El estándar permite un único registro TXT que empiece por v=spf1 por dominio; si hay dos, el receptor devuelve permerror y SPF falla entero, aunque los dos registros fueran correctos por separado. Cuando añades un proveedor nuevo, se fusiona su include dentro del registro existente, nunca se crea otro.
¿Qué significa p=none en mi registro DMARC?
Significa modo observación: el receptor te envía informes de qué pasa, pero no aplica ninguna acción a los correos que fallan. Es el punto de partida correcto para descubrir tus fuentes de envío, pero no protege tu dominio de suplantación. El objetivo es avanzar a quarantine y luego a reject cuando los informes salgan limpios.
¿Cómo sé qué selector DKIM usa mi dominio?
El DNS no permite listar selectores: hay que conocerlo. Míralo en la cabecera DKIM-Signature de cualquier correo que hayas enviado (el campo s=) o en el panel de tu proveedor. Los más habituales son google para Google Workspace, selector1 y selector2 en Microsoft 365, y k1 o similares en plataformas de envío masivo.
¿Por qué pasa SPF pero DMARC sigue fallando?
Casi siempre es un problema de alineación. DMARC no mira solo si SPF pasó, sino si el dominio que validó SPF coincide con el dominio del From que ve el destinatario. Muchas plataformas envían con su propio dominio en el Return-Path: SPF pasa para ellas y falla la alineación para ti. Se arregla configurando el dominio de retorno personalizado que ofrece el proveedor, o apoyándote en DKIM firmado con tu dominio.
¿Configurar los tres garantiza que mis correos lleguen a la bandeja de entrada?
No. La autenticación es el requisito de entrada, no el destino: sin ella te descartan de salida, pero con ella sigues compitiendo contra tu reputación como remitente. Las quejas de spam, las listas compradas, los envíos a direcciones muertas y el contenido del mensaje pesan tanto o más que los registros DNS.
Revisa el correo de tu dominio ahora
SPF, DKIM, DMARC, MX, CAA y DNSSEC. Gratis, desde tu navegador.
Abrir verificador DNS →Herramientas relacionadas
- Verificar SPF, DKIM y DMARC — Registros de correo de cualquier dominio, explicados.
- Codificar y decodificar Base64 — El formato en el que viaja la clave pública DKIM.
- Generar hash — SHA-256 y compañía, la base de la firma DKIM.
- Constructor de URLs con UTM — Para medir tus campañas de correo sin romper los enlaces.
También te puede interesar: herramientas SEO gratuitas que no te piden registro.