mailcow Toolkit — guía

Antes de empezar

• mailcow-dockerized en Linux (probado con 2026-09 y 2026-09a), instalado por ejemplo en /opt/mailcow-dockerized.
• Acceso de root en el host y estos comandos: docker con docker compose, git, jq, flock, curl, tar, sha256sum y systemd.
• HTTPS saliente hacia medialab.works desde el servidor (comprobación de la licencia, prueba, actualizaciones del Toolkit).
• Tu clave de licencia, desde 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 el webmail (por ejemplo, webmail.example.com) en DNS, y un proxy inverso que pueda servirlo.
• Una carpeta para las copias de seguridad, por ejemplo /srv/backup/mailcow.
• Opcional, para DNS y Cloudflare: una cuenta de Cloudflare que contenga las zonas de tus dominios. Para averiguar las direcciones públicas del servidor, el Toolkit pregunta a ip4.mailcow.email y ip6.mailcow.email (como la propia comprobación DNS de mailcow).

Instalación

Descarga mailcow-toolkit-<version>.tar.gz desde tu cuenta de medialab.works, 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: dónde está instalado mailcow-dockerized (predeterminado /opt/mailcow-dockerized).
• --webmail-url: la dirección del webmail, https:// + nombre de host (se permite un puerto opcional). Sin ella, el botón de SOGo mantiene el comportamiento original de mailcow.
• --backup-dir: dónde van las copias de seguridad antes de las actualizaciones. Sin ella, Update now se ejecuta sin copia de seguridad previa (el instalador te lo advierte).
• --name: solo si tienes varias instalaciones de mailcow en el mismo host: un nombre por instalación (letras, dígitos y -).

El instalador coloca los archivos web en data/web de mailcow (excluido del git de mailcow), la carpeta compartida en data/hooks/phpfpm/.mlw-toolkit, el agente del host en /usr/local/sbin/mlw-mailcow-agent-<name>, los ajustes en /etc/mlw-mailcow-toolkit/<name>.conf, una copia de la versión instalada en /var/lib/mlw-mailcow-toolkit/<name>/package, y habilita cinco unidades de systemd: una que ejecuta las peticiones de la interfaz de administración, un temporizador que comprueba la licencia y busca una versión nueva de mailcow cuando el servidor arranca y una vez al día, mlw-mailcow-rdns-<name>.timer, que comprueba el DNS inverso cada 6 horas, y mlw-mailcow-domains-<name>.timer, que busca dominios nuevos de mailcow cada 2 minutos (no hace nada mientras la configuración automática de Cloudflare y el asistente de dominio nuevo están ambos desactivados) y, desde la 0.4.0, mlw-mailcow-accounts-<name>.timer, que ejecuta los trabajos de Sign-up for mailcow y Cashier for mailcow cada 5 minutos. Desde la 0.4.0, el paquete instala también Sign-up y Cashier (sus tablas mlw_su_* y mlw_ca_* en la base de datos de mailcow); se quedan desactivados hasta que cada uno tiene su propia licencia. Al final, recarga php-fpm y comprueba la licencia; hasta que la licencia esté activa, te indica que abras la sección License.

Actualizar el Toolkit: desde la sección License (ver más abajo), o ejecutando de nuevo install.sh de la versión nueva. Tu dirección de webmail y tu carpeta de copias de seguridad anteriores se conservan si las omites. Actualizar a la 0.3.0 desde la sección License habilita también los dos temporizadores nuevos; la página DNS & Cloudflare aparece entonces en el menú System.

Licencia y prueba gratuita

Abre System > Updates (Toolkit) (solo administradores). La sección License de arriba muestra el estado de la licencia y funciona incluso sin ella:

