SPF, DKIM y DMARC en Zimbra: cómo proteger el correo corporativo

Un correo aparentemente enviado por la dirección de una empresa no siempre procede de sus servidores. La suplantación del remitente —spoofing— se utiliza en campañas de fraude, phishing y envío de mensajes no autorizados. Además, una autenticación de correo mal configurada puede provocar que mensajes legítimos terminen en spam o sean rechazados.

En una infraestructura Zimbra, SPF, DKIM y DMARC forman una parte esencial de la seguridad y de la entregabilidad. No son tres nombres para el mismo control: cada uno comprueba una pieza distinta de la identidad del remitente y, combinados, permiten publicar una política de autenticación para el dominio.

La configuración debe considerar todos los sistemas que envían correo en nombre de la organización: Zimbra, pasarelas SMTP, aplicaciones de facturación, formularios web, plataformas de marketing y servicios externos. Un cambio realizado sin ese inventario puede bloquear comunicaciones legítimas.

SPF, DKIM y DMARC: qué comprueba cada mecanismo

Una idea importante: DMARC no exige que SPF y DKIM pasen simultáneamente. Basta con que al menos uno de ellos pase y esté alineado con el dominio visible del remitente. Aun así, es recomendable configurar correctamente ambos para mejorar la resiliencia ante reenvíos y cambios en el flujo del correo.

1. SPF: autorizar los servidores que envían correo

SPF permite indicar qué direcciones IP y servicios están autorizados para emitir correo con un determinado dominio de sobre SMTP. El servidor receptor consulta el registro SPF publicado en DNS y compara el origen de la conexión con esa autorización.

Ejemplo ilustrativo para example.com :

example.com. IN TXT "v=spf1 ip4:203.0.113.10 ~all"

La IP pertenece a un rango reservado para documentación: el ejemplo no es una configuración para producción. Si también envía correo un proveedor externo, habrá que incorporar sus autorizaciones reales. Añadir un include ficticio o sin un SPF válido puede provocar un error de evaluación. Los calificadores ~all y -all indican, respectivamente, softfail y fail para los orígenes no autorizados; la decisión de entrega corresponde al receptor. La elección debe apoyarse en el inventario y en las pruebas de todos los emisores.

Errores frecuentes de SPF

• Publicar más de un registro TXT que empiece por v=spf1 para el mismo nombre de dominio: SPF debe tener un único registro lógico.
• Olvidar una pasarela SMTP o un servicio de envío externo.
• Superar el límite de 10 términos que provocan búsquedas DNS durante la evaluación, incluidos los anidados mediante include o redirect ; no es simplemente contar las IP autorizadas. El exceso provoca permerror , según el RFC 7208, apartado 4.6.4.
• Suponer que SPF autentica por sí solo la dirección visible de From: ; para ello hace falta la alineación evaluada por DMARC.
• Cambiar a -all antes de verificar el flujo de correo de todas las aplicaciones.

SPF debe revisarse cuando cambia el proveedor de correo, se incorpora una herramienta SaaS o se modifica el servidor de salida.

2. DKIM: firmar criptográficamente los mensajes enviados desde Zimbra

DKIM añade una firma al mensaje saliente. El receptor recupera la clave pública desde DNS y verifica que las partes firmadas del correo no se hayan modificado de forma incompatible con la firma.

En Zimbra, la firma DKIM se configura por dominio. La documentación oficial de Zimbra indica que la utilidad zmdkimkeyutil debe ejecutarse en un servidor MTA. Antes de cambiar nada, compruebe la versión instalada y si el dominio ya firma sus mensajes.

Como usuario zimbra , esta consulta permite revisar la configuración existente:

su - zimbra -c '/opt/zimbra/libexec/zmdkimkeyutil -q -d example.com'

La consulta puede mostrar la clave privada. No comparta su salida completa en tickets, capturas o documentos. En DNS se publica únicamente la clave pública.

Solo para un dominio que todavía no tenga DKIM configurado, el alta documentada es:

/opt/zimbra/libexec/zmdkimkeyutil -a -d example.com

La utilidad genera un selector y la clave pública para un TXT bajo un nombre similar a selector-ejemplo._domainkey.example.com . Utilice los valores reales de su instalación y compruebe que el panel DNS no añade el dominio dos veces.

Planifique el alta o la rotación, valide DNS y conserve temporalmente el TXT anterior cuando corresponda, para verificar mensajes ya firmados. Si una pasarela posterior modifica el mensaje, compruebe la firma en el destinatario final.

DKIM no sustituye SPF. Un mensaje puede tener una firma DKIM válida y, aun así, proceder de un flujo de envío que no cumpla la política SPF; DMARC evaluará si alguna autenticación válida está alineada.

3. DMARC: establecer una política para el dominio visible

DMARC conecta los resultados de SPF y DKIM con el dominio que el usuario ve en el campo From: . Si ninguno de los dos mecanismos pasa con alineación, el receptor puede aplicar la política publicada por el propietario del dominio.

La política se configura mediante un TXT en _dmarc.example.com . Un ejemplo inicial para observar resultados es:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

La dirección de informes debe existir y permitir procesar los reportes agregados XML. Si utiliza un analizador en otro dominio, revise la autorización DNS para recibir esos informes, descrita en el RFC 9990. La ausencia de informes no demuestra que todos los envíos sean correctos: no todos los receptores los generan.

Tres políticas habituales

