Cómo configurar los registros DKIM, SPF y DMARC para un servidor Zimbra.

DKIM, SPF y DMARC resuelven tres aspectos distintos de la autenticación de correo electrónico saliente, y una implementación fiable de Zimbra requiere que funcionen conjuntamente. SPF indica a los receptores qué sistemas tienen permiso para enviar correos con el dominio del sobre. DKIM añade una firma criptográfica vinculada a un dominio. DMARC comprueba si una identidad SPF o DKIM válida coincide con el dominio visible en el encabezado "De" del mensaje y, a continuación, publica una política de gestión e informes.

Un detalle importante de los estándares actuales es que, a partir de octubre de 2026, la especificación vigente del protocolo DMARC es la RFC 9989 , publicada en mayo de 2026. Esta reemplaza a la anterior RFC 7489 y modifica algunos detalles de implementación, como marcar la etiqueta antigua pctcomo histórica e introducir la tetiqueta de prueba. Esto es relevante si se copia un ejemplo antiguo de DMARC de una guía de Zimbra o un tutorial de DNS anterior.

Lo que necesitas antes de cambiar el DNS

Necesitas acceso administrativo a la consola de un MTA de Zimbra, acceso a la zona DNS pública autoritativa de tu dominio de envío y una lista completa de todos los sistemas que envían correo legítimamente utilizando ese dominio. Esta lista puede incluir tu servidor Zimbra, un servidor de retransmisión o de reenvío, plataformas de marketing, sistemas de gestión de incidencias, aplicaciones en la nube y cualquier servicio de correo de recuperación ante desastres.

Un error común es creer que publicar registros solo para el host de Zimbra es suficiente. Esto solo es suficiente cuando Zimbra es realmente el único remitente autorizado. SPF se evalúa con respecto a la identidad SMTP, y DMARC puede revelar remitentes de terceros olvidados una vez que se habilita la aplicación de políticas. Acción: realice un inventario de todas las fuentes de salida antes de publicar una política restrictiva de SPF o DMARC.

Paso 1: Generar la clave DKIM en Zimbra

Zimbra incluye la zmdkimkeyutilutilidad para la firma DKIM a nivel de dominio. La documentación oficial de Zimbra indica que debe ejecutarse en un servidor MTA. Para agregar datos DKIM a un dominio que aún no los tiene, cambie a la cuenta de Zimbra y ejecute:

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

El comando almacena los datos DKIM en la entrada de dominio LDAP de Zimbra e imprime el selector y el registro TXT público que necesita publicar. La documentación de firma DKIM de Zimbra también describe -qcómo consultar, -uactualizar y -reliminar los datos DKIM existentes.

En las instalaciones modernas de Zimbra, el valor exacto del selector puede diferir de los ejemplos que se muestran en línea. El selector no debe ser una palabra fija como defaulto zimbra; utilice exactamente el selector que imprime su servidor. Acción: copie el registro completo de la clave pública de la salida del comando en lugar de reconstruirlo manualmente.

Paso 2: Publicar el registro TXT de DKIM

Los verificadores DKIM buscan la clave pública en DNS bajo un nombre construido a partir del selector y ._domainkey. El mecanismo está definido en RFC 6376. En términos prácticos de un proveedor de DNS, el registro suele tener este aspecto:

Si introduce solo el nombre de la zona YOUR_SELECTOR._domainkeyo el nombre completo YOUR_SELECTOR._domainkey.example.comdepende de su panel de control DNS. Algunos proveedores añaden automáticamente el nombre de la zona. Acción: previsualice el nombre del registro completo final en su proveedor antes de guardarlo para no crear accidentalmente un nombre de zona ...example.com.example.com.

Paso 3: Cree un registro SPF TXT para el dominio remitente.

SPF se publica como un registro TXT de DNS en el dominio cuya autorización de envío se desea describir. El RFC 7208 exige registros TXT para SPF e indica que tener varios registros SPF con el mismo nombre de propietario produce un error permanente. En otras palabras, no cree un segundo v=spf1registro TXT solo porque añada otro servicio de correo.

Si su servidor Zimbra envía directamente desde una dirección IPv4 pública estable, un ejemplo mínimo es:

v=spf1 ip4:203.0.113.10 -all

Si todos los hosts a los que hacen referencia los registros MX de su dominio son remitentes salientes legítimos, puede usar mx; si un servicio de terceros publica un dominio de inclusión SPF, es posible que necesite un include:mecanismo. El registro exacto depende de la implementación, por lo que no existe una cadena SPF de Zimbra universalmente correcta.

Otro error común es asumir que ~allsiempre es más seguro que -all. La verdadera pregunta es si su inventario de remitentes autorizados está completo. Un estricto -alles razonable cuando lo es. Acción: autorice a cada remitente legítimo en un registro SPF, verifíquelo en producción y luego elija el calificador final allen función de esa evidencia.

Mantenga SPF razonablemente simple. RFC 7208 limita los mecanismos y modificadores que activan las consultas DNS a 10 durante la evaluación; exceder el límite puede resultar en permerror. Acción: cuente las inclusiones y otros mecanismos de expansión de DNS antes de agregar otro proveedor.

Paso 4: Publique primero el DMARC en modo de monitorización.

La política DMARC se publica en _dmarc.example.com. Un primer registro prudente es:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=noneSe solicita a los receptores que no modifiquen el manejo de los datos según la política DMARC mientras se recopilan. La ruadirección solicita informes agregados; el formato actual de los informes agregados se especifica en la RFC 9990. Utilice un buzón de correo o un servicio de informes capaz de procesar informes DMARC en lugar de una bandeja de entrada personal desatendida.