• Introduce tu clave de licencia y pulsa Activate. La clave está en tu cuenta de medialab.works.
• O empieza la prueba gratuita de 30 días: introduce tu dirección de correo, elige mensual o anual para después de la prueba y pulsa Start the free trial. Abre la página de pago de Stripe desde el enlace mostrado: ahí se pide la tarjeta y no se cobra durante los 30 días. Si la dirección ya tiene una cuenta de medialab.works, el enlace se le envía por correo en su lugar. La página activa entonces el Toolkit por sí misma en cuanto empieza la prueba. La prueba se puede usar una vez por servidor y por dirección de correo.
• Desde la 0.4.0, la página muestra una tarjeta License por producto (License · mailcow Toolkit, License · Sign-up for mailcow, License · Cashier for mailcow), cada una con su propia clave y su propia prueba. Una clave del paquete para mailcow se introduce en cada tarjeta. Las actualizaciones del paquete pueden iniciarse desde la tarjeta de cualquier producto con una licencia válida. Consulta la guía de Sign-up y la guía de Cashier.
• Con una licencia activa, la sección muestra la clave (parcialmente oculta), el tipo, la fecha de fin, la última comprobación, hasta cuándo funciona el Toolkit sin conexión y el identificador de este servidor. Check now comprueba al instante (como máximo dos veces por hora, junto con las actualizaciones y las vueltas a versiones anteriores).
• Remove from this server (tras marcar la confirmación) libera la licencia para que puedas usarla en otro servidor mailcow; el Toolkit se detiene aquí.

La licencia se comprueba cuando el servidor arranca y una vez al día. Si no se puede acceder a medialab.works, el Toolkit sigue funcionando 7 días después de la última comprobación exitosa.

Sin una licencia válida (todavía ninguna, caducada, eliminada, trasladada a otro servidor, o sin comprobar durante más de 7 días), las funciones del Toolkit se detienen: el botón de 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 la página muestra solo la sección License. No se borra nada.

Actualizar el Toolkit o volver a una versión anterior

Con una licencia válida, la sección License muestra la versión instalada y la última versión publicada:

• Update the Toolkit to x.y.z descarga el archivo firmado desde medialab.works, comprueba su tamaño y su SHA-256 y lo pone en cola para el agente del host, que lo vuelve a comprobar, ejecuta el install.sh de esa versión y conserva la versión anterior: si la instalación falla, se vuelve a instalar la versión anterior. La página muestra el progreso y se recarga al terminar.
• Roll back to x.y.z hace lo mismo con la versión anterior que permite tu licencia.

Si tu licencia no cubre la versión instalada (por ejemplo, una licencia de por vida cuyo período de actualizaciones terminó antes de esa versión), el Toolkit se detiene y la sección License ofrece Roll back to a la última versión que permite tu licencia, y el enlace para renovar el pase de actualizaciones.

El nombre de host del webmail

SOGo como buzón solo funciona en un nombre de host distinto del de la interfaz de mailcow, porque el navegador guarda una cookie de sesión por nombre de host.

1. Apunta el nombre de host del webmail (por ejemplo, webmail.example.com) a tu servidor en DNS.
2. En tu proxy inverso, sírvelo exactamente igual que la interfaz de mailcow: mismo backend, mismas cabeceras. Es el mismo mailcow, solo con otro nombre.
3. Dale un certificado TLS, como a la interfaz.

Activar SOGo como buzón

1. En mailcow.conf pon ALLOW_ADMIN_EMAIL_LOGIN=y y aplícalo después desde la carpeta de mailcow con docker compose up -d.
2. Asegúrate de que el administrador tiene el permiso Login as mailbox user.

Entonces, en E-Mail > Configuration, pestaña Mailboxes, el botón SOGo junto a un buzón abre una pestaña nueva en el host de webmail, con la sesión iniciada en SOGo como ese buzón. Tu pestaña de administrador sigue con la sesión iniciada. El enlace del botón funciona una sola vez y solo durante 60 segundos; si una pestaña muestra This link has expired, haz clic de nuevo en SOGo desde la lista de buzones.

El botón es solo para el administrador de la plataforma: los administradores de dominio conservan el botón SOGo de mailcow. Los buzones inactivos se rechazan.

