mailcow: abrir SOGo como cualquier buzón, actualizar desde la interfaz y configurar el DNS

El problema: tres tareas que te comen la semana

Si llevas mailcow-dockerized para ti o para unos cuantos clientes, conoces la rutina. Alguien te pide revisar un buzón, así que pulsas SOGo junto a él en la interfaz de administración y tu sesión de administrador desaparece: mailcow mantiene una sesión por nombre de host, así que la misma sesión pasa al buzón. Y si la sesión de administrador sigue abierta, SOGo te devuelve igualmente al panel.

Luego está la actualización. mailcow publica versiones a menudo, y actualizar significa una sesión SSH, update.sh y confiar en que te acordaste de la copia de seguridad. Y cada dominio de correo nuevo necesita sus registros MX, SPF, DKIM y DMARC configurados a mano en el proveedor de DNS, además de una comprobación del DNS inverso que nadie recuerda hasta que Gmail empieza a rechazar correo.

mailcow Toolkit es un plugin que resuelve las tres cosas desde tu propio mailcow, y sigue funcionando tras las actualizaciones de mailcow porque no modifica ningún archivo versionado. Este tutorial recorre la configuración una vez, para que las tareas diarias se conviertan en clics.

Requisitos

mailcow-dockerized en Linux (el Toolkit está probado con 2026-09 y 2026-09a), instalado por ejemplo en /opt/mailcow-dockerized, con docker compose y systemd.
Acceso root en el host, con git, jq, flock, curl, tar y sha256sum instalados.
HTTPS saliente hacia medialab.works desde el servidor (comprobación de licencia, prueba, actualizaciones del Toolkit).
Una clave de licencia de tu cuenta de medialab.works, o una dirección de correo para la prueba gratuita de 30 días.
Un segundo nombre de host para webmail (por ejemplo webmail.example.com) en DNS, servido por el mismo proxy inverso que la interfaz de mailcow.
Una carpeta de copias de seguridad, por ejemplo /srv/backup/mailcow.
Para SOGo como cualquier buzón: ALLOW_ADMIN_EMAIL_LOGIN=y en mailcow.conf y el permiso Login as mailbox user.
Opcional, para escribir registros DNS: una cuenta de Cloudflare y un token de API con Zone > Zone > Read y Zone > DNS > Edit.

Paso 1 — Instalar el Toolkit

Descarga mailcow-toolkit-<version>.tar.gz desde tu cuenta, descomprímelo en el host de mailcow y ejecuta, como root:

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized \
  --webmail-url https://webmail.example.com --backup-dir /srv/backup/mailcow

--mailcow-dir es donde está mailcow (por defecto /opt/mailcow-dockerized).
--webmail-url es la dirección de webmail, https:// más el nombre de host (se permite un puerto opcional). Si lo omites, el botón de SOGo mantiene el comportamiento original de mailcow.
--backup-dir es donde van las copias de seguridad previas a las actualizaciones. Si lo omites, Update now se ejecuta sin copia de seguridad previa y el instalador te avisa.
--name solo es necesario si tienes varias instalaciones de mailcow en un mismo host.

El instalador activa cinco unidades de systemd, entre ellas un temporizador diario para la comprobación de versión y licencia, uno que comprueba el DNS inverso cada 6 horas y uno que busca dominios nuevos de mailcow cada 2 minutos. Al final recarga php-fpm y te pide abrir la sección License.

Paso 2 — Activar la licencia

Abre System > Updates (Toolkit) como administrador. La sección License de la parte superior funciona incluso sin licencia: introduce tu clave y pulsa Activate, o inicia la prueba gratuita de 30 días con tu dirección de correo y abre el enlace de pago de Stripe que se muestra (la tarjeta se pide ahí y no se cobra durante la prueba). La página activa el Toolkit por sí sola en cuanto empieza la prueba. Sin una licencia válida, las funciones del Toolkit se detienen y no se borra nada.

Paso 3 — Un nombre de host de webmail aparte

Aquí está el truco para mantener tu sesión de administrador. Tu navegador guarda una cookie de sesión por nombre de host, así que SOGo necesita su propio nombre.

Apunta webmail.example.com a tu servidor en DNS.
En tu proxy inverso, sírvelo exactamente igual que la interfaz de mailcow: mismo backend, mismas cabeceras. Es el mismo mailcow, solo bajo otro nombre.
Dale un certificado TLS, como a la interfaz.