• p=none : solicitar informes y observar fallos sin pedir una acción específica de bloqueo por DMARC.
• p=quarantine : solicitar que los mensajes que no superen DMARC se traten como sospechosos, por ejemplo enviándolos a spam.
• p=reject : solicitar que los mensajes que no superen DMARC sean rechazados.

La política expresa una solicitud al receptor; no garantiza que todos los proveedores apliquen exactamente la misma acción. No conviene pasar directamente a p=reject sin revisar primero los informes y las fuentes de envío legítimas.

4. La alineación: el detalle que más errores provoca

Una validación SPF o DKIM correcta no implica necesariamente que DMARC pase. El dominio autenticado debe estar alineado con el dominio visible en From: .

Por ejemplo, una empresa envía un mensaje visible como facturacion@example.com , pero una aplicación externa lo emite con un dominio de sobre SMTP propio del proveedor. SPF puede devolver pass para el dominio del proveedor y, sin embargo, no estar alineado con example.com . Si tampoco existe una firma DKIM válida y alineada con example.com , DMARC fallará.

Los proveedores suelen ofrecer firma DKIM con un dominio propio o un dominio de retorno compatible con la alineación SPF. La alineación relajada permite compartir el mismo dominio organizativo; la estricta exige coincidencia exacta. Los parámetros adkim y aspf determinan el modo, relajado por defecto. El RFC 9989 sustituye al RFC 7489 como especificación de DMARC.

Un reenvío puede romper SPF al cambiar la IP emisora; DKIM puede seguir siendo válido si el mensaje conserva las partes firmadas. Revise también listas de distribución y pasarelas que alteren el contenido.

5. Plan de implantación para reducir el riesgo de interrupciones

Para una empresa que utiliza Zimbra, recomendamos un despliegue progresivo:

1. Inventariar emisores: Zimbra, relays, ERP, CRM, impresoras, formularios, newsletters y proveedores externos.
2. Auditar DNS: comprobar registros SPF, selectores DKIM y existencia de una política DMARC previa; detectar duplicados o valores obsoletos.
3. Corregir SPF: consolidar autorizaciones y controlar el número de búsquedas DNS.
4. Activar o validar DKIM: firmar mensajes salientes desde Zimbra y comprobar los flujos de terceros.
5. Empezar en observación si no existe política: utilizar p=none con un buzón o analizador operativo. Si ya hay quarantine o reject , revisar el despliegue existente antes de modificarlo; no rebajar una política validada por seguir una receta inicial.
6. Revisar los informes: identificar fuentes desconocidas y corregir envíos legítimos que no estén alineados.
7. Ajustar la política según los resultados: decidir si se mantiene quarantine o se adopta reject según los informes, la validación de los emisores legítimos y las necesidades del dominio. Pasar a reject no es un objetivo obligatorio ni una consecuencia automática de haber aplicado quarantine .
8. Mantener la configuración: revisar los registros cuando cambien los servicios o proveedores de correo.

El plazo entre fases dependerá del volumen de mensajes, de la variedad de emisores y de la calidad de los informes recibidos. No existe una duración universal segura para todos los dominios.

6. Cómo comprobar SPF, DKIM y DMARC

Las consultas DNS son una primera verificación:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT selector-ejemplo._domainkey.example.com

Para DKIM, sustituya selector-ejemplo por el selector real. No utilice marcadores con < o > en un comando de shell: se interpretan como redirecciones. Estas consultas confirman la publicación de registros, pero no demuestran que un mensaje esté autenticándose correctamente.

La prueba completa consiste en enviar mensajes reales desde cada origen autorizado a buzones de distintos proveedores y revisar los encabezados de autenticación del receptor, especialmente el Authentication-Results añadido por el receptor de confianza, buscando resultados como spf=pass , dkim=pass y dmarc=pass . Recuerde que DMARC puede pasar con solo SPF o DKIM válido y alineado. También hay que comprobar el dominio autenticado, la alineación y la entrega final.

Conviene probar correos enviados directamente desde Zimbra, desde las aplicaciones empresariales y desde los servicios externos, no solo desde un cliente de correo habitual.

7. Qué no resuelven estos mecanismos

SPF, DKIM y DMARC reducen determinadas formas de suplantación del dominio y ayudan a la reputación y la autenticación del correo, pero no garantizan que todos los mensajes legítimos lleguen a la bandeja de entrada ni eliminan por sí solos el phishing.

No impiden registrar dominios visualmente parecidos al de la empresa, tampoco sustituyen el filtrado antispam, la protección de cuentas, MFA donde esté disponible, TLS, el mantenimiento del servidor ni la formación de los usuarios.

La autenticación debe formar parte de una estrategia más amplia de seguridad y operación del correo corporativo. En CorvanIT trabajamos con Zimbra como plataforma de correo y colaboración y ofrecemos soporte técnico Zimbra para empresas para revisar problemas de entrega, DNS, seguridad y mantenimiento.

Si su organización está valorando una renovación de la plataforma, también puede consultar nuestro servicio de migración Zimbra y el catálogo de servicios IT de CorvanIT.

¿Su dominio de correo está correctamente protegido?

Una política DMARC estricta aplicada sin pruebas puede provocar rechazos de correo legítimo. Por el contrario, una configuración incompleta puede facilitar la suplantación de identidad y dificultar la entrega de mensajes.

En CorvanIT revisamos la autenticación de correo, los registros DNS y los flujos de envío de entornos Zimbra, identificando riesgos y proponiendo cambios verificables.