Qué se registra: cada uso aparece en el registro de inicios de sesión de mailcow de ese buzón como un inicio de sesión SSO, y en el registro de auditoría del Toolkit (quién abrió qué buzón, cuándo y desde qué dirección).

Actualizar mailcow

Con una licencia válida, System > Updates (Toolkit) muestra debajo de la sección License:

• la versión instalada y la última comprobación (Up to date o Update available, con los cambios nuevos);
• la última ejecución (en curso, terminada o fallida) con su mensaje;
• el registro de la última actualización.

Check now busca una versión nueva al instante; si no, el servidor comprueba una vez al día.

Update now está disponible cuando la última comprobación encontró una versión nueva. Tras confirmar, se ejecuta, en este orden:

1. una copia de seguridad de crypt, redis, rspamd, postfix y mysql en tu carpeta de copias de seguridad, con el propio script de copias de seguridad de mailcow; las copias de más de 14 días se eliminan. Si la copia de seguridad falla, la actualización se detiene y no se cambia nada;
2. el update.sh de mailcow;
3. una espera de hasta 5 minutos hasta que todos los contenedores están en marcha y la interfaz responde.

Durante la actualización, los contenedores se reinician, así que el correo y la interfaz no están disponibles durante unos minutos. La página sigue mostrando el registro y se recarga sola cuando el servidor vuelve. Cuando la actualización termina, se envía un correo a la dirección de notificación.

Notificaciones

En la misma página, bajo Notifications, introduce la dirección que debe recibir los correos y guarda. El servidor envía entonces un correo por cada versión nueva de mailcow (no uno cada día) y otro cuando termina una actualización. Una dirección vacía desactiva los correos.

DNS y Cloudflare

Abre System > DNS & Cloudflare (solo administradores). Sin una licencia válida, la página muestra solo un aviso y nada se ejecuta en segundo plano.

Estado de los dominios

Arriba hay una fila de resumen (cuántos dominios están críticos o tienen advertencias) y un selector de Domain con cada dominio de mailcow y dominio alias, los peores primero, cada uno con su estado. La página recuerda el último dominio seleccionado.

• crítico: el correo no se puede entregar ni enviar, o acabará en spam: falta, está mal o tiene proxy el registro A (o AAAA) del host de correo, el MX, el SPF, el DKIM o el DMARC; no hay clave DKIM en mailcow; el DNS inverso del servidor es incorrecto; o SOGo todavía no conoce el dominio (ver SOGo y los dominios nuevos más abajo).
• advertencia: faltan registros opcionales: autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT.
• todo correcto: todo lo que el dominio necesita está en su sitio.

La vista del dominio enumera What needs attention, primero lo crítico, con por qué importa y How to fix it, y después el archivo de zona, las acciones de Cloudflare del dominio, el asistente y la tabla completa de registros. Los estados se actualizan cada 10 minutos en segundo plano; Re-check now comprueba el dominio seleccionado al instante. Los ajustes de todos los dominios (DNS inverso, credenciales y automatización de Cloudflare, puertos de servicio, el asistente, SOGo) están en secciones plegables debajo.

Los registros de cada dominio

La tabla de registros del dominio seleccionado muestra lo que mailcow necesita para él, según la propia comprobación DNS de mailcow:

• obligatorios: el registro A de MAILCOW_HOSTNAME, para el dominio cuya zona contiene el nombre de host (solo DNS en Cloudflare, porque SMTP e IMAP no pueden pasar por el proxy de Cloudflare); MX 10 hacia MAILCOW_HOSTNAME; SPF; DKIM con el selector y la clave de mailcow; DMARC;
• recomendados: CNAME de autodiscover y autoconfig hacia MAILCOW_HOSTNAME (solo DNS; también se acepta un registro A con la IP del servidor); registros SRV _autodiscover, _imaps, _submissions, _submission, _pop3s (cuando se permite POP3), _caldavs y _carddavs con un TXT path=/SOGo/dav/ (cuando SOGo está activo); con MTA-STS activo para el dominio en mailcow, el CNAME mta-sts, el TXT _mta-sts y el registro TLS-RPT _smtp._tls;
• para un dominio alias: MX, SPF, DKIM (la fila se queda en unknown hasta que mailcow tiene una clave para él), DMARC y, con MTA-STS, los registros TXT _mta-sts y _smtp._tls.

