Instalar Stalwart como servidor de correo en un VPS

Qué concentra Stalwart en un solo binario

Stalwart es un servidor de correo que se ejecuta en un único VPS como un binario de Rust. Atiende SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV y WebDAV desde el mismo proceso, e incluye su propio filtro de spam, su propio almacén de mensajes y su propio cliente ACME. Una pila convencional realiza ese mismo trabajo con Postfix, Dovecot, Rspamd, una base de datos para las cuentas y una herramienta de certificados independiente. Stalwart sustituye todos esos componentes por una sola unidad de servicio y un solo archivo de configuración en /etc/stalwart/config.json.

Todas las cifras, los nombres de configuración y los comandos siguientes proceden de la documentación, las páginas de versiones y el script de instalación de Stalwart. Se consultaron por primera vez el 28 August 2026 para la versión v0.16.19 (publicada el 24 August 2026) y se volvieron a comprobar el 12 October 2026, cuando la versión más reciente era v0.16.26 (publicada el 11 October 2026). Estos son comandos que debe ejecutar en su propio servidor. Cada uno va seguido de la comprobación que indica si se ejecutó correctamente.

Stalwart se distribuye bajo una licencia dual: GNU Affero General Public License v3.0 (AGPL-3.0) y Stalwart Enterprise License v2. Algunas funciones son exclusivas de la edición Enterprise. La lista documentada de endpoints HTTP las marca con /scim/v2/*. Lea las condiciones de la licencia antes de planificar una implementación basada en una función que todavía no haya probado.

Un solo binario reduce realmente el número de componentes. No reduce los dos factores que determinan si sus mensajes llegan a destino.

El puerto 25 y la reputación DNS no dependen del software que ejecute

El puerto TCP saliente 25 es la primera barrera. Muchos proveedores de VPS lo bloquean de forma predeterminada en las cuentas nuevas. Un puerto 25 bloqueado impide que el servidor entregue correo directamente al servidor de correo de otra persona. Compruébelo antes de instalar nada.

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 alt1.aspmx.l.google.com 25

Un resultado correcto muestra Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! en aproximadamente un segundo. Un bloqueo se manifiesta de una de estas dos formas. Si los paquetes se descartan en un punto intermedio, nadie devuelve un reset, por lo que nc espera los cinco segundos completos y después muestra nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out. Si el firewall los rechaza, devuelve un error ICMP. El rechazo de netfilter envía port unreachable, salvo que se le indique que envíe otro mensaje, como administratively prohibited. En ese caso, el fallo aparece de inmediato, normalmente como Connection refused o No route to host. En ambos casos, abra un ticket con el proveedor.

Si el proveedor no lo desbloquea, la única alternativa es usar un relay. Stalwart puede entregar todo el correo saliente a un smarthost mediante una ruta Relay. Su puerto predeterminado es 25, pero acepta cualquier valor entre 1 y 65535. También admite un interruptor implicitTls y los campos authUsername y authSecret para un relay autenticado en 465 o 587. El correo saldrá con la reputación del relay, no con la suya.

La segunda barrera es la valoración que las redes receptoras hacen de su dirección IP y su dominio. Esto incluye el DNS inverso de la IP, SPF, DKIM, DMARC y el historial de envío del bloque de direcciones que le haya sido asignado. La página de configuración DNS de Stalwart, tal como la consultamos el 28 August 2026, indicaba claramente dónde se realiza ese trabajo: los registros de DNS inverso "normalmente los configura el proveedor de hosting, no el propio Stalwart". Lo mismo se aplica al resto de esta configuración. Se administra en su zona DNS y en el panel de control del proveedor, no en el servidor de correo.

Por eso, esta página no vuelve a explicar esos registros. Ya tenemos una guía que lo hace: Configuración única de SPF, DKIM y DMARC para todo lo que envía correo. Si todavía no ha decidido si quiere ejecutar su propio correo, empiece por nuestro análisis honesto sobre si el correo autohospedado sigue mereciendo la pena. Elegir Stalwart no cambia ninguno de esos cálculos.

Qué necesita un VPS pequeño para ejecutar un servidor de correo Stalwart

La página de requisitos del sistema de Stalwart, consultada el 12 de octubre de 2026, proporciona estas cifras. El uso de memoria en reposo es de unos 100 MB. Una implementación pequeña para entre 5 y 10 usuarios funciona bien con 1 GB de RAM. Una configuración con poco tráfico y unos 5 usuarios funciona con un solo núcleo de CPU. La página añade que «a medida que aumentan la concurrencia y la actividad, serán necesarios más núcleos de CPU para mantener una latencia baja y un rendimiento alto». El límite predeterminado es de 8,192 conexiones simultáneas entre todos los servicios y se puede configurar.

La página no indica un tamaño mínimo de disco. Por tanto, dimensione el disco para el correo que espera conservar y deje espacio adicional para que el almacén pueda compactarse.

Deben funcionar tres rutas de salida. De lo contrario, el servidor puede parecer averiado por motivos que no tienen relación con el correo. Descarga el paquete de la interfaz web desde https://github.com/stalwartlabs/webui/releases/latest/. Accede a https://acme-v02.api.letsencrypt.org/directory para obtener certificados. Necesita DNS en el puerto UDP y TCP 53 para consultar registros MX y registros de autenticación. Un firewall de salida restrictivo que bloquee la primera ruta deja un servidor de correo en ejecución, pero sin interfaz de administración.

Instale una versión fijada, no latest

El instalador oficial es un script de shell. Léalo antes de ejecutarlo.

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
less install.sh
sudo sh install.sh

Leer ese script el 12 de octubre de 2026 muestra exactamente lo que hace. Crea una cuenta de servicio stalwart y los directorios que necesita. Después descarga desde https://github.com/stalwartlabs/stalwart/releases/latest/download. El binario se instala en /usr/local/bin/stalwart con el modo 0755. La configuración se guarda en /etc/stalwart/config.json, los datos en /var/lib/stalwart y los registros en /var/log/stalwart. Los tres directorios tienen el modo 0750 y pertenecen a stalwart. Se escribe un archivo de entorno en /etc/stalwart/stalwart.env con el modo 0640 y propiedad de root:stalwart. El script acepta un prefijo de instalación opcional y una opción --fdb para la compilación de FoundationDB. No acepta ningún argumento de versión.

Este último punto es importante. El script siempre descarga la versión más reciente, por lo que dos servidores preparados con una semana de diferencia no ejecutan necesariamente el mismo código. Fije el binario manualmente justo después. Esta es también la vía de actualización indicada en las notas de la versión v0.16.26: «Si está actualizando desde v0.16.x, sustituya el binario (o ejecute docker pull)». Entre el 24 de agosto y el 11 de octubre de 2026 se publicaron siete versiones de corrección, varias de ellas con correcciones de seguridad. Por tanto, fije la más reciente y cambie esa fijación de forma deliberada.

STALWART_TAG=v0.16.26
curl -fsSLO "https://github.com/stalwartlabs/stalwart/releases/download/${STALWART_TAG}/stalwart-x86_64-unknown-linux-gnu.tar.gz"
tar zxf stalwart-x86_64-unknown-linux-gnu.tar.gz
sudo systemctl stop stalwart
sudo install -m 0755 -o root -g root stalwart /usr/local/bin/stalwart
sudo systemctl start stalwart
systemctl is-active stalwart

systemctl is-active stalwart debería mostrar active. Si muestra cualquier otra cosa, lea journalctl -u stalwart -n 50. Cada archivo de una versión se publica junto con un paquete .sigstore.json correspondiente, por lo que la firma de la descarga se puede verificar antes de instalarla.

La unidad que escribe el script se ejecuta como User=stalwart y establece AmbientCapabilities=CAP_NET_BIND_SERVICE. Esa capacidad permite que una cuenta sin privilegios escuche en los puertos 25, 443, 465 y 993. Si más adelante escribe su propia unidad y omite esa línea, el servicio falla al iniciar porque un usuario normal no puede escuchar en un puerto inferior a 1024.

Dónde se imprime la primera contraseña de administrador

Stalwart se inicia en modo de arranque (bootstrap) y escribe una contraseña temporal de 16 caracteres en el registro del servicio una sola vez.

sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'

El asistente de configuración escucha en HTTP sin cifrar en el puerto 8080, por lo que no debe exponer ese puerto. En su lugar, cree un túnel desde su equipo local mediante SSH:

ssh -N -L 8080:127.0.0.1:8080 you@your-vps

A continuación, abra http://127.0.0.1:8080/admin e inicie sesión como admin con la contraseña del registro. El asistente solicita el nombre de host del servidor, el dominio de correo predeterminado, TLS, el almacenamiento, el directorio de cuentas, el registro y la gestión de DNS. Reinicie el servicio al finalizar y utilice https://<your-host>/admin a partir de ese momento.

Si la contraseña ha desaparecido del registro por desplazamiento, establezca una fija. /etc/stalwart/stalwart.env incluye entradas comentadas precisamente para esto, incluyendo STALWART_RECOVERY_ADMIN=admin:changeme, STALWART_RECOVERY_MODE=true y STALWART_RECOVERY_MODE_PORT (predeterminado 8080). Quite los comentarios, reinicie, inicie sesión y vuelva a comentar la entrada. La página de endurecimiento de Stalwart indica mantener esa credencial solo para emergencias y nunca iniciar sesión en IMAP, JMAP o WebDAV con una cuenta de administrador.

La misma página enumera qué escuchas mantener: el puerto 25 para SMTP entrante, 465 para envío con TLS implícito, 993 para IMAPS y 443 para todo lo relacionado con HTTP. Clasifica los puertos 587, 143, 4190, 110, 995 y 8080 como no esenciales y recomienda desactivar el 8080 una vez completada la configuración.

Ejecutarlo con Docker usando una etiqueta fijada

La imagen documentada es stalwartlabs/stalwart. La etiqueta v0.16.26 estaba disponible en Docker Hub el 12 de octubre de 2026, junto con una variante -alpine. La página de Docker de Stalwart recomienda la etiqueta secundaria v0.16 para producción. Fije en su lugar la versión del parche, por el mismo motivo que en el binario anterior.

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.26
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"
      - "465:465"
      - "993:993"
      - "443:443"
      - "127.0.0.1:8080:8080"
    volumes:
      - stalwart-etc:/etc/stalwart
      - stalwart-data:/var/lib/stalwart
volumes:
  stalwart-etc:
  stalwart-data:

Ese archivo contiene el comando docker run documentado, escrito como Compose, con los listeners no esenciales omitidos y el puerto de configuración enlazado a localhost. Inícielo y lea la misma línea de bootstrap:

docker compose up -d
docker compose logs stalwart 2>&1 | grep -A8 'bootstrap mode'

La página de Docker también documenta -e STALWART_RECOVERY_ADMIN=admin:mySecretPass como método para establecer una credencial fija durante el arranque. En Compose, la clave correspondiente es environment:, si prefiere usarla en lugar de leer los registros.

Si Compose es nuevo para usted, nuestro tutorial de Docker Compose para un VPS explica la estructura de archivos y el modelo de volúmenes con nombre que se utiliza aquí. Hay una advertencia especialmente importante para los servidores de correo: Docker publica los puertos escribiendo sus propias reglas de firewall, y esas reglas se procesan antes que las de ufw. Por eso, ufw deny 8080 no cierra un puerto publicado por Compose. Enlazarlo a 127.0.0.1 en la asignación de puertos es lo que realmente lo cierra. Por ese motivo el archivo anterior lo hace así, y el túnel SSH sigue siendo aplicable.

TLS sin certbot y su coste

Stalwart implementa ACME (automatic certificate management environment) directamente, por lo que no utiliza certbot ni un hook de renovación. La documentación enumera cuatro métodos de validación. HTTP-01 responde a una solicitud de desafío en el puerto 80. TLS-ALPN-01 presenta un certificado específico en el puerto 443 mediante el protocolo ALPN de ACME. DNS-01 publica registros TXT temporales y es uno de los dos métodos que pueden emitir certificados comodín. DNS-PERSIST-01 utiliza registros TXT de autorización de larga duración en lugar de crear uno nuevo en cada renovación.

El coste es que Stalwart necesita controlar el handshake TLS. TLS-ALPN-01 funciona completando el handshake por sí mismo, por lo que no puede funcionar detrás de un reverse proxy que termine TLS. Si nginx o Caddy ya utiliza el puerto 443 en ese equipo, tiene tres opciones. La guía de nginx de Stalwart configura nginx como un TCP passthrough, con listen 443; proxy_pass 127.0.0.1:10443; proxy_protocol on;, para que la conexión TLS llegue a Stalwart sin modificaciones. Esto entrega a Stalwart todas las conexiones del puerto 443, por lo que resulta adecuado para un equipo en el que nginx no sirve nada más en ese puerto. De lo contrario, cambie Stalwart a DNS-01 o HTTP-01, o asígnele su propia dirección IP.

DANE y MTA-STS, y los valores predeterminados que debe conocer

Ambos se configuran según la estrategia TLS en el objeto MtaTlsStrategy, bajo Settings, MTA, Outbound, TLS Strategies en la interfaz web. El campo dane tiene como valor predeterminado optional, que intenta la validación DANE cuando el destinatario publica registros TLSA y recurre al STARTTLS ordinario cuando no lo hace. Si se establece en require, la entrega solo procede si existe un registro TLSA verificable. El campo mtaSts se comporta de la misma manera, con el valor predeterminado optional. Los tiempos de espera relacionados son tlsTimeout (3 minutos por defecto) y mtaStsTimeout (5 minutos por defecto).

En el lado entrante, Stalwart puede publicar su propia política MTA-STS en https://mta-sts.<domain>/.well-known/mta-sts.txt, lo cual requiere que el puerto 443 esté abierto. El singleton MtaSts tiene mode (valor predeterminado testing), maxAge (valor predeterminado 7 días) y mxHosts, que recurre a los nombres de host de su certificado TLS cuando está vacío. Debe proporcionar dos registros DNS: un CNAME mta-sts que apunte al host de correo y un registro TXT _mta-sts que contenga el identificador de la política.

dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txt

La búsqueda TXT debería devolver una cadena v=STSv1; id=... y el comando curl debería devolver el cuerpo de la política. Si curl no devuelve nada, el puerto 443 está cerrado o el certificado para mta-sts.example.org nunca se emitió.

Mantenga mode en testing hasta que ambas comprobaciones sean exitosas. Una política en modo enforce con un certificado roto impide que otros servidores le entreguen correos, y se enterará por sus usuarios en lugar de por un registro. DANE tiene una trampa similar: requiere una zona firmada con DNSSEC, y un registro TLSA que ancle el certificado hoja debe volver a publicarse cada vez que ACME realice una renovación. Ancle la CA emisora en su lugar, o acepte la tarea de renovación.

El cifrado en reposo no es cifrado de extremo a extremo

Esta es la función que más se interpreta mal, así que esto es exactamente lo que indica la documentación. Los mensajes en texto plano de cada usuario se cifran automáticamente con su certificado OpenPGP o S/MIME antes de escribirse en el disco. encryptAtRest está habilitado de forma predeterminada y se aplica a los mensajes que llegan mediante SMTP o LMTP, siempre que el destinatario haya registrado una clave de cifrado. encryptOnAppend tiene el valor predeterminado false, «lo que deja intactos los mensajes añadidos para que los clientes mantengan el control total sobre el contenido que almacenan». OpenPGP usa PGP/MIME en lugar del antiguo PGP/Inline, con AES-256 o AES-128. Stalwart no genera claves: los usuarios exportan una clave pública con formato ASCII-armored y la registran como un objeto PublicKey en Account, Public Keys.

Por tanto, protege una imagen de disco robada, una copia de seguridad robada y el acceso de un operador al almacén después de la entrega. Sin la clave privada, los bytes almacenados no se pueden leer y el administrador tampoco puede descifrarlos.

No protege el mensaje durante el tránsito. Un mensaje atraviesa Internet con el nivel de TLS que hayan acordado los dos servidores, llega en texto plano y Stalwart lo cifra en ese momento. El remitente, el proveedor del remitente y cualquier salto que haya eliminado TLS ya han visto el texto plano.

Conviene indicar claramente otros tres límites. Las carpetas Sent y Drafts las escribe el cliente, mediante una operación append, y encryptOnAppend es false de forma predeterminada, por lo que permanecen sin cifrar salvo que cambie ese valor. La documentación que volví a revisar el 12 October 2026 sólo describe el contenido de los mensajes y no indica que se cifren los datos del sobre, las cabeceras o las entradas del índice, así que no debe asumirlo. Tampoco indica que los mensajes almacenados antes de cargar una clave se vuelvan a cifrar, por lo que debe asumir que no ocurre y comprobarlo. Tampoco se especifica si la búsqueda de texto completo sigue funcionando en los cuerpos cifrados. Pruébelo en una cuenta desechable antes de prometérselo a alguien.

Y si un usuario pierde su clave privada, pierde sus mensajes. No existe ningún mecanismo de recuperación, por diseño.

WKD es un trabajo de servidor web, no de servidor de correo

WKD (Web Key Directory) es la otra parte de OpenPGP y resuelve un problema diferente. Publica tu clave pública en una URL HTTPS fija bajo tu dominio para que el cliente de correo del remitente pueda encontrarla y cifrar el mensaje antes de que salga de su equipo. Eso es cifrado de extremo a extremo. El cifrado en reposo de Stalwart se aplica a la copia almacenada en el disco. Configurar uno no proporciona el otro.

Stalwart no sirve WKD. Sus endpoints HTTP documentados, consultados el 12 de octubre de 2026, enumeran rutas well-known para jmap, caldav, carddav, oauth-authorization-server, openid-configuration, acme-challenge, mta-sts.txt, mail-v1.xml y autoconfig. No existe la ruta openpgpkey. Sírvela desde un servidor web estático normal.

La especificación define dos diseños. El método avanzado usa https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. El método directo usa https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. Esa cadena de 32 caracteres es el SHA-1 de la parte local convertida a minúsculas y codificada en z-base-32, por lo que nunca debes crear estos nombres de archivo manualmente. GnuPG los crea por ti.

gpg --export --armor you@example.org > you.asc
gpg-wks-client --print-wkd-url you@example.org
gpg-wks-client --install-key you.asc you@example.org

--print-wkd-url muestra la URL que consultará un cliente mediante el formato de subdominio. --install-key escribe la clave en un árbol de directorios local que reproduce el diseño de WKD, bajo un directorio de nivel superior llamado openpgpkey de forma predeterminada, cuyo nombre se cambia con -C dir. Copia ese árbol en la raíz web, añade el archivo policy requerido junto al directorio hu (un archivo vacío es válido) y consulta tu propia URL con curl para confirmar que devuelve bytes de clave y no un 404.

Almacenamiento en un único VPS

Stalwart divide el almacenamiento en cuatro roles: un almacén de datos para registros estructurados como el estado del buzón, un almacén de blobs para bytes de mensajes sin procesar y archivos adjuntos, un almacén de búsqueda para indexación de texto completo y un almacén en memoria para limitadores de tasa, tokens de autenticación y datos de sesión. Cada uno puede apuntar a un backend diferente. La lista de compatibilidad incluye RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, almacenamiento de objetos compatible con S3, Azure Blob Storage, Redis, ElasticSearch y Meilisearch.

En un solo VPS, la respuesta es breve. La documentación denomina a RocksDB "el backend recomendado para instalaciones de un solo nodo de Stalwart debido a su velocidad y fiabilidad". Redis solo es compatible como almacén en memoria y no puede ser el almacén de datos ni el almacén de blobs, por lo que no se requiere un contenedor de Redis independiente para comenzar. Mueva el almacén de blobs a S3 más adelante si los buzones superan la capacidad del disco.

Las copias de seguridad siguen al backend. Para bases de datos externas, utilice el procedimiento propio de dicha base de datos. Para las integradas, el FAQ indica copiar el directorio /var/lib/stalwart. Realice esta operación con el servicio detenido, o bien mediante una instantánea del sistema de archivos o del volumen. Una copia a nivel de archivo de un almacén clave-valor en ejecución puede capturarlo a mitad de una escritura, y no se dará cuenta hasta que intente restaurarlo.

El filtro de spam que reemplaza a Rspamd

El filtrado se ejecuta dentro del mismo proceso, por lo que no hay un segundo daemon que mantener activo. El clasificador se configura en el singleton SpamClassifier bajo Settings, Spam Filter, Classifier. Utiliza el algoritmo FTRL-Proximal con hashing de características. FtrlFh es el valor predeterminado recomendado para la mayoría de las implementaciones. FtrlCcfh cambia a hashing de características cuckoo para reducir las colisiones de hash y está orientado a implementaciones a gran escala. El entrenamiento es continuo: cuando los usuarios marcan un mensaje como spam o ham, esa etiqueta se incorpora directamente a decisiones futuras.

Alrededor del clasificador se encuentran las listas de bloqueo DNS, el greylisting, la detección de phishing, los spam traps y Pyzor, además de la opción de invocar a SpamAssassin mediante milter si tiene reglas a las que no desea renunciar.

Cuándo mailcow sigue siendo la opción adecuada

Stalwart no incluye webmail. Es la mayor carencia y no está cerca de resolverla. La documentación de mailcow, consultada el 12 de octubre de 2026, enumera dieciséis componentes, incluido SOGo, que proporciona a los usuarios una bandeja de entrada en el navegador y una interfaz CalDAV y CardDAV desde el primer momento. La publicación de la hoja de ruta de Stalwart del 20 de junio de 2025 indica que el webmail integrado está «en nuestros planes, pero no es nuestra prioridad inmediata». También señala que se desarrollará en Rust con Dioxus después de la versión 1.0, «muy probablemente en algún momento de 2026». A fecha del 12 de octubre de 2026, el blog del proyecto no contiene ninguna publicación que anuncie su disponibilidad. Por tanto, con Stalwart tendrá que desplegar Roundcube por su cuenta o pedir a todos los usuarios que configuren un cliente de correo.

Stalwart sí tiene una interfaz de administración web, por lo que esa no es la carencia que suelen esperar los usuarios. La segunda carencia es la madurez de la versión. Las FAQ indican que Stalwart está en la versión 0.x y que el diseño de los datos y la configuración pueden cambiar antes de la v1.0, lo que puede requerir una migración. La propia publicación del proyecto de junio de 2026 se titula «Cero informes de errores abiertos: el camino hacia Stalwart 1.0». Eso indica en qué punto se encuentra: cerca, pero todavía no está ahí. A fecha del 12 de octubre de 2026, la versión más reciente sigue siendo v0.16.26.

La tercera carencia es la que nadie incluye en una lista de funciones. Postfix, Dovecot y Rspamd tienen una década de respuestas documentadas detrás. A las dos de la madrugada, con mensajes en cola y usuarios esperando, una búsqueda que devuelve una cadena de error coincidente vale más que una arquitectura elegante. Si esa es su situación, nuestra guía de instalación de mailcow recorre toda la pila de principio a fin y la noche será más corta.

Elija Stalwart si quiere un único binario, un único archivo de configuración y JMAP, y acepta adoptar una solución reciente. Elija mailcow si necesita webmail hoy y una amplia base de respuestas existentes.

Migración de correo existente

La ruta genérica es IMAP a IMAP mediante imapsync, herramienta que es agnóstica respecto al software que ejecutan ambos extremos. Realice primero una ejecución de prueba.

imapsync --dry \
  --host1 old.example.org --user1 you@example.org --passfile1 /root/.old.pw \
  --host2 mail.example.org --user2 you@example.org --passfile2 /root/.new.pw

--dry hace que imapsync "no realice ninguna acción real; solo imprime lo que se haría", así que lea esa salida antes de eliminar el flag. Cada archivo de contraseña contiene la contraseña en su primera línea, por lo que debe chmod 600 ambos y borrarlos después.

Stalwart también incluye herramientas más recientes que la mayoría de las guías de terceros aún no han incorporado. Su blog documenta Vandelay, un importador y exportador JMAP (29 de mayo de 2026), y un proxy de migración para actualizaciones sin tiempo de inactividad (10 de junio de 2026). Lea ambos antes de planificar una migración a gran escala, ya que son más recientes que casi cualquier otra documentación que encontrará escrita en otros sitios.

Modos de fallo y cadenas que verá

La interfaz de administración nunca carga. Las preguntas frecuentes lo indican directamente: el paquete de la interfaz web se descarga de GitHub durante la primera ejecución. Por tanto, un servidor sin HTTPS saliente hacia github.com ejecuta el servicio, pero todas las rutas de la interfaz web devuelven 404. Compruébelo desde el servidor con curl -sI https://github.com/stalwartlabs/webui/releases/latest/. Las otras causas habituales que se indican son un esquema HTTP o HTTPS incorrecto y un reverse proxy que no reenvía la IP del cliente.

No hay ninguna contraseña de arranque en el registro. Se muestra una sola vez, al iniciar, en modo de arranque. Si el servicio se ha reiniciado desde entonces, amplíe el intervalo con sudo journalctl -u stalwart --since today | grep -A8 'bootstrap mode'. Si realmente ha desaparecido, establezca STALWART_RECOVERY_ADMIN en /etc/stalwart/stalwart.env y reinicie.

Se rechaza el relay a través de un proxy local. Las notas de la versión v0.16.19 registran una corrección para las rutas de relay que se rechazaban con host resolves loopback address. Si encuentra esa cadena exacta, está ejecutando una compilación anterior. Actualice la versión; no aplique una solución alternativa.

El servicio no inicia después de crear su propia unidad. Sin AmbientCapabilities=CAP_NET_BIND_SERVICE, el usuario stalwart no puede enlazar los puertos 25, 443, 465 o 993, y el arranque falla en el primer listener. Copie la línea de capacidades de la unidad que generó el instalador.

Los certificados nunca se emiten. HTTP-01 necesita que el puerto 80 sea accesible y esté libre. TLS-ALPN-01 necesita que el propio Stalwart responda al handshake TLS en el puerto 443. Si otro proceso del servidor ocupa cualquiera de esos puertos, ACME seguirá fallando silenciosamente mientras todo lo demás parece funcionar.

FAQ

¿Stalwart sustituye a Postfix, Dovecot y Rspamd en un solo VPS?

Sí. Un único binario de Rust gestiona SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV y WebDAV, e incluye el filtro antispam, el almacén de mensajes y un cliente ACME. Hay una unidad de systemd y un archivo de configuración en /etc/stalwart/config.json, en lugar de cuatro daemons y su configuración auxiliar. Lo que no sustituye es la zona DNS ni la política del proveedor sobre el puerto 25, que es donde el correo autoalojado realmente funciona o falla.

¿Cuánta RAM necesita un servidor de correo Stalwart?

La página de requisitos del sistema de Stalwart, consultada el 12 de octubre de 2026, indica aproximadamente 100 MB en reposo y señala que 1 GB de RAM es adecuado para una implementación pequeña de 5 a 10 usuarios. Una instalación con poco tráfico para unos 5 usuarios funciona con un solo núcleo de CPU. El límite predeterminado es de 8,192 conexiones simultáneas entre todos los servicios y se puede configurar, por lo que el límite aumenta con el número de conexiones y el volumen de correo, no sólo con el número de usuarios. No se publica un tamaño mínimo de disco, así que dimensione el disco según el correo que vaya a conservar.

¿Cambiar a Stalwart mejorará la entregabilidad de mi correo?

No. La entregabilidad depende de que el puerto TCP 25 saliente esté abierto en su VPS, del DNS inverso de su IP y de SPF, DKIM y DMARC en su dominio. Stalwart admite DANE, MTA-STS y los informes TLS de SMTP, y puede publicar su política MTA-STS, pero estos mecanismos controlan la seguridad del transporte, no si una red receptora confía en su dirección. Pruebe el puerto 25 con nc -vz -w 5 alt1.aspmx.l.google.com 25 antes de instalar nada.

¿Stalwart incluye webmail?

No, a fecha del 12 de octubre de 2026. Incluye una interfaz web de administración, que es algo distinto. La publicación sobre la hoja de ruta del proyecto, fechada el 20 de junio de 2025, indica que hay un cliente webmail previsto después de la versión 1.0, desarrollado en Rust con Dioxus, «con toda probabilidad en algún momento de 2026», y el blog del proyecto todavía no anuncia ninguno. Si sus usuarios necesitan ahora una bandeja de entrada en el navegador, implemente Roundcube junto con Stalwart o use una pila que incluya SOGo.

¿Contra qué protege el cifrado en reposo de Stalwart?

Cifra los mensajes de cada usuario con su propia clave pública OpenPGP o S/MIME antes de escribirlos en el disco, de modo que un disco robado, una copia de seguridad robada o un administrador que lea el almacén no puedan recuperar el contenido. No es cifrado de extremo a extremo: el mensaje llega en texto plano y se cifra al entregarlo, por lo que todos los saltos anteriores pudieron verlo. encryptOnAppend tiene el valor predeterminado false, por lo que los mensajes de Sent y Drafts escritos por el cliente permanecen sin cifrar a menos que cambie esta opción. La documentación sólo cubre el contenido de los mensajes y no dice nada sobre los metadatos, las entradas del índice ni el recifrado del correo almacenado antes de cargar la clave; verifique estos aspectos por su cuenta en lugar de darlos por supuestos.