SPF, DKIM y DMARC: qué son y por qué tus correos acaban en spam

Si los correos de tu empresa llegan a la carpeta de spam, o un cliente te avisa de que ha recibido un correo «tuyo» que tú no enviaste, casi siempre hay detrás lo mismo: tu dominio no tiene bien puestos SPF, DKIM y DMARC. Son tres ajustes del dominio que dicen al mundo quién puede enviar correo en tu nombre, y desde 2024 Gmail, Yahoo y Outlook los exigen. Te explicamos qué son, qué pasa si faltan y cómo ponerlos en orden.

Cuando envías un correo, el servidor que lo recibe no tiene forma de saber, por sí solo, si de verdad lo has enviado tú. Cualquiera puede poner tu dirección en el remitente. Estos tres ajustes, que se publican como registros en el DNS de tu dominio, sirven para comprobarlo:

• SPF es la lista de servidores autorizados a enviar correo con tu dominio. Se publica como un registro TXT en el propio dominio (RFC 7208). INCIBE lo describe como «un sistema de defensa ante intentos de suplantación de correos».
• DKIM es una firma digital que lleva cada correo y que el destinatario comprueba con una clave pública publicada en tu DNS (RFC 6376). Así se sabe que el mensaje sale de tu dominio y que nadie lo ha cambiado por el camino. La clave va en un nombre del tipo selector._domainkey.tudominio.es, y se recomienda que sea de al menos 2.048 bits (RFC 8301).
• DMARC une a los dos y le dice al destinatario qué hacer si un correo dice ser tuyo y no pasa la comprobación: nada (p=none), tratarlo como sospechoso (p=quarantine) o rechazarlo (p=reject). Además, te envía informes de quién está enviando correo con tu dominio. Se publica en _dmarc.tudominio.es.

Un detalle importante de DMARC es la alineación: no basta con que SPF o DKIM pasen; el dominio que valida tiene que coincidir con el del remitente que ve el destinatario. Si no coincide, DMARC falla aunque los otros dos hayan pasado.

DMARC es ahora estándar oficial: en mayo de 2026 se publicó como RFC 9989, que sustituye a la versión de 2015 (RFC 7489), que solo era informativa.

Desde febrero de 2024, los grandes proveedores de correo piden autenticación a quien les envía correo:

• Gmail exige a todos los remitentes SPF o DKIM, que el servidor tenga DNS inverso (PTR), usar conexiones cifradas (TLS) y mantener la tasa de spam por debajo del 0,3 %. A quien envía más de 5.000 correos al día le exige además SPF y DKIM, DMARC (basta p=none) con alineación y la baja en un clic en los correos comerciales. Y avisa de que, desde noviembre de 2025, aplica estas normas con más dureza: los correos que no cumplen pueden ir a spam o ser rechazados.
• Yahoo pide lo mismo desde febrero de 2024: a todos, SPF o DKIM y menos de un 0,3 % de spam; a los envíos masivos, SPF y DKIM, un DMARC válido de al menos p=none y alineación.
• Outlook.com (las cuentas personales de outlook.com, hotmail.com y live.com) exige desde el 5 de mayo de 2025 SPF, DKIM y DMARC a quien envía más de 5.000 correos al día, y según su anuncio rechaza los que no cumplen.

Aunque tu empresa no envíe 5.000 correos al día, tus clientes usan Gmail, Hotmail o Yahoo, y estos proveedores miran la autenticación de todos. Un dominio sin SPF ni DKIM tiene muchas más papeletas de acabar en spam.

Y hay una segunda razón para tenerlo bien: sin DMARC en una política que proteja, cualquiera puede enviar correos haciéndose pasar por tu empresa. Es la base de muchos fraudes, como el de la factura con una cuenta bancaria cambiada. INCIBE recomienda, ante cualquier cambio de cuenta, comprobarlo «mediante un canal de comunicación ajeno al correo electrónico».

• No tener DMARC, o tenerlo en p=none para siempre. p=none sirve para empezar y recibir informes, pero no protege: con ella no pides al destinatario que haga nada con los correos que fallan. Según el monitor de la Comisión Europea, en el tercer trimestre de 2026 el 95 % de los dominios españoles analizados tenía DMARC, pero solo el 36 % con una política estricta (la media de la UE es del 50 %). Ojo, son unos 5.500 dominios europeos con mucho tráfico de correo, no una muestra de pymes.
• Pasarse del límite de 10 consultas de SPF. Cada include (el de Microsoft 365, el de la herramienta de newsletters, el de la tienda…) cuenta, y el estándar fija un máximo de 10. Si se supera, SPF da error («permerror») y deja de servir, aunque el registro parezca correcto.
• Olvidarse de alguien que envía en tu nombre. La herramienta de newsletters, la tienda online, el programa de facturación o el CRM envían correos con tu dominio. Si no están en SPF ni firman con DKIM, sus correos fallan.
• Varios registros SPF. Solo puede haber uno por dominio; si hay dos, el resultado es un error.
• Claves DKIM antiguas o cortas, por debajo de los 1.024 bits que exige el RFC 8301.