El SPF propuesto es v=spf1 ip4:<IPv4> -all. Cuando ya existe un SPF y no cubre el servidor, la propuesta añade la dirección del servidor y conserva el resto; cuando se apoya en include o redirect, la página te indica que lo compruebes.

DMARC: un registro DMARC válido que ya tengas se conserva tal cual. Si no, la propuesta es v=DMARC1; p=quarantine;, con rua=mailto:dmarc@<domain> (o postmaster@<domain>) solo cuando esa dirección existe en mailcow. Los informes TLS-RPT van a tls-rpt@ o postmaster@ del dominio.

Cada fila se compara con tres fuentes: DNS público, una zona importada (si subiste una) y la zona de Cloudflare (con credenciales). El estado es OK, missing (falta), different (distinto), proxied — must be DNS-only (con proxy; debe ser solo DNS), fix by hand (corregir a mano; por ejemplo, registros A donde debería haber un CNAME, o varios registros SPF) o unknown (desconocido; aún no hay clave DKIM en mailcow, o aún no se conoce la IPv4 pública).

Archivo de zona: exportar e importar

• Download BIND zone file guarda los registros del dominio como un archivo de zona. En Cloudflare, impórtalo desde DNS > Records > Import and Export > Import DNS records: los registros que deben quedar solo DNS llevan cf_tags=cf-proxied:false. Las filas aún unknown se omiten.
• Compare with a zone file lee una exportación de Cloudflare (DNS > Records > Import and Export > Export) o cualquier archivo de zona BIND, de hasta 1 MB, y añade una columna Imported zone a la comparación. Forget the imported file lo elimina.

IPv4 e IPv6

Por defecto, el Toolkit trabaja solo con IPv4: ningún registro AAAA, solo ip4: en el SPF, y el DNS inverso IPv6 no se comprueba. Un servidor que publica AAAA sin un PTR IPv6 coincidente ve cómo Gmail y otros rechazan su correo por IPv6. Cuando el PTR IPv6 del servidor esté definido, activa Use IPv6 (publish AAAA, SPF ip6, check the IPv6 rDNS) y guarda.

Puertos de servicio

La tarjeta Service ports (SRV records) define los puertos que anuncian los registros SRV: IMAPS (993), Submission (STARTTLS, 587), SMTPS (465), POP3S (995) y HTTPS (443, para autodiscover, CalDAV y CardDAV). Cada campo es opcional (1–65535). Si se deja vacío, el puerto sale de mailcow.conf cuando es un número simple, o es el puerto estándar cuando mailcow.conf enlaza una dirección como 127.0.0.1:12587 (delante hay un proxy o NAT); un HTTPS vacío usa el puerto de la página de administración. Debajo de cada campo, la página muestra el puerto en uso y de dónde sale. La exportación, la comparación y Cloudflare (manual y automático) usan todos estos puertos.

Credenciales de Cloudflare

Las acciones de Cloudflare de un dominio (la columna en vivo, la vista previa y la aplicación, Provision now) solo aparecen cuando las credenciales guardadas funcionan ahora y pueden editar el DNS de la zona de ese dominio; si no, la página indica por qué (sin credenciales, conexión rechazada, la zona no está en la cuenta o no está en los recursos de zona del token, o falta Zone > DNS > Edit). Run wizard funciona sin Cloudflare.

En la tarjeta Cloudflare, elige una de:

