mailcow Toolkit

mailcow-dockerized mantiene una sola sesión por nombre de host. Cuando un administrador hace clic en SOGo junto a un buzón, esa misma sesión pasa al buzón: SOGo se abre, pero el administrador ya no tiene la sesión iniciada en la interfaz de administración, y mientras la sesión de administrador está abierta, SOGo te devuelve al panel de administración. Actualizar mailcow implica una sesión SSH y update.sh. Cada dominio de correo nuevo necesita sus registros MX, SPF, DKIM y DMARC, configurados a mano en el proveedor de DNS. mailcow Toolkit resuelve las tres cosas, dentro de tu propio mailcow, y sigue funcionando después de las actualizaciones de mailcow.

Qué hace

SOGo como cualquier buzón, conservando la sesión de administrador

• El botón SOGo de la lista de buzones (solo para el administrador de la plataforma; los administradores de dominio conservan el botón de mailcow) abre SOGo como ese buzón, en una pestaña nueva. Tu pestaña de administración sigue con la sesión iniciada.
• SOGo se ejecuta en un nombre de host de webmail independiente (por ejemplo, webmail.example.com), así que tiene su propia cookie de sesión, separada de la interfaz de administración.
• El traspaso usa un token de un solo uso, válido 60 segundos y utilizable una vez. En el host del webmail se inicia una sesión de buzón nueva; nunca hereda el rol de administrador.
• Usa las propias reglas de mailcow: necesita ALLOW_ADMIN_EMAIL_LOGIN=y y el permiso Login as mailbox user, y los buzones inactivos se rechazan.
• Cada uso queda registrado: en el registro de inicios de sesión de mailcow de ese buzón (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.
• Sin nombre de host de webmail, el botón mantiene el comportamiento original de mailcow.

Actualiza mailcow desde la interfaz de administración

• Una página nueva, System > Updates (Toolkit), muestra la versión de mailcow instalada, la última comprobación y los cambios nuevos.
• El servidor busca una versión nueva de mailcow cada día y envía un correo por cada versión nueva a la dirección que configures en la página.
• Update now primero hace una copia de seguridad (crypt, redis, rspamd, postfix y mysql, conservada 14 días), luego ejecuta el propio update.sh 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.
• 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.

Registros DNS y Cloudflare

Novedad de la 0.3.0: la página System > DNS & Cloudflare (solo administradores) enumera, para cada dominio y dominio alias de mailcow, los registros que necesita mailcow, siguiendo la propia comprobación de DNS de mailcow:

• Obligatorios: el registro A de MAILCOW_HOSTNAME (solo DNS en Cloudflare; se indica para el dominio cuya zona contiene el nombre de host), MX 10 hacia MAILCOW_HOSTNAME, SPF, DKIM (el selector y la clave de mailcow) y DMARC.
• Recomendados: los CNAME autodiscover y autoconfig (solo DNS), los registros SRV para autodiscover, IMAPS, submission y 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 en mailcow.
• 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 de Cloudflare en vivo. El estado es OK, missing (falta), different (distinto), proxied (con proxy; debe ser solo DNS), fix by hand (corregir a mano) o unknown (desconocido).
• Download BIND zone file genera un archivo que Cloudflare importa (DNS > Records > Import and Export), con cf_tags=cf-proxied:false en los registros que deben quedarse solo DNS.
• Solo IPv4 por defecto: ningún registro AAAA y un SPF v=spf1 ip4:<IPv4> -all. El ajuste Use IPv6 añade AAAA, ip6: y la comprobación del DNS inverso IPv6. Un servidor que publica AAAA sin un PTR IPv6 coincidente ve cómo Gmail y otros rechazan su correo por IPv6.
• DMARC: una política válida existente se conserva; si no, v=DMARC1; p=quarantine;, con los informes (rua) a dmarc@ o postmaster@ del dominio, solo cuando esa dirección existe.
• Los puertos SRV (IMAPS 993, Submission 587, SMTPS 465, POP3S 995, HTTPS 443) siguen mailcow.conf y se pueden configurar a mano, para servidores detrás de un proxy o de NAT.
• Un estado para cada dominio: la página se abre con un resumen y un selector de todos los dominios y dominios alias, del peor al mejor: crítico (el correo no se puede entregar ni enviar, o acabará en spam: falta, está mal o tiene proxy el registro A del host de correo, el MX, el SPF, el DKIM o el DMARC, no hay clave DKIM, el DNS inverso es incorrecto o SOGo todavía no conoce el dominio), advertencia (faltan registros opcionales: autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT) o todo correcto. Se recuerda el último dominio seleccionado. Para cada dominio, la página explica qué está mal y cómo corregirlo. Los estados se actualizan cada 10 minutos en segundo plano; Re-check now comprueba un dominio al instante.
• Las acciones de Cloudflare de un dominio solo aparecen cuando las credenciales guardadas funcionan y pueden editar el DNS de la zona de ese dominio (token de API: Zone > Zone > Read y Zone > DNS > Edit); si no, la página dice por qué.
• Cloudflare: con un token de API con permisos limitados (recomendado) o con la Global API Key, marcas registros, previsualizas los cambios y los aplicas. 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 nunca.

Dominios nuevos que se configuran solos

• Configuración automática de Cloudflare (desactivada hasta que se guardan las credenciales): unos 2 minutos después de añadir un dominio o un dominio alias en mailcow (interfaz o API), sus registros se crean en la zona de Cloudflare existente. Los registros incorrectos se actualizan, los registros ajenos nunca se borran, y una política SPF, DMARC o TLS-RPT distinta que ya exista se deja como está. Una zona que falta se señala, o se crea si lo permites. Los fallos se te pueden enviar por correo.
• Asistente de dominio nuevo (desactivado hasta que se configura un destino): 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. Nunca se toca un buzón o alias existente.
• Los dominios que ya existen cuando activas una función no se tocan; Provision now y Run wizard los procesan uno a uno.

SOGo y los dominios nuevos

• SOGo lee los dominios de mailcow al arrancar, así que un dominio añadido después le resulta desconocido: sus buzones reciben «Unauthorized» en SOGo y con el botón SOGo.
• Novedad de la 0.4.0: cada 2 minutos, el Toolkit busca esos dominios y reinicia solo el contenedor de SOGo (y vacía memcached), entre 3 y 10 minutos después de añadir el dominio: una sola 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.
• Mientras un dominio espera, la página DNS muestra una advertencia y un botón Restart SOGo. La propia opción Restart SOGo de mailcow al añadir un dominio evita la espera.

Comprobación del DNS inverso (PTR)

• Cada 6 horas (y al pulsar Check now), el servidor comprueba que cada IPv4 pública (e IPv6, con Use IPv6) tenga un PTR igual a MAILCOW_HOSTNAME, y que MAILCOW_HOSTNAME resuelva de vuelta a ella.
• Cuando falla, aparece un ! rojo junto al menú System en todas las páginas de administración y una fila Reverse DNS (PTR) en System > Information. La página te explica cómo corregirlo: el PTR pertenece a quien es dueño de la IP (tu proveedor de alojamiento o de VPS, o tu proveedor de internet), no a tu zona DNS.

Licencia, prueba gratuita y actualizaciones del Toolkit

• La sección License en la parte superior de System > Updates (Toolkit) activa el Toolkit con tu clave de licencia, o inicia la prueba gratuita de 30 días con tu dirección de correo: la tarjeta se pide en la página de pago de Stripe y no se cobra durante los 30 días, y la página activa el Toolkit sola en cuanto empieza la prueba. La prueba se puede usar una vez por servidor y por dirección de correo.
• La licencia se comprueba al arrancar el servidor y una vez al día. Sin internet, el Toolkit sigue funcionando 7 días después de la última comprobación correcta.
• Sin una licencia válida, las funciones del Toolkit se detienen: el botón SOGo mantiene el comportamiento original de mailcow, la búsqueda de actualizaciones de mailcow, los correos y las actualizaciones no se ejecutan, las comprobaciones de DNS, el indicador del DNS inverso, Cloudflare y el asistente de dominio nuevo se detienen, y las páginas solo muestran la sección License o un aviso. No se borra nada; una licencia válida lo vuelve a activar todo.
• Con una licencia válida, la misma sección actualiza el Toolkit a la última versión o lo devuelve a la anterior: el archivo firmado se descarga de medialab.works, se comprueban su tamaño y su SHA-256, el agente del host ejecuta el instalador de esa versión y, si falla, se vuelve a instalar la versión actual. Las instalaciones existentes reciben la 0.4.0 de esta forma.
• Desde la 0.4.0, el paquete también contiene Sign-up for mailcow (registro por cuenta propia) y Cashier for mailcow (planes de pago a través de tu propia cuenta de Stripe), cada uno con su propia licencia y su propia prueba de 30 días; la página muestra una tarjeta License por producto, y el paquete para mailcow cubre los tres con una sola clave.

Sobrevive a las actualizaciones de mailcow

El Toolkit añade sus propios archivos junto a los de mailcow y no modifica ningún archivo controlado por mailcow: sus archivos web están excluidos del git de mailcow, la carpeta compartida está donde el git de mailcow no mira, y el agente del host y sus temporizadores se ejecutan desde systemd. Una actualización de mailcow deja el Toolkit en su sitio. Se admiten varias instalaciones de mailcow en un mismo host.

Requisitos

• mailcow-dockerized, probado con 2026-09 y 2026-09a, en Linux con docker compose y systemd.
• Acceso root en el host, con git, jq, flock, curl, tar y sha256sum instalados.
• El servidor debe poder llegar a medialab.works por HTTPS (comprobación de la licencia, prueba, actualizaciones del Toolkit).
• Para SOGo como buzón: ALLOW_ADMIN_EMAIL_LOGIN=y en mailcow.conf y el permiso Login as mailbox user para el administrador.
• Un segundo nombre de host para el webmail, dirigido a mailcow a través del mismo proxy inverso que la interfaz de mailcow.
• Para las copias de seguridad antes de las actualizaciones: una carpeta de copias de seguridad en el host (--backup-dir).
• Opcional, para escribir los registros en Cloudflare: una cuenta de Cloudflare que contenga las zonas de los dominios, y un token de API.

Preguntas frecuentes

¿Por qué SOGo me devuelve al panel de administración? Porque mailcow mantiene una sola sesión por nombre de host: con la sesión de administrador abierta, la sesión del buzón no puede existir a su lado en el mismo host. El Toolkit abre SOGo en un nombre de host de webmail independiente, donde el buzón tiene su propia sesión. Consulta la guía.

¿Modifica archivos de mailcow? No se modifica ningún archivo controlado por mailcow. sudo ./uninstall.sh elimina todo lo que añadió el Toolkit; las copias de seguridad de mailcow se conservan.

¿Qué pasa cuando termina la licencia? Las funciones del Toolkit se detienen y mailcow funciona como antes del Toolkit: el botón SOGo vuelve a cambiar la sesión de administrador, las actualizaciones se hacen por SSH y los registros DNS ya no se comprueban ni se escriben. No se borra nada, ni en mailcow ni en Cloudflare. Renueva la licencia, o introduce una clave nueva, en la sección License.

¿Puedo actualizar sin copia de seguridad? Si instalas sin --backup-dir, Update now se ejecuta sin hacer antes una copia de seguridad. Te recomendamos configurar una carpeta de copias de seguridad.

¿Necesito Cloudflare? No. Sin credenciales de Cloudflare, la página DNS sigue enumerando los registros, los compara con el DNS público y con un archivo de zona que subas, y te da un archivo de zona BIND para importar. Cloudflare solo hace falta para que los registros se escriban solos.

¿Puede borrar o estropear mis registros DNS? Solo crea o actualiza los registros que enumera, y nunca borra un registro. Antes de cada cambio se guarda una copia de seguridad JSON de la zona, y Undo these changes lo revierte (elimina solo los registros que creó ese cambio, si no se han editado desde entonces). La configuración automática conserva la política SPF, DMARC o TLS-RPT que ya tengas.

¿Por qué no hay ningún registro AAAA ni ip6: en el SPF? Porque IPv6 está desactivado por defecto: si un servidor publica AAAA sin un PTR IPv6 coincidente, Gmail y otros rechazan su correo por IPv6. Activa Use IPv6 en cuanto esté configurado el PTR IPv6.

Licencia

El Toolkit es de código abierto (GPL-3.0), como el propio mailcow. Lo que compras es la suscripción a las nuevas versiones, las actualizaciones y el soporte para un servidor mailcow: el Toolkit con su comprobación de licencia, cada versión nueva mientras la suscripción esté activa, y ayuda cuando algo no funciona. El Toolkit está hecho de scripts de shell, PHP y JavaScript, así que lo que recibes es el código fuente completo. Consulta la sección 11 del EULA.

mailcow Toolkit es código propio, escrito por MediaLab Works; no contiene código de terceros. Se ejecuta dentro de mailcow-dockerized y usa las propias funciones de mailcow (sesiones, permisos, update.sh, el script de copias de seguridad, la creación de alias); mailcow es un proyecto de código abierto independiente (GPL-3.0) de The Infrastructure Company GmbH, consulta Derechos de autor. Cloudflare es un servicio independiente, utilizado solo con tu propia cuenta y tus credenciales.