SPF, DKIM y DMARC: Que tu Correo No Acabe en Spam

Por Qué el Correo Necesita Autenticación

Cuando un servidor de correo recibe un mensaje, tiene que responder a una pregunta aparentemente sencilla: ¿este correo viene de verdad de quien dice venir? Sin ningún mecanismo de autenticación, la única respuesta posible es un acto de fe. El campo From que ve el usuario es texto libre que el remitente controla por completo, igual que el remitente escrito a mano en el sobre de una carta postal: nadie comprueba que coincida con quien realmente la envió.

Esta falta de verificación tiene dos consecuencias directas. La primera es de seguridad: un atacante puede enviar correos que parecen provenir de tu dominio para engañar a tus clientes, empleados o proveedores. La segunda es de entregabilidad: como los proveedores de correo no pueden distinguir tu dominio legítimo de un impostor, aplican filtros de reputación agresivos y, ante la duda, mandan tus mensajes a spam. La autenticación resuelve ambos problemas a la vez, y es tan importante para la seguridad como los certificados SSL/TLS lo son para el tráfico web.

Los tres pilares de la autenticación de correo se apoyan en el DNS del dominio, donde se publican los registros que los servidores receptores consultan para validar cada mensaje. Si quieres entender bien cómo funciona esa infraestructura sobre la que se sostiene todo, tenemos una guía dedicada a cómo funciona el DNS y por qué es tan importante. Veamos ahora cada uno de los tres mecanismos.

SPF: Quién Puede Enviar en tu Nombre

SPF (Sender Policy Framework) es el más antiguo y sencillo de los tres. Consiste en un registro DNS de tipo TXT publicado en tu dominio que lista qué servidores están autorizados a enviar correo en su nombre. Cuando un servidor receptor recibe un mensaje, comprueba la dirección IP del servidor emisor contra esa lista: si la IP está autorizada, el correo pasa SPF; si no, falla.

Un registro SPF típico tiene este aspecto: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Los mecanismos include delegan la autorización a los servidores de terceros que envían por ti (tu proveedor de correo, tu plataforma de email marketing, tu CRM), y el final del registro define la política. Aquí es donde aparece una distinción clave: el ~all (softfail) indica que el correo de servidores no listados es sospechoso pero debe aceptarse igualmente, mientras que -all (hardfail) indica que debe rechazarse directamente. Durante la fase de pruebas se usa ~all; en producción, con SPF bien afinado, lo correcto es -all.

SPF tiene una limitación técnica muy importante que hay que respetar: el límite de 10 consultas DNS (lookups). Cada include, a, mx o redirect del registro provoca una resolución adicional, y si al expandir todos los include anidados se superan los diez lookups, el registro se marca como permerror y la validación falla, aunque el correo sea legítimo. Este límite es la causa número uno de que SPF deje de funcionar cuando una empresa acumula demasiados servicios de terceros. Además, SPF tiene un punto débil estructural: no sobrevive a los reenvíos, porque al reenviar un correo cambia el servidor emisor y la IP original desaparece.

DKIM: La Firma Criptográfica del Mensaje

DKIM (DomainKeys Identified Mail) resuelve las carencias de SPF con un enfoque criptográfico. En lugar de verificar la IP del servidor emisor, DKIM añade una firma digital a la cabecera de cada correo saliente. El servidor de envío firma partes seleccionadas del mensaje (cabeceras y cuerpo) con una clave privada que solo él conoce, y publica la clave pública correspondiente en un registro DNS TXT. El receptor recupera esa clave pública, verifica la firma y confirma dos cosas: que el mensaje realmente proviene del dominio y que no ha sido alterado en tránsito.

La gran ventaja de DKIM frente a SPF es que la firma viaja dentro del propio correo, así que sobrevive a los reenvíos: mientras el contenido firmado no se modifique, la validación sigue siendo válida aunque el mensaje pase por varios servidores intermedios. Esto lo hace mucho más robusto para escenarios reales de distribución de correo.