• API token (recomendado): en Cloudflare, My Profile > API Tokens > Create Token, con Zone > DNS > Edit y Zone > Zone > Read en todas las zonas. Añade Zone > Zone > Edit solo si el Toolkit puede crear zonas que falten. Si ese token se filtra, puede cambiar registros DNS y nada más, y puede revocarse por separado.
• Global API Key con el correo de la cuenta: también funciona, pero puede hacer de todo en toda la cuenta de Cloudflare (facturación, miembros, cada producto). Úsala solo si aceptas ese riesgo.

Check and save comprueba primero las credenciales con Cloudflare. Se guardan cifradas (AES-256-GCM) en la carpeta del Toolkit de tu servidor; la clave se guarda en el redis de mailcow, no junto al archivo, así que una copia de la carpeta o de las copias de seguridad de mailcow no las revela. No se vuelven a mostrar nunca: la página muestra solo el tipo y los últimos 4 caracteres. Remove the credentials las elimina y desactiva la configuración automática. Las credenciales se quedan en tu servidor y solo se envían a la API de Cloudflare.

Aplicar registros en Cloudflare

1. Selecciona el dominio. Los registros obligatorios y los mostrados como proxied están marcados; marca o desmarca los demás.
2. Preview changes for Cloudflare enumera lo que se crearía o actualizaría, con el valor ahora y después.
3. Apply to Cloudflare guarda primero una copia de seguridad JSON de toda la zona y después crea o actualiza solo esos registros. No se borra nada. Si la zona cambió desde la vista previa, no se aplica nada y vuelves a previsualizar; una vista previa caduca a los 15 minutos.

Cada copia de seguridad aparece bajo Cloudflare backups: Download guarda el JSON, Undo these changes revierte ese cambio (los registros actualizados recuperan sus valores antiguos; los registros creados se eliminan, solo si no se han cambiado desde entonces). Cada aplicación y reversión se escribe en el registro de auditoría del Toolkit.

Configuración automática de dominios nuevos

Con las credenciales guardadas, activa Configure new mailcow domains in Cloudflare by themselves. Entonces, en unos 2 minutos desde que se añade un dominio o dominio alias en mailcow (desde la interfaz o la API), el Toolkit coloca sus registros en la zona de Cloudflare existente:

• espera hasta 10 minutos la clave DKIM de mailcow; sin ella, define los demás registros y añade el DKIM después (lo reintenta cada hora);
• los registros que faltan se crean y los incorrectos se actualizan; el registro A del host de correo y los CNAME quedan solo DNS;
• los registros que no gestiona nunca se borran; una política SPF, DMARC o TLS-RPT distinta que ya exista se deja como está (existing policy) y se reporta (la vista previa manual aún puede actualizarla);
• se guarda una copia de seguridad de la zona antes de cada cambio, como con la aplicación manual;
• si la zona no está en Cloudflare, el dominio muestra zone missing. Con Create the zone in Cloudflare if it does not exist (necesita Zone > Zone > Edit o la Global API Key), el Toolkit la crea y muestra los Cloudflare nameservers que definir en tu registrador. Cuando las credenciales ven varias cuentas de Cloudflare, Cloudflare account for new zones elige la cuenta (por defecto, la primera);
• con E-mail the notification address when provisioning fails, un fallo se envía por correo a la dirección bajo Notifications en la página Updates (Toolkit); el Toolkit reintenta a los 15 minutos.

Los dominios que ya existen al activar esto se quedan como están: usa Provision now junto a un dominio para configurarlo de la misma manera.

Asistente de dominio nuevo

La tarjeta New domain wizard: role addresses crea, para cada dominio nuevo de mailcow, las direcciones de función como alias de mailcow, así que no cuentan para el límite de buzones del dominio:

• las direcciones: postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, cada una opcional, más tus propias partes locales (separadas por comas);
• Destination (all role addresses): a dónde entregan; cada dominio puede tener su propio destino en su vista (vacío = el global);
• dmarc@ y tls-rpt@ pueden ir a una dirección de reports separada;
• noreply@ usa el «discard silently» de mailcow (null@localhost): el correo dirigido a ella se acepta y se descarta.