Puedes revisarlo en nuestro analizador de correo: escribes el dominio y en unos segundos ves si recibe bien, si tiene SPF, DKIM y DMARC, si te pasas del límite de 10 consultas de SPF y, si algo falla, los registros exactos para arreglarlo.

Es el orden que marcan el propio estándar de DMARC (RFC 9989) y la guía de Google:

1. Haz inventario de quién envía correo en tu nombre: tu servidor de correo, la herramienta de newsletters, la tienda, la facturación… El RFC 9989 pide arreglar los envíos legítimos que no se autentican antes de endurecer DMARC.
2. Configura SPF y DKIM para todos ellos. Google recomienda hacerlo al menos 48 horas antes de publicar DMARC.
3. Publica DMARC en p=none con informes (la etiqueta rua, con la dirección que los recibirá). Es el modo de vigilancia: no cambia nada en la entrega, pero empiezas a saber quién envía con tu dominio.
4. Lee los informes y corrige lo que falle. El estándar explica que se empieza en p=none precisamente para asegurarse de que no se ha olvidado nada.
5. Pasa a p=quarantine poco a poco y comprueba que nada legítimo se queda por el camino. Algunas guías, como la de Google, lo hacen con la etiqueta pct (un porcentaje de los correos), que el nuevo estándar sustituye por el modo de prueba t.
6. Llega a p=reject cuando estés seguro de que todo tu correo se autentica. El RFC 9989 avisa de que pueden hacer falta meses de informes antes de dar este paso.

Hay ajustes más avanzados, como MTA-STS (exigir que el correo te llegue cifrado, RFC 8461) y TLS-RPT (recibir avisos si el cifrado falla, RFC 8460). BIMI, que muestra tu logo junto a tus correos, no es un estándar del IETF: es un borrador que el propio IETF no respalda. Ninguno de los tres sustituye a SPF, DKIM y DMARC.

Sí. Gmail exige SPF o DKIM a todos los remitentes, sin mínimo de envíos, y DMARC es lo que impide que otros se hagan pasar por tu empresa, envíes mucho o poco.

No. Con p=none recibes informes, pero no pides a los proveedores que hagan nada con los correos que fallan: el estándar la define como «ninguna preferencia». Es el punto de partida, no el final.

El estándar de SPF define -all como una negativa explícita y ~all como un resultado intermedio que, por sí solo, no debería bastar para rechazar un correo. Para DMARC solo cuenta que SPF haya pasado, así que, con DMARC en una política estricta, lo que decide qué pasa con los correos que fallan es DMARC.

Los registros se publican en el DNS de tu dominio, así que los pone quien gestiona tu dominio. Las claves de DKIM las genera tu proveedor de correo (Microsoft 365, Google Workspace o tu servidor), y cada herramienta que envía en tu nombre tiene que añadirse a SPF y firmar con DKIM.

Los cambios en el DNS suelen notarse en minutos u horas, según cómo esté configurado. Llegar a p=reject con seguridad lleva semanas o meses, según cuántos servicios envíen correo en tu nombre.

En LN Digital revisamos el correo de tu dominio y configuramos SPF, DKIM y DMARC para que tus correos no acaben en spam y nadie pueda hacerse pasar por ti, dentro de nuestro mantenimiento de servidores. Si quieres saber cómo está ahora, pásalo por el analizador de correo o escríbenos.

Consultadas el 20 de octubre de 2026.

• Estándares del IETF: RFC 7208 (SPF), RFC 6376 (DKIM), RFC 8301 (algoritmos y tamaño de clave de DKIM), RFC 9989 (DMARC), que deja obsoleto el RFC 7489, RFC 9990 (informes agregados de DMARC), RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT) y el borrador de BIMI.
• Google: requisitos para remitentes, preguntas frecuentes y calendario y despliegue recomendado de DMARC.
• Yahoo: buenas prácticas para remitentes.
• Microsoft: nuevos requisitos de Outlook.com para remitentes de grandes volúmenes.
• INCIBE: el correo electrónico, la primera barrera a proteger y fraude del email comprometido.
• Comisión Europea, EU Internet Standards Deployment Monitoring: correo (metodología), datos del tercer trimestre de 2026.