DKIM utiliza el concepto de selector, un identificador que permite tener varias claves publicadas a la vez bajo el mismo dominio (por ejemplo selector1._domainkey.tudominio.com). Los selectores hacen posible la rotación de claves: publicar una clave nueva, empezar a firmar con ella y retirar la antigua sin interrumpir el servicio, una buena práctica de seguridad que conviene realizar periódicamente para limitar el impacto de una clave comprometida. Cada servicio de envío de terceros suele tener su propio selector y su propia clave, lo que evita el problema de los lookups que sufre SPF.

DMARC: La Política y la Visibilidad

DMARC (Domain-based Message Authentication, Reporting and Conformance) es la pieza que une SPF y DKIM y les da sentido. Por sí solos, SPF y DKIM validan el correo, pero no le dicen al receptor qué hacer cuando la validación falla ni informan al dueño del dominio de lo que está pasando. DMARC es un registro DNS TXT publicado en _dmarc.tudominio.com que resuelve exactamente eso. Puedes profundizar en la especificación y las herramientas oficiales en dmarc.org.

DMARC aporta tres cosas. La primera es la política, definida por el parámetro p, que indica al receptor qué hacer con el correo que no pasa la autenticación: p=none (no hacer nada, solo observar), p=quarantine (enviar a spam) o p=reject (rechazar el mensaje). La segunda es la alineación (alignment): DMARC exige que el dominio validado por SPF o DKIM coincida con el dominio visible en la cabecera From, cerrando el hueco por el que un atacante podría pasar SPF con un dominio propio mientras falsifica el remitente que ve el usuario.

La tercera aportación, y probablemente la más valiosa al principio, son los informes agregados. Mediante el parámetro rua defines una dirección de correo a la que los proveedores receptores envían informes XML diarios con estadísticas de todo el correo que dice provenir de tu dominio: qué IPs envían, cuánto pasa SPF y DKIM, y cuánto falla. Estos informes te dan visibilidad total de quién envía en tu nombre —incluidos impostores y servicios legítimos que habías olvidado— y son la base sobre la que se construye una implementación segura de DMARC.

Cómo Trabajan los Tres Juntos

La forma más clara de entender la relación entre los tres es pensar en capas complementarias. SPF valida el servidor emisor, DKIM valida el mensaje mediante criptografía, y DMARC valida que ambos estén alineados con el dominio visible y decide qué hacer si no lo están. Un correo pasa DMARC si SPF o DKIM validan correctamente y están alineados con el From; basta con que uno de los dos funcione, lo que aporta redundancia. La siguiente tabla resume qué valida cada mecanismo, dónde se publica y de qué protege:

El Camino de Implementación Paso a Paso

Implementar DMARC no es publicar un registro y olvidarse: es un proceso gradual diseñado para no rebotar correo legítimo por el camino. El orden recomendado es siempre el mismo:

• check_circle Publica SPF y DKIM primero: asegúrate de que tu proveedor de correo y todos tus servicios de envío tengan sus registros SPF y sus selectores DKIM correctamente configurados antes de tocar DMARC.
• check_circle Empieza con p=none: publica DMARC en modo monitorización con una dirección rua para recibir informes. En esta fase no se bloquea nada; solo observas quién envía en tu nombre durante varias semanas.
• check_circle Corrige tus fuentes legítimas: analiza los informes, identifica todos los servicios reales que envían por ti (marketing, facturación, CRM, tickets) y alinéalos hasta que el 100% de tu correo legítimo pase la autenticación.
• check_circle Endurece a p=quarantine y luego a p=reject: cuando estés seguro de que solo tus fuentes legítimas superan la validación, sube la política de forma progresiva hasta el rechazo total del correo suplantado.

Una vez alcanzado p=reject, existe un paso extra opcional: BIMI (Brand Indicators for Message Identification). BIMI permite mostrar el logotipo verificado de tu marca junto a tus correos en la bandeja de entrada de los proveedores compatibles, lo que aumenta el reconocimiento y la confianza. Requiere DMARC en política estricta como condición previa, así que es la recompensa natural a un despliegue de autenticación bien hecho.