Activa Create the role addresses for new domains by themselves (necesita un destino). El asistente se ejecuta antes de la configuración de Cloudflare, así que los registros DMARC y TLS-RPT de un dominio nuevo envían sus informes a su dmarc@ y tls-rpt@. Una dirección que ya existe como buzón o alias nunca se toca: se omite y se reporta. Los dominios alias se omiten, porque mailcow ya los asigna a las direcciones del dominio de destino. Los alias se crean con las propias funciones de mailcow, así que aparecen en el registro de mailcow. Los dominios que existían al activar el asistente se quedan como están: usa Run wizard junto a un dominio.

SOGo y los dominios nuevos

SOGo lee los dominios de mailcow cuando arranca. Un dominio añadido después es desconocido para SOGo, así que sus buzones muestran «Unauthorized» en SOGo y en el botón de SOGo del Toolkit hasta que SOGo se reinicia (la búsqueda fallida también se guarda en memcached).

Con una licencia válida, el Toolkit comprueba cada 2 minutos si SOGo conoce todos los dominios de mailcow. Cuando falta uno, reinicia solo el contenedor de SOGo y vacía memcached, unos 3 minutos después del primer dominio que falta (para que varios dominios nuevos compartan un reinicio) y como máximo una vez cada 10 minutos: en la práctica, entre 3 y 10 minutos después de añadir el dominio. Las sesiones de webmail se interrumpen durante unos segundos. Cada reinicio se escribe en el registro de auditoría.

Mientras un dominio espera, la página DNS muestra una advertencia con un botón Restart SOGo (el mismo botón está en la sección SOGo, con el último reinicio). Si marcas la propia opción Restart SOGo de mailcow al añadir el dominio, SOGo lo conoce al instante y no hay un segundo reinicio.

DNS inverso (PTR)

Otros servidores de correo comprueban que cada IP pública de tu servidor tiene un registro PTR igual a MAILCOW_HOSTNAME y que MAILCOW_HOSTNAME resuelve de vuelta a la misma IP (DNS inverso confirmado hacia delante). El Toolkit comprueba esto cada 6 horas para cada IPv4 pública (e IPv6, con Use IPv6); Check now en la página DNS lo ejecuta al instante.

Cuando la comprobación falla, aparece una ! roja junto al menú System en cada página de administración, y una fila Reverse DNS (PTR) en System > Information. Sin Use IPv6, una dirección IPv6 nunca lo provoca.

Para corregirlo: el registro PTR de una IP pertenece a quien es dueño de la IP, no a tu zona DNS. Defínelo en el panel de control de tu proveedor de alojamiento o VPS (a menudo «Reverse DNS» o «PTR» junto a la IP), o pídeselo a tu proveedor de internet, exactamente como MAILCOW_HOSTNAME. Después, asegúrate de que MAILCOW_HOSTNAME tiene un registro A con la misma IP (solo DNS en Cloudflare).

El servidor averigua sus direcciones públicas a través de ip4.mailcow.email / ip6.mailcow.email; si no, desde sus interfaces de red. Detrás de NAT o con varias direcciones, enuméralas en RDNS_IPS (ver Ajustes).

Ajustes

/etc/mlw-mailcow-toolkit/<name>.conf (el nombre predeterminado es default) contiene:

• BACKUP_DIR: la carpeta de copias de seguridad (vacía = sin copia de seguridad antes de actualizar, no recomendado);
• BACKUP_COMPONENTS: qué se copia en seguridad, por defecto crypt redis rspamd postfix mysql;
• BACKUP_KEEP_DAYS: cuánto tiempo se conservan las copias de seguridad, por defecto 14;
• RDNS_IPS: las IP públicas que comprobar para el DNS inverso, separadas por espacios, por ejemplo RDNS_IPS="203.0.113.10" (vacío = las direcciones detectadas);
• SOGO_DELAY y SOGO_MIN_GAP: la espera antes de reiniciar SOGo por un dominio nuevo y el tiempo mínimo entre dos reinicios, en segundos (por defecto, 180 y 600).

