SPF, DKIM y DMARC: cómo configurarlos para que tus correos no vayan a spam

Si tus correos llegan a spam, si Gmail muestra un aviso junto a tu nombre o si alguien está enviando mensajes falsos con tu dominio, casi siempre la causa está en estos tres registros. Te explicamos qué hace cada uno, cómo se escriben, cómo los configuran cPanel, Plesk, Google Workspace y Microsoft 365, y cómo comprobar que funcionan.

Qué necesitas antes de empezar

• Acceso a la zona DNS activa de tu dominio (la de tu hosting, tu registrador o Cloudflare). Si no sabes cuál es o cómo se añade un TXT, empieza por nuestra guía de registros DNS.
• La lista de todo lo que envía correo con tu dominio: tu hosting (buzones y formularios de la web), Google Workspace o Microsoft 365, la herramienta de newsletter, el CRM, el programa de facturación… Cada uno debe quedar autorizado.
• Acceso al panel del hosting. En proveedores con cPanel, como Nicalia, o con Plesk, como Profesional Hosting, buena parte del trabajo es automático si el correo está en el propio hosting.
• Un buzón para los informes DMARC, por ejemplo [email protected]. Llegan muchos y en formato XML, así que mejor que no sea tu bandeja principal.

Qué es SPF y cómo se escribe un registro SPF

SPF (Sender Policy Framework, RFC 7208) es un registro TXT en el nombre @ que empieza siempre por v=spf1. Detrás van los mecanismos que autorizan servidores y, al final, qué hacer con el resto:

• a y mx: autorizan las IP de los registros A y MX del dominio. cPanel los escribe con un + delante (+a +mx), que es opcional.
• ip4: e ip6:: autorizan una IP o un rango concreto, por ejemplo ip4:203.0.113.10.
• include:: delega en el SPF de otro servicio. Google Workspace usa include:_spf.google.com y Microsoft 365, include:spf.protection.outlook.com. Para otros servicios, usa el valor exacto que indique su documentación.
• all: el final del registro. ~all (softfail) marca como sospechoso lo que no esté en la lista; -all (fail) pide rechazarlo; ?all es neutro. Nunca uses +all: autoriza a cualquier servidor del mundo.

Solo puede haber un registro SPF

Si el dominio tiene dos TXT que empiezan por v=spf1, el estándar obliga a devolver un error (permerror) y el SPF deja de valer. Es el fallo más común al añadir un servicio: Microsoft lo advierte expresamente en su guía. La solución es fusionar: un solo v=spf1, todos los mecanismos y un único all al final.

El límite de 10 consultas DNS

Para evaluar tu SPF, el receptor no puede hacer más de 10 consultas DNS. Cuentan include, a, mx, ptr, exists y redirect, y también las que hay dentro de cada include. No cuentan ip4, ip6 ni all. Si te pasas, el resultado es permerror. El estándar también recomienda limitar a dos las consultas «vacías» (nombres que no existen o no responden), así que borra los include de servicios que ya no usas.

Para no pasarte: elimina lo que sobre, sustituye a y mx por ip4 si sabes la IP del servidor y no uses ptr, que el propio RFC desaconseja.

¿~all o -all?

Google recomienda ~all en su guía de SPF; Microsoft usa -all en el registro de ejemplo de Microsoft 365. Nuestra recomendación práctica: empieza con ~all mientras revisas los informes DMARC y pasa a -all solo cuando estés seguro de que no te falta ningún servicio. Con DMARC en marcha, lo que de verdad decide qué pasa con un correo que falla es su política p=.

Qué es DKIM

DKIM (DomainKeys Identified Mail, RFC 6376) firma cada mensaje con una clave privada que solo tiene el servidor que envía. La clave pública se publica en tu DNS, en un nombre con este formato: selector._domainkey.tudominio.es. El receptor la lee, comprueba la firma y sabe que el mensaje viene de un servidor autorizado y no se ha modificado por el camino.

El selector permite tener varias claves a la vez, una por servicio. cPanel y Plesk usan default; Google Workspace, google; Microsoft 365 publica dos, selector1 y selector2, como CNAME. Por eso, al contrario que con SPF, no tienes que fusionar nada: cada servicio añade su propio registro.