No copie ciegamente pct=10ejemplos pct=25de implementación de artículos anteriores. RFC 9989 se considera pcthistórico porque la experiencia operativa mostró una aplicación inconsistente. El estándar actual utiliza t=ypara probar el comportamiento cuando sea necesario. Acción: comience con p=noney analice los informes; no confíe en el muestreo porcentual como su mecanismo de seguridad.

Paso 5: Verifique los tres registros en el DNS público.

Una vez que el proveedor de DNS haya publicado los registros, consúltelos desde fuera del servidor autoritativo o desde un resolvedor que acceda al DNS público. Por ejemplo:

dig +short TXT example.com
dig +short TXT YOUR_SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com

Para SPF, confirme que solo existe una respuesta TXT que comience con v=spf1ese nombre de propietario. Para DKIM, confirme que el selector coincide exactamente con el valor almacenado actualmente por Zimbra. Para DMARC, confirme que existe un único registro de política DMARC utilizable con el nombre esperado.

La propagación de DNS depende de su proveedor, el TTL y la caché del resolvedor. Un cambio que aparece inmediatamente en un servidor de nombres autoritativo puede estar almacenado en caché en otro lugar. Acción: realice pruebas con al menos un resolvedor público independiente antes de culpar a Zimbra por una respuesta antigua.

Paso 6: Envía un mensaje real y verifica la alineación de la autenticación.

Envía un mensaje desde el dominio Zimbra a un buzón de correo de otro proveedor e inspecciona los encabezados completos del mensaje. Un resultado exitoso normalmente debería mostrar una firma DKIM y/o un resultado SPF correctos, además de que DMARC se haya completado correctamente, ya que al menos una identidad autenticada coincide con el dominio del remitente visible.

Aquí es donde se hace evidente otro concepto erróneo: DMARC no requiere que tanto SPF como DKIM pasen. Requiere una identidad SPF alineada que pase o una identidad DKIM alineada que pase. RFC 9989 define la alineación relajada como predeterminada para ambos aspf, adkimaunque se puede solicitar una alineación estricta con s. Acción: inspeccione Authentication-Resultse identifique exactamente qué mecanismo proporciona el pase DMARC alineado.

Paso 7: Pase de la supervisión a la aplicación de la ley solo después de que los informes estén limpios.

Una vez que sus datos DMARC muestren que los remitentes legítimos se autentican y se alinean correctamente, puede cambiar la política a p=quarantineo eventualmente p=reject. En el estándar actual, none, quarantine, y rejectexpresan la evaluación del propietario del dominio sobre el uso no autenticado, pero los receptores aún conservan la discreción de manejo local.

No lo considere p=rejectuna optimización de la entregabilidad. DMARC es principalmente un control de autenticación y abuso de dominio; no convierte automáticamente el correo deseado en confiable ni garantiza su llegada a la bandeja de entrada. Acción: convierta la aplicación en una decisión de seguridad basada en una cobertura de autenticación alineada, no en una promesa de mayores tasas de entrega.

Paso 8: Rotar las claves DKIM sin eliminar inmediatamente el registro DNS antiguo.

Para actualizar los datos DKIM de un dominio, Zimbra documenta lo siguiente:

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

El comando crea datos DKIM actualizados y genera una nueva entrada DNS. Zimbra recomienda específicamente mantener el registro TXT anterior en DNS durante un tiempo para que los mensajes firmados con la clave anterior puedan verificarse mientras están en tránsito o en cola. Acción: publique primero el nuevo selector, verifíquelo y conserve temporalmente el selector anterior antes de eliminarlo.

Referencia rápida: qué demuestra cada registro

Comprobaciones específicas de Zimbra que vale la pena realizar

La guía de protección de correo electrónico de Zimbra indica que el DKIM debe generarse por dominio y publicarse en el DNS público de cada dominio. También documenta problemas de alineación que pueden surgir con ciertos perfiles de usuario o el comportamiento de los autorespondedores en configuraciones antiguas. Estos detalles son específicos de cada caso, no universales: si su implementación utiliza alias, perfiles de usuario, retransmisiones o reescritura inusual del remitente del sobre, pruebe esas rutas de mensajes por separado.

Para una instalación de Zimbra multidominio, repita la configuración de DKIM y la publicación de DNS para cada dominio emisor. SPF y DMARC también son políticas de dominio; no asuma que un registro en un dominio alojado cubre automáticamente otro dominio no relacionado. Acción: cree una pequeña matriz de prueba para cada dominio y cada ruta de salida antes de habilitar la aplicación estricta de DMARC.

Lista de verificación de validación final

• Hay exactamente un registro SPF que comienza con v=spf1en cada dominio de envío.
• El registro SPF incluye todas las rutas de salida autorizadas y se mantiene dentro de los límites de procesamiento DNS de SPF.
• Zimbra firma los correos salientes con el selector almacenado para ese dominio.
• La clave pública DKIM correspondiente es visible en el DNS público en selector._domainkey.
• El registro DMARC TXT se publica en _dmarc.domainy utiliza la sintaxis actual.
• Los mensajes de prueba externos muestran que la verificación SPF o DKIM se ha realizado correctamente y, por lo tanto, la verificación DMARC también se ha realizado correctamente.
• Los informes agregados se revisan antes de pasar de la fase de monitoreo a la de cuarentena o rechazo.
• Los selectores DKIM antiguos se conservan temporalmente durante la rotación y solo se eliminan después del período de transición.

Si estas comprobaciones se superan, su servidor Zimbra no solo publica tres registros DNS, sino que presenta una cadena de autenticación coherente que los receptores remotos pueden validar. Esta distinción es más importante que copiar cualquier cadena de ejemplo de una guía, ya que las fuentes SPF correctas, el selector DKIM y la sincronización de la aplicación de DMARC dependen de cómo su propio correo electrónico sale realmente de la organización.