Tus cambios en este archivo se conservan cuando vuelves a instalar o actualizas el Toolkit desde la sección License; solo cambia BACKUP_DIR, y solo si pasas --backup-dir. Las opciones de DNS y Cloudflare se guardan desde la página, no en este archivo, y se conservan.

Quitar el Toolkit

sudo ./uninstall.sh --mailcow-dir /opt/mailcow-dockerized

Detiene y elimina las unidades de systemd (incluidos los temporizadores), los ajustes, el agente, la copia conservada del Toolkit y los archivos web, y limpia la lista de exclusiones del git de mailcow. La carpeta compartida también se va, con las credenciales cifradas de Cloudflare y las copias de seguridad de zonas de Cloudflare: descarga antes las copias que quieras conservar. Tus registros DNS en Cloudflare se quedan como están. Las copias de seguridad de mailcow se conservan. Las tablas de Sign-up y Cashier se quedan en la base de datos de mailcow, y los buzones, dominios y administradores de dominio que crearon se quedan en mailcow. Añade --name si instalaste con uno. Pulsa primero Remove from this server en la sección License si quieres usar la licencia en otro servidor.

Problemas frecuentes

El botón de SOGo sigue cambiando mi sesión de administrador. No se dio ninguna dirección de webmail en la instalación, la dirección de webmail tiene el mismo nombre de host que la interfaz, o el inicio de sesión en SOGo como buzón no está permitido (ALLOW_ADMIN_EMAIL_LOGIN=y y el permiso Login as mailbox user). Ejecuta de nuevo install.sh con --webmail-url y comprueba los dos ajustes.

La página Updates dice que el agente del host no está instalado o no está en marcha. Ejecuta de nuevo install.sh; comprueba systemctl status mlw-mailcow-agent-default.path.

La página muestra solo la sección License. La licencia no es válida: el mensaje de arriba indica por qué (aún sin clave, caducada, eliminada o trasladada, o sin comprobar durante más de 7 días). En el último caso, comprueba que el servidor llega a https://medialab.works y pulsa después Check now.

La actualización falló. La página indica en qué paso (copia de seguridad, update.sh o la comprobación de contenedores) y conserva el registro. Tras una copia de seguridad fallida no se cambió nada. Tras un update.sh o una comprobación de contenedores fallidos, lee el registro y corrige la causa como lo harías tras ejecutar update.sh a mano.

Hay una ! roja junto al menú System. La comprobación del DNS inverso falló: abre System > DNS & Cloudflare, sección Reverse DNS (PTR) of the server, para ver qué IP y por qué. Define el PTR en tu proveedor de alojamiento / VPS o de internet y pulsa después Check now.

Cloudflare rechazó las credenciales. Comprueba los permisos del token (Zone > DNS > Edit y Zone > Zone > Read en todas las zonas) o, para la Global API Key, el correo de la cuenta. El mensaje de Cloudflare se muestra en la página.

Un dominio muestra «zone missing». El dominio no es una zona en la cuenta de Cloudflare que ven las credenciales. Añádelo en Cloudflare, o activa Create the zone in Cloudflare if it does not exist; el Toolkit reintenta cada hora, o pulsa Provision now.

El registro SPF o DMARC quedó «left as it is (existing policy)». La configuración automática nunca reemplaza una política que ya tengas. Selecciona el dominio, marca el registro y usa Preview changes for Cloudflare si quieres el valor del Toolkit.

Los buzones de un dominio nuevo muestran «Unauthorized» en SOGo. SOGo todavía no conoce el dominio: la página DNS muestra una advertencia; espera unos minutos al reinicio automático o pulsa Restart SOGo.

No he recibido ningún correo. Comprueba que hay una dirección guardada bajo Notifications; se envía un correo por cada versión nueva, no cada día.