Si ya instalaste con --webmail-url, esto está hecho. Si no, vuelve a ejecutar install.sh desde la versión nueva; tu dirección de webmail y tu carpeta de copias de seguridad anteriores se conservan cuando los omites.

Paso 4 — Activar SOGo como cualquier buzón

En mailcow.conf define ALLOW_ADMIN_EMAIL_LOGIN=y y luego aplícalo desde la interfaz de mailcow.
Asegúrate de que el administrador tiene el permiso Login as mailbox user.

A partir de ahí, el botón SOGo de la lista de buzones (para el administrador de la plataforma; los administradores de dominio conservan el botón propio de mailcow) abre SOGo como ese buzón, en una pestaña nueva, mientras tu pestaña de administrador sigue con la sesión iniciada. El traspaso usa un token de un solo uso, válido 60 segundos y usado una sola vez; en el host de webmail se inicia una sesión de buzón nueva que nunca hereda el rol de administrador. Los buzones inactivos se rechazan, siguiendo las propias reglas de mailcow.

Cada uso queda registrado dos veces: en el registro de inicio de sesión de ese buzón en mailcow, como inicio de sesión SSO, y en el registro de auditoría del Toolkit, con quién lo abrió y desde qué dirección. Esto es lo que gusta a auditores y clientes.

Paso 5 — Actualizaciones desde la interfaz, con copia de seguridad previa

Abre System > Updates (Toolkit). La página muestra la versión de mailcow instalada, la última comprobación y los cambios nuevos. El servidor comprueba a diario si hay una versión nueva de mailcow y envía un correo por cada versión nueva a la dirección que configures en la página.

Cuando quieras, pulsa Update now. El Toolkit primero hace una copia de seguridad (crypt, redis, rspamd, postfix y mysql, conservada 14 días), luego ejecuta el update.sh propio de mailcow y después espera hasta que todos los contenedores estén en marcha y la interfaz responda. El registro se muestra en directo en la página.

Hay dos garantías que importan: si la copia de seguridad falla, la actualización se detiene y no se cambia nada; si update.sh falla o un contenedor no arranca, la página lo indica y conserva el registro. La página sigue el idioma de la interfaz de mailcow, inglés o rumano.

Paso 6 — Registros DNS para cada dominio

Abre System > DNS & Cloudflare (solo administradores). Para cada dominio de mailcow y dominio alias, lista los registros que mailcow necesita, siguiendo la propia comprobación de DNS de mailcow:

Obligatorios: el registro A de MAILCOW_HOSTNAME (solo DNS en Cloudflare), MX 10 hacia MAILCOW_HOSTNAME, SPF, DKIM (el selector y la clave de mailcow) y DMARC.
Recomendados: los CNAME de autodiscover y autoconfig (solo DNS), los registros SRV de autodiscover, IMAPS, submission, SMTPS, POP3S (cuando POP3 está permitido), CalDAV y CardDAV con su TXT path=/SOGo/dav/ (con SOGo), y MTA-STS y TLS-RPT cuando MTA-STS está activo para el dominio.
Los dominios alias reciben MX, SPF, DKIM, DMARC y, con MTA-STS, sus registros TXT.

Cada registro se compara con el DNS público, con un archivo de zona que subas (una exportación de Cloudflare o cualquier archivo BIND) y, con credenciales de Cloudflare, con la zona activa de Cloudflare. Los estados son OK, missing, different, proxied (debe ser solo DNS), fix by hand o unknown.

Dos valores por defecto te evitan problemas. Solo IPv4 por defecto: sin registro AAAA y con un SPF de v=spf1 ip4:<IPv4> -all; el ajuste Use IPv6 añade AAAA, ip6: y la comprobación del DNS inverso de IPv6, porque un servidor que publica AAAA sin un PTR de IPv6 correspondiente ve su correo por IPv6 rechazado por Gmail y otros. Y DMARC: una política válida existente se conserva; si no, obtienes v=DMARC1; p=quarantine;, con informes a dmarc@ o postmaster@ solo cuando esa dirección existe. Los puertos SRV siguen mailcow.conf y se pueden definir a mano para servidores detrás de un proxy o NAT.

Download BIND zone file te da un archivo que Cloudflare importa en DNS > Records > Import and Export, con cf_tags=cf-proxied:false en los registros que deben quedarse solo DNS.

Paso 7 — Aplicar en Cloudflare con seguridad