El valor de un TXT de DKIM tiene la forma v=DKIM1; k=rsa; p=…, donde p es la clave, una cadena larguísima. Google exige claves de al menos 1.024 bits y recomienda 2.048. Cópiala entera: un carácter de menos y la firma falla. Si tu panel da error por la longitud, recuerda que un TXT admite cadenas de 255 caracteres como máximo y la clave puede tener que ir partida.

Qué es DMARC y cómo implantarlo sin perder correos

DMARC es un TXT en _dmarc.tudominio.es. Hace dos cosas que SPF y DKIM no hacen solos:

• Exige alineación: no basta con que SPF o DKIM pasen; el dominio que validan debe coincidir con el del remitente que ve el usuario (el campo De:). Así se evita que alguien pase SPF con su propio dominio y ponga el tuyo como remitente.
• Publica una política y pide informes: p=none (solo observar), p=quarantine (tratar como sospechoso, normalmente a spam) o p=reject (rechazar). Con rua=mailto:… los grandes proveedores te envían informes agregados con quién envía correo con tu dominio y si pasa o no.

Otras etiquetas útiles: sp fija la política de los subdominios, y adkim/aspf eligen alineación relajada (r, por defecto) o estricta (s). En mayo de 2026 se publicó la nueva versión del estándar, RFC 9989, que sustituye a la RFC 7489: el registro sigue empezando por v=DMARC1, pero retira la etiqueta pct (que Google todavía menciona en su guía) y añade otras como t para el modo de prueba. No uses pct en un registro nuevo.

Despliegue por fases: none, quarantine, reject

1. Configura SPF y DKIM primero y espera. Google pide dejar pasar 48 horas antes de activar DMARC.
2. Publica p=none con rua. No cambia la entrega, pero empiezas a recibir informes.
3. Revisa los informes durante semanas. Busca servicios legítimos que fallen (la newsletter, el CRM, la web) y corrígelos en SPF o DKIM. Los informes son XML pensados para máquinas: un servicio de análisis de DMARC te ahorra mucho tiempo.
4. Sube a p=quarantine cuando todo lo legítimo pase. La RFC 9989 sugiere, para dominios cuyos usuarios escriben en listas de correo, mantener p=none al menos un mes y después p=quarantine otro tanto antes de plantearse p=reject.
5. Pasa a p=reject solo cuando la cuarentena lleve tiempo sin afectar a correo legítimo.

Lo que exigen Gmail y Yahoo

Desde febrero de 2024, Google y Yahoo aplican requisitos a quien envía correo a sus usuarios. Según sus guías actuales:

• Todos los remitentes: SPF o DKIM, registros DNS directos e inversos (PTR) válidos para las IP de envío y una tasa de spam por debajo del 0,3 %. Google exige además conexión TLS.
• Envíos masivos (Google los define como más de 5.000 mensajes al día a cuentas de Gmail): SPF y DKIM, DMARC con al menos p=none, el dominio del remitente alineado con SPF o DKIM y baja de suscripción con un clic en los correos comerciales.

Aunque no envíes newsletters, cumplir lo de los envíos masivos es la mejor forma de que tus correos normales lleguen a la bandeja de entrada. El PTR depende de quien controla la IP: en hosting compartido lo gestiona el proveedor.

Si tu correo está en Google Workspace o Microsoft 365

Google Workspace

• SPF: añade include:_spf.google.com a tu registro (o crea v=spf1 include:_spf.google.com ~all si Google es lo único que envía).
• DKIM: en la consola de administración, ve a Apps › Google Workspace › Gmail › Authenticate email (los nombres pueden aparecer traducidos), elige el dominio, pulsa Generate New Record, selecciona 2048 bits si tu DNS lo admite y deja el selector google. Crea el TXT google._domainkey con el valor que te da y, solo entonces, pulsa Start authentication. Google indica que, tras activar Gmail, la clave puede tardar de 24 a 72 horas en estar disponible, y que la autenticación puede tardar hasta 48 horas en empezar a funcionar.
• DMARC: TXT en _dmarc, tras esperar 48 horas desde SPF y DKIM.