Este proceso ha dejado de ser opcional. Desde 2024, Google, Yahoo y Microsoft exigen autenticación de correo —SPF, DKIM y una política DMARC como mínimo en p=none— a los remitentes que envían grandes volúmenes de mensajes, y rechazan o marcan como spam el correo que no cumple. Lo que antes era una buena práctica recomendada es hoy un requisito de entrada para que tus campañas y notificaciones lleguen a la bandeja de entrada.

Errores Comunes que Debes Evitar

La mayoría de los problemas de autenticación no vienen de la teoría, sino de descuidos concretos en la configuración. Estos son los más frecuentes:

• arrow_right SPF con demasiados include: superar el límite de 10 lookups DNS invalida todo el registro con un permerror. Conviene consolidar servicios y, si es necesario, usar técnicas de aplanado (flattening) del registro.
• arrow_right Olvidar servicios de terceros: plataformas como Mailchimp, tu CRM, la herramienta de facturación o el sistema de tickets envían correo en tu nombre. Si no los incluyes en SPF y DKIM, su correo legítimo fallará la autenticación.
• arrow_right Poner DMARC en reject sin monitorizar: saltar directamente a la política de rechazo sin haber analizado los informes rebota correo legítimo y puede dejar a tu empresa sin poder enviar facturas o notificaciones críticas.
• arrow_right Ignorar los informes rua: publicar DMARC y no leer nunca los informes desaprovecha su mayor ventaja. Son la única forma de detectar suplantaciones y fuentes legítimas mal configuradas.

Estos fallos no son solo técnicos: un dominio sin autenticación es un vector abierto para las campañas de phishing e ingeniería social que suplantan tu marca para engañar a terceros. El impacto de hacerlo bien es doble: mejora la entregabilidad (tus correos no caen en spam) y aporta protección de marca (nadie puede enviar correo fraudulento que aparente venir de tu dominio).

Cómo te Ayuda EasyDataHost

Configurar SPF, DKIM y DMARC correctamente exige conocer la infraestructura DNS del dominio, identificar todas las fuentes de envío y afinar los registros sin interrumpir el correo en producción. En EasyDataHost ayudamos a nuestros clientes a configurar los registros DNS de autenticación de su correo corporativo como parte de nuestros servicios de seguridad e infraestructura:

• arrow_right Diseño y publicación de registros SPF optimizados que respetan el límite de 10 lookups incluso con múltiples servicios de terceros.
• arrow_right Configuración de claves DKIM y selectores con rotación periódica para cada plataforma de envío.
• arrow_right Despliegue gradual de DMARC desde p=none hasta p=reject, con análisis de los informes agregados en cada fase.
• arrow_right Integración de la autenticación de correo dentro de una estrategia global de seguridad gestionada, en datacenter propio en España.

Todo ello con la garantía de nuestra infraestructura certificada ISO 27001 y conforme al ENS. Si tu correo corporativo aún no tiene los tres pilares configurados, es una de las mejoras de seguridad con mayor retorno que puedes implementar.

Preguntas Frecuentes

Conclusión

El correo electrónico seguirá funcionando sobre un protocolo que nació sin seguridad, pero eso no significa que tengas que aceptar sus riesgos. SPF, DKIM y DMARC convierten un sistema abierto a la suplantación en un canal autenticado y de confianza:

• arrow_right SPF lista qué servidores pueden enviar en nombre de tu dominio, respetando el límite de 10 lookups y usando -all en producción.
• arrow_right DKIM firma criptográficamente cada mensaje, garantizando su integridad y origen, y sobrevive a los reenvíos gracias a selectores rotables.
• arrow_right DMARC alinea la autenticación con el remitente visible, define la política (none, quarantine, reject) y aporta la visibilidad de los informes agregados.
• arrow_right El despliegue gradual —de p=none a reject, con BIMI como recompensa— mejora la entregabilidad y protege tu marca, y hoy es un requisito de Google, Yahoo y Microsoft.