Con un token de API con permisos acotados (recomendado) o la Global API Key, marca registros, previsualiza los cambios y aplícalos. Primero se guarda una copia de seguridad JSON de la zona y el cambio se puede deshacer; solo se crean o actualizan los registros seleccionados, no se borra nada y cada cambio va al registro de auditoría. Las credenciales se comprueban con Cloudflare, se guardan cifradas en tu servidor y no se vuelven a mostrar. Las acciones de Cloudflare de un dominio aparecen solo cuando las credenciales guardadas pueden editar el DNS de esa zona; si no, la página explica por qué.

Paso 8 — Deja que los dominios nuevos se configuren solos

Hay dos funciones desactivadas hasta que las configures:

Configuración automática de Cloudflare: en unos 2 minutos desde que se añade un dominio o dominio alias en mailcow (interfaz o API), sus registros se crean en la zona de Cloudflare existente. Los registros incorrectos se actualizan, los registros no relacionados nunca se borran y una política SPF, DMARC o TLS-RPT distinta existente se deja como está. Una zona que falta se notifica, o se crea si lo permites; los fallos se te pueden enviar por correo.
Asistente de dominio nuevo: las direcciones de rol (postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, cada una opcional, más las tuyas) se crean como alias hacia una dirección que elijas, así que no cuentan para el límite de buzones. noreply@ descarta el correo en silencio. Un buzón o alias existente nunca se toca.

Los dominios que ya existen cuando activas una función se dejan como están; Provision now y Run wizard los procesan uno a uno.

Paso 9 — Vigilar el PTR y el estado de cada dominio

El Toolkit comprueba el DNS inverso cada 6 horas y muestra un «!» rojo en el menú de administración cuando falla. La página de DNS se abre con un resumen y un selector de todos los dominios y dominios alias, primero los peores: crítico (el correo no se puede entregar ni enviar, o acabará en spam), advertencia (faltan registros opcionales) o todo correcto, con una explicación de qué va mal y cómo resolverlo para cada dominio. Los estados se actualizan cada 10 minutos en segundo plano; Re-check now comprueba un dominio al momento. Se recuerda el último dominio seleccionado.

Consejos y resolución de problemas

SOGo dice «Unauthorized» para un dominio nuevo. SOGo lee los dominios de mailcow al arrancar, así que un dominio añadido después le es desconocido. Desde la 0.4.0 el Toolkit detecta esos dominios cada 2 minutos y reinicia solo el contenedor de SOGo (y vacía memcached), en unos 3 a 10 minutos desde que se añade el dominio: una vez para varios dominios nuevos, como máximo cada 10 minutos y solo con una licencia válida. Cada reinicio va al registro de auditoría.
El botón de SOGo se comporta como el mailcow original. Comprueba que se pasó --webmail-url, que ALLOW_ADMIN_EMAIL_LOGIN=y está aplicado y que el administrador tiene el permiso Login as mailbox user.
Update now aparece en gris o se ejecuta sin copia de seguridad. La carpeta de copias de seguridad viene de --backup-dir; vuelve a ejecutar install.sh para definirla.
Un registro aparece como proxied. Ese registro debe ser solo DNS en Cloudflare; la exportación del archivo de zona los marca con cf_tags=cf-proxied:false.
Servidor detrás de un proxy o NAT. Define los puertos SRV a mano en la página de DNS; si no, siguen mailcow.conf.
Sin conexión con medialab.works. Tras la última comprobación correcta, el Toolkit sigue funcionando 7 días.
Actualizar el propio Toolkit. Usa la sección License: descarga el archivo firmado, comprueba el tamaño y el SHA-256 y conserva la versión anterior, así que una instalación fallida se revierte. install.sh desde una versión más nueva también funciona.

Conclusión

Ninguna de estas tres tareas es difícil; solo son fáciles de olvidar. Un nombre de host de webmail aparte convierte SOGo en una vista segura, auditada y de un clic de cualquier buzón mientras tu sesión de administrador sigue abierta. Un botón de actualización con copia de seguridad previa elimina el paso por SSH y las conjeturas. Y una página de DNS que compara cada dominio con el DNS público y con Cloudflare, más una comprobación del PTR cada 6 horas, detecta los problemas antes que un destinatario. Como el Toolkit no modifica ningún archivo versionado de mailcow, sobrevive a las actualizaciones de mailcow, así que lo configuras una sola vez.

La guía de usuario detalla cada ajuste, el changelog indica qué añadió cada versión y nuestra base de conocimiento tiene más para quienes gestionan sus propios servidores. ¿Dudas? Ponte en contacto.

Esta publicación se redactó con ayuda de IA a partir de la documentación de nuestros productos o de las fuentes indicadas y se revisó automáticamente antes de publicarse.