Microsoft 365

• SPF: Microsoft propone v=spf1 include:spf.protection.outlook.com -all. Si ya tienes un SPF, no crees otro: añade el include al existente.
• DKIM: los dominios propios no se firman hasta que lo configuras. En el portal de Microsoft Defender, ve a Email & collaboration › Policies & rules › Threat policies › Email authentication settings, pestaña DKIM. Crea los dos CNAME (selector1._domainkey y selector2._domainkey) con los valores que te muestra y, pasados unos minutos, activa Sign messages for this domain with DKIM signatures.
• DMARC: igual que en cualquier otro caso, un TXT en _dmarc.

Cómo comprobar que funciona

• El SPF: consulta los TXT de tu dominio en nuestra consulta DNS y comprueba que hay un único registro v=spf1 con todos tus servicios.
• DKIM y DMARC viven en nombres que empiezan por guion bajo (_dmarc, default._domainkey). Consúltalos desde la terminal con los comandos de abajo o con la herramienta Dig de la Google Admin Toolbox, que Google recomienda en sus guías.
• Un correo real: envía un mensaje desde tu dominio a una cuenta de Gmail que no sea la tuya de envío. Ábrelo, pulsa Más (los tres puntos junto a Responder) y elige «Mostrar original». En la cabecera Authentication-Results deberías ver spf=pass, dkim=pass y dmarc=pass. Si falta la línea de DKIM, el mensaje no se ha firmado.
• Los informes DMARC: una vez publicado rua, irán llegando periódicamente a tu buzón como adjuntos XML.

Errores frecuentes y cómo solucionarlos

Dos registros SPF

Causa: un servicio nuevo añadió su propio v=spf1. Solución: fusiónalos en uno y borra el sobrante. Comprueba en la consulta DNS que solo queda uno.

SPF con más de 10 consultas

Causa: demasiados include, a menudo de servicios que ya no usas, o include que contienen a su vez otros. Solución: quita los que sobren, cambia a y mx por ip4 y elimina ptr.

Los correos de la newsletter o de la web van a spam

Causa: ese servicio no está en el SPF o no firma con DKIM tu dominio. Con DMARC en quarantine o reject, sus mensajes fallan. Solución: añade su include al SPF y configura su DKIM según su documentación. Los informes DMARC te dirán qué IP están fallando.

El panel dice que DKIM está activo, pero Gmail no ve la firma válida

Causa: el servidor firma, pero la clave pública está solo en la zona del hosting y los NS del dominio apuntan a otro sitio. Solución: copia el registro default._domainkey desde cPanel o Plesk y créalo en el proveedor DNS que manda.

La clave DKIM está incompleta

Causa: al copiar se perdió un trozo, se colaron espacios o comillas, o el panel cortó la cadena de más de 255 caracteres. Solución: vuelve a copiarla desde el origen, compárala con la consulta dig y, si el panel no admite valores tan largos, pide a soporte cómo partirla.

DMARC publicado en el sitio equivocado

Causa: el TXT se creó en @ en lugar de en _dmarc, o en un panel que añade el dominio se escribió _dmarc.tudominio.es y quedó duplicado. Solución: el nombre debe ser _dmarc (el panel añade el dominio). Comprueba con dig _dmarc.tudominio.es TXT.

Paso a reject y desaparecen correos legítimos

Causa: saltaste fases o algún servicio no estaba alineado. Los reenvíos y las listas de correo también rompen SPF con frecuencia. Solución: vuelve a p=none o p=quarantine, revisa los informes y corrige antes de subir otra vez.

Cómo deshacer el cambio

• SPF: restaura el valor anterior (guárdalo antes de editar). No lo borres sin más si tienes DMARC en quarantine o reject: sin SPF, el correo que no firme con DKIM fallará.
• DKIM: si dejas de usar una clave, desactiva primero la firma en el panel y luego borra el registro. Si la clave se ha visto comprometida, el estándar permite revocarla publicando p= vacío.
• DMARC: la marcha atrás más rápida es volver a p=none. Los receptores la aplicarán cuando caduque el TTL del registro.