Diferencias entre SPF, DKIM y DMARC explicadas para MSP

Resumen ejecutivo: Los MSPs que gestionan entornos de correo electrónico para clientes necesitan que SPF, DKIM y DMARC funcionen juntos para proteger contra ataques de suplantación y cumplir con los requisitos de los proveedores de bandeja de entrada. Esta guía explica cómo funciona cada protocolo, por qué los tres son necesarios y cómo los MSPs pueden desplegar la autenticación de correo electrónico de manera eficiente en toda su base de clientes.

Puntos clave:

• SPF valida las direcciones IP de los servidores emisores, DKIM verifica la integridad del mensaje mediante firmas criptográficas y DMARC aplica políticas cuando la autenticación falla
• Google y Yahoo ahora exigen SPF y DKIM para emisores masivos, haciendo que la autenticación de correo electrónico sea esencial para la entregabilidad de los clientes
• Los MSPs deben implementar primero SPF, luego DKIM y después DMARC con p=none antes de avanzar hacia la aplicación de políticas
• La arquitectura multiempresa de Red Sift OnDMARC permite a los MSPs gestionar la autenticación de todos los dominios de clientes desde un solo panel, alcanzando la aplicación en 6-8 semanas frente a 6-12 meses de forma manual

Envías lo que parece ser un correo electrónico de negocios rutinario en nombre de un cliente, pero rebota o termina en spam. O peor aún, los clientes de tu cliente reciben correos de phishing que parecen venir de su dominio, dañando su reputación antes de que alguien se dé cuenta del problema. Estos escenarios ocurren porque el correo electrónico, por diseño, carece de verificación integrada de la identidad del remitente.

Los protocolos originales de correo electrónico de la década de 1980 asumían confianza entre los servidores. Cualquiera podía afirmar que enviaba correo desde cualquier dominio y los servidores receptores no tenían un método confiable para verificar esas afirmaciones. Esta debilidad fundamental permite los ataques de suplantación, en los que los atacantes falsifican la dirección From para hacerse pasar por remitentes de confianza.

Los protocolos de autenticación de correo existen para resolver esta brecha de seguridad. SPF, DKIM y DMARC trabajan juntos para verificar que los correos que afirman provenir de los dominios de tus clientes sean legítimos. Para los MSPs que gestionan múltiples entornos de clientes, comprender cómo funciona cada protocolo y por qué los tres son importantes puede marcar la diferencia entre una infraestructura segura y una vulnerable a ataques de suplantación y phishing.

SPF (Sender Policy Framework) es un estándar de autenticación de correo electrónico que permite a los propietarios de dominios especificar qué direcciones IP están autorizadas para enviar correo en su nombre. Cuando un servidor de correo recibe un email que dice ser de un dominio de cliente, consulta el registro SPF para confirmar que la IP del servidor emisor está en la lista aprobada.

Puedes pensar en SPF como la lista de invitados de un edificio seguro. El servidor receptor comprueba si la dirección IP emisora figura en la lista publicada de remitentes autorizados. Si coincide, el correo pasa la autenticación SPF. Si no, falla.

DKIM (DomainKeys Identified Mail) utiliza un enfoque diferente agregando una firma digital a las cabeceras del correo. Esta firma criptográfica demuestra que el mensaje no ha sido alterado en tránsito y confirma que proviene de un servidor con acceso a la clave privada DKIM. El servidor receptor valida esta firma con la clave pública publicada en el DNS.

Mientras SPF se centra en la identidad del servidor emisor, DKIM verifica el mensaje en sí. La firma abarca las cabeceras y el cuerpo del correo, por lo que cualquier alteración durante el tránsito invalida la firma.

DMARC (Domain-based Message Authentication, Reporting and Conformance) se construye sobre SPF y DKIM añadiendo aplicación de políticas y capacidades de reporte [1]. Mientras SPF y DKIM verifican aspectos distintos de un correo, DMARC asocia estos chequeos con el dominio visible en el buzón del destinatario e indica a los servidores receptores qué hacer cuando la autenticación falla.

La diferencia fundamental es que DMARC te da el control sobre la autenticación fallida. Puedes decidir si los correos que fallan se entregan igualmente, se envían a spam o se rechazan por completo. Para los MSPs, esto significa poder establecer políticas consistentes en todos los dominios de los clientes.

La guía de seguridad de correo electrónico de Red Sift ofrece más contexto sobre cómo DMARC coordina con SPF y DKIM una protección integral de dominio.

La validación SPF ocurre cuando el servidor receptor consulta el DNS buscando el registro SPF del dominio. Este registro TXT incluye una lista de IPs autorizadas e integra mecanismos como instrucciones "include" para servicios de terceros. El servidor compara la IP emisora con esta lista y retorna un resultado de aprobado, fallido o neutral [2].

• SPF: El servidor receptor consulta el DNS, compara la IP emisora con la lista autorizada y retorna aprobado/fallido/neutral
• DKIM: El servidor de correo firma el mensaje con una clave privada; el servidor receptor recupera la clave pública del DNS y valida la firma
• DMARC: Comprueba los resultados SPF o DKIM, verifica la alineación del dominio en la cabecera From y aplica la política según la configuración

DKIM funciona con criptografía de clave pública. El servidor de correo firma los mensajes salientes con una clave privada y los servidores receptores verifican la firma usando la clave pública publicada en el DNS. Si incluso un carácter del cuerpo del mensaje cambia durante el tránsito, la validación de DKIM falla.

DMARC coordina estos dos métodos de autenticación y añade funcionalidades críticas. Cuando publicas un registro DMARC, especificas una política (none, quarantine o reject) que le dice a los servidores receptores cómo manejar los correos que fallan en los chequeos SPF o DKIM. DMARC también requiere alineamiento, es decir, que el dominio en la cabecera From coincida con el dominio autenticado por SPF o DKIM.

El recurso de guía completa de DKIM y SPF explica los detalles técnicos de cómo estos protocolos fundamentales verifican la autenticidad del correo.

Los ataques de suplantación por correo cuestan a las organizaciones un promedio de 1,6 millones de dólares por incidente, según datos del FBI. Sin protocolos de autenticación, los atacantes pueden fácilmente falsificar los dominios de los clientes en la cabecera From y hacerse pasar por ejecutivos, clientes o socios. Estos ataques de compromiso por correo tienen éxito porque los protocolos estándar de email carecen de verificación de remitente integrada.

Para los MSPs, el riesgo se multiplica por toda tu base de clientes. Un solo incidente de suplantación que afecte a un cliente puede dañar tu reputación y despertar preocupaciones del resto sobre su propia seguridad. El impacto financiero va más allá de las pérdidas directas: los clientes afrontan costes de respuesta a incidentes, investigaciones forenses, honorarios legales, multas regulatorias y notificación a clientes. El daño reputacional puede persistir mucho después de superar la crisis inmediata.

Los protocolos de autenticación protegen la reputación del dominio y la entregabilidad en toda la cartera de clientes. Los principales proveedores de correo como Google, Microsoft y Yahoo ahora exigen SPF y DKIM para remitentes masivos, y utilizan el cumplimiento de DMARC como señal para decidir si el correo llega a bandeja de entrada o spam [3].

Además de proteger el correo saliente, estos protocolos defienden a los clientes y socios de tus clientes de recibir correos falsificados. Los reportes DMARC te dan visibilidad sobre quién está enviando correo en nombre de cada dominio, incluyendo servicios legítimos y posibles atacantes. Para MSPs, esa visibilidad centralizada en todos los dominios de clientes es un potente diferenciador.

SPF y DKIM cumplen roles complementarios en la pila de autenticación. SPF valida que el servidor emisor esté autorizado según la IP, pero no verifica el contenido del mensaje ni la cabecera visible From. DKIM confirma la integridad del mensaje y aporta autenticación criptográfica, pero no requiere que el dominio firmante coincida con el del From.

Aquí es donde DMARC resulta esencial. DMARC exige "alineación" entre el dominio autenticado por SPF o DKIM y el que se muestra en From. Esta comprobación impide una técnica de suplantación común en la que los atacantes pasan SPF usando su propio dominio en mail-from, mientras muestran el dominio del cliente en From visible.

• Capa 1: Validación de infraestructura (SPF) Valida la IP del servidor emisor. Validación rápida por DNS. Se rompe con reenvío.
• Capa 2: Validación del mensaje (DKIM) Valida que el mensaje no ha sido alterado. Firma criptográfica. Sobrevive al reenvío.
• Capa 3: Aplicación de políticas (DMARC) Requiere alineación con From. Aplica políticas de aprobación/cuarentena/rechazo. Coordina los resultados de SPF y DKIM.

Los MSPs suelen implementar los tres protocolos por fases en sus clientes. Comienzas publicando registros SPF y DKIM, luego añades DMARC con política "none" para recolectar datos sin afectar el flujo de correo. Según identifiques y autorices los emisores legítimos de cada cliente, avanzas gradualmente hacia políticas más estrictas.

Los protocolos también ofrecen valor según el origen del correo. SPF funciona bien para envíos directos desde la infraestructura del cliente, pero tiene limitaciones con reenvíos. DKIM sobrevive al reenvío porque la firma viaja con el mensaje.

La configuración de SPF comienza identificando todos los servicios y servidores que envían correo usando el dominio del cliente: servidores de correo, plataformas de marketing, sistemas CRM, y servicios de terceros. Cada emisor legítimo debe añadirse al registro SPF mediante IPs o mecanismos "include".

La fase de descubrimiento suele revelar emisores inesperados. Los MSPs suelen encontrar que los clientes usan más servicios de correo de los que pensaban, desde sistemas de notificación automática hasta plataformas de tickets o herramientas de RRHH. Documentar esto ayuda a identificar patrones comunes y establecer plantillas.

El registro SPF es un TXT en el DNS con una sintaxis específica. Un registro básico sería "v=spf1 ip4:192.0.2.1 include:_spf.google.com -all", donde "-all" indica que las IPs no autorizadas deben fallar la autenticación. El registro debe ser menor a 255 caracteres y no superar 10 consultas DNS o dejará de funcionar.

El límite de 10 consultas DNS es un obstáculo frecuente que rompe la autenticación sin avisar. Cada "include" cuenta como una consulta, y algunos servicios encadenan varios. Si un registro SPF supera el límite, los servidores receptores lo marcan como fallido y pueden bloquear todo el correo legítimo. Puede que necesites aplanar los registros SPF convirtiendo "includes" en IPs o consolidando servicios para no sobrepasar el límite. Para los MSPs con múltiples clientes, monitorear el número de consultas es una tarea crítica.

Implementar DKIM requiere generar un par de claves pública-privada y configurar el servidor de correo para firmar los mensajes salientes con la clave privada. Debes publicar la clave pública como registro TXT en DNS en un subdominio selector como "selector1._domainkey.clientdomain.com". La mayoría de las plataformas de correo ofrecen herramientas para generar claves y configurar la firma DKIM.

Fase de configuración SPF

• Audita todos los servicios de envío de correo de cada cliente
• Documenta direcciones IP y mecanismos include
• Crea el registro SPF con prefijo v=spf1
• Verifica que no supere 10 consultas
• Prueba con herramienta de validación SPF
• Púbicalo en DNS y verifica la propagación

Fase de configuración DKIM

• Genera un par de claves de 2048 bits
• Configura el servidor de correo con la clave privada
• Publica la clave pública en DNS
• Activa la firma DKIM para todo el correo saliente
• Envía mensajes de prueba y verifica cabeceras
• Coordina con servicios de terceros

Fase de configuración DMARC

• Comienza con política p=none (solo monitoreo)
• Configura dirección de reporte agregado (rua=)
• Publica el registro DMARC en DNS
• Monitorea los reportes durante 2-4 semanas
• Identifica y corrige fallos de autenticación
• Pasa a p=quarantine y después a p=reject

La longitud de clave es importante en la seguridad de DKIM. Usa como mínimo claves de 1024 bits, aunque 2048 bits es mejor contra ataques futuros. Algunos MSPs rotan las claves DKIM periódicamente como mejor práctica en todos los entornos de clientes.

Para DMARC, tienes que crear un registro TXT en "_dmarc.clientdomain.com" que especifique la política y preferencias de reporte. Empieza con "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourmsp.com" para recolectar datos sin bloquear correos. El tag rua dirige los reportes agregados a tu bandeja, permitiéndote monitorear resultados de autenticación de todos los clientes desde un solo lugar.

Los reportes llegan como archivos XML mostrando los resultados de autenticación de todos los correos enviados desde cada dominio cliente. Sin un análisis automatizado, estos reportes son difíciles de interpretar a gran escala. Verás qué fuentes pasan o fallan SPF y DKIM, ayudando a descubrir problemas de configuración antes de imponer políticas más estrictas.

La guía completa de implementación DMARC explica cada etapa, del inicio hasta lograr enforcement en p=reject.

La pregunta no es qué protocolo elegir, sino en qué orden implementarlos. Los tres son necesarios para una seguridad integral. SPF y DKIM ofrecen los mecanismos de autenticación; DMARC los une mediante política y visibilidad.

Empieza con SPF porque es el más sencillo de implementar. Normalmente puedes desplegar SPF en pocas horas identificando fuentes de envío y publicando el registro DNS. SPF solo ya aporta protección básica y mejora la entregabilidad con los principales proveedores.

Añade DKIM después, pues ofrece autenticación más robusta que SPF solo. Las firmas criptográficas de DKIM no pueden falsificarse fácilmente y, a diferencia de SPF, sobreviven al reenvío de correo. La combinación de SPF y DKIM te da dos mecanismos independientes que DMARC puede usar.

Implementa DMARC al final, pues requiere que SPF y DKIM funcionen correctamente. Comienza con política de sólo monitoreo (p=none) para identificar emisores legítimos y avanza progresivamente a políticas de cuarentena y rechazo a medida que te asegures de la configuración.

Algunos MSPs se preguntan si pueden saltar protocolos o usar solo uno para ahorrar tiempo en los despliegues. Esto deja huecos importantes. SPF solo no detiene ciertos ataques; DKIM solo no aplica alineación con From. Solo DMARC proporciona la aplicación política que realmente bloquea correos falsificados.

Implementar la autenticación de correo manualmente en decenas o cientos de dominios implica gestionar múltiples registros DNS, analizar informes XML complejos y coordinarse con servicios de correo de terceros por cliente. La plataforma Red Sift OnDMARC automatiza el proceso, ayudando a los MSPs a alcanzar enforcement de DMARC en todos sus clientes en 6-8 semanas, frente a las 6-12 meses típicas manualmente.

La plataforma comienza monitorizando el ecosistema y detectando automáticamente todas las fuentes que envían correos en nombre de cada cliente. En vez de analizar informes DMARC en bruto, obtienes un panel visual que muestra qué fuentes están autenticadas y cuáles requieren atención en toda tu cartera.

OnDMARC categoriza automáticamente las fuentes de envío, distinguiendo entre servidores corporativos, servicios autorizados de terceros y posibles emisores maliciosos. Muestra exactamente qué servicios pasan la autenticación y cuáles requieren actualización de configuración por cliente.

La plataforma detecta errores de configuración en registros SPF, DKIM y DMARC y ofrece instrucciones claras de corrección. Cuando estés listo para aplicar enforcement DMARC, OnDMARC monitoriza el impacto y te alerta si algún correo legítimo se vería afectado. El sistema puede predecir el impacto de cambios antes de aplicarlos, reduciendo el riesgo de bloqueo de correo legítimo para tus clientes.

Para MSPs con múltiples clientes y entornos complejos, OnDMARC ofrece gestión y análisis centralizados. Puedes ver el estado de autenticación global y asegurar políticas coherentes de seguridad. Su arquitectura multiempresa permite gestionar todos los clientes desde una sola interfaz, conservando la segregación de datos adecuada.

La plataforma Red Sift OnDMARC escala desde pequeños MSPs hasta grandes proveedores de servicios de seguridad gestionada con cientos de dominios de clientes.

[1] "DMARC vs SPF vs DKIM - La comparación definitiva." courier.com. https://www.courier.com/guides/dmarc-vs-spf-vs-dkim

[2] "¿Qué son DMARC, DKIM y SPF?" Cloudflare. https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/

[3] "SPF, DKIM, DMARC: Los 3 pilares de la autenticación de correo." higherlogic.com, 2024-01-01. https://www.higherlogic.com/blog/spf-dkim-dmarc-email-authentication/