Durante años, montar un servidor de correo propio ha sido una de esas tareas que muchos administradores miraban con respeto: reputación de IP, registros DNS, puertos “delicados”, configuraciones largas y el temor constante a acabar en listas negras. Pero el panorama del self-hosting ha cambiado. Hoy existen plataformas que facilitan el despliegue con contenedores y certificados TLS automáticos, y también han aparecido proyectos modernos que intentan simplificar el “todo en uno” del correo.
Ahí es donde entra Stalwart Mail Server, un servidor de correo open source escrito en Rust y planteado como un stack integrado (con servicios y administración en un único paquete), pensado para que el despliegue sea más directo y que la operativa sea menos artesanal.
En paralelo, soluciones como FlyWP han popularizado un enfoque muy pragmático: partir de una plantilla básica (por ejemplo, un “sitio HTML” con Nginx) y usar Docker Compose para añadir servicios propios, manteniendo una puerta de entrada web con HTTPS lista para usar. La idea es sencilla: si ya se puede publicar una web, también se pueden “colgar” detrás otros servicios con un proxy inverso… y, en el caso del correo, exponer además los puertos necesarios para SMTP/IMAP y compañía.
El enfoque: usar una base Nginx y añadir Stalwart como servicio
El procedimiento habitual se apoya en tres piezas:
- Una base con Nginx que ya esté funcionando (y que, idealmente, gestione el TLS para la parte web).
- Un
docker-compose.ymldonde se mantiene el servicio Nginx tal cual y se agrega el contenedor de Stalwart. - Un ajuste de Nginx para reenviar el tráfico web al panel/servicio HTTP de Stalwart (cuando se quiera que la administración sea accesible desde el dominio).
En la guía compartida, Stalwart se monta como un segundo servicio dentro del mismo Compose y se le asigna un volumen persistente para conservar configuración y datos. Es un detalle importante: en correo, “sin persistencia” significa “sin servidor” en cuanto reinicie.
Puertos: lo que conviene entender antes de abrir nada
Stalwart no es solo “una web”: es correo. Y eso implica protocolos y puertos específicos. En despliegues típicos con Docker, la imagen expone puertos para administración web/HTTP y para los protocolos de correo (SMTP, IMAP, POP3), además de opciones como ManageSieve y otros servicios asociados según configuración.
La guía que has pegado usa un conjunto clásico para correo moderno:
- 25 (SMTP)
- 587 (Submission con STARTTLS)
- 465 (SMTPS)
- 143 / 993 (IMAP / IMAPS)
- 4190 (ManageSieve)
Y, además, redirige la parte web mediante Nginx hacia Stalwart (en el ejemplo, el servicio HTTP interno de Stalwart se publica “detrás” del Nginx de la plantilla).
Aquí conviene una advertencia realista: en muchos proveedores y VPS, el puerto 25 puede venir filtrado o bloqueado por defecto para evitar spam. Si el objetivo es correo saliente a Internet (no solo recepción local o pruebas), este punto suele marcar la diferencia entre “funciona” y “no entrega”.
Qué se está haciendo en Docker Compose, paso a paso
Sin reinventar el contenido, el flujo práctico que propone la guía se resume así:
- Crear el sitio base (plantilla HTML) y conectarse por SSH al servidor.
- Parar contenedores (
docker compose down) para editar con seguridad. - Crear una ruta de datos persistentes para Stalwart (por ejemplo,
./data/stalwart). - Editar
docker-compose.ymly añadir el serviciostalwart:- Imagen
stalwartlabs/stalwart:latest - Puertos mapeados (los de correo + ManageSieve)
- Volumen persistente hacia
/opt/stalwart - Misma red que Nginx para que el proxy resuelva el nombre del servicio
- Imagen
- Ajustar la configuración de Nginx para que el
serveractúe como proxy inverso haciastalwart:8080(o el puerto que corresponda internamente). - Levantar todo con
docker compose up -d.
Un detalle especialmente útil en el primer arranque: Stalwart puede mostrar credenciales iniciales (por ejemplo, la contraseña del administrador) en los logs del contenedor, lo que simplifica el acceso inicial al panel para completar la configuración.
Lo que viene después: dominio, DNS y entregabilidad
Publicar el contenedor es solo el principio. Para que un servidor de correo sea “utilizable” en el mundo real, normalmente hay que completar (como mínimo):
- Registros MX apuntando al host correcto.
- SPF para autorizar el envío desde tu dominio.
- DKIM para firmar correos.
- DMARC para política y reportes.
- PTR / reverse DNS (si el proveedor lo permite) para reducir rechazo por parte de grandes buzones.
Este es el terreno donde muchos proyectos fallan no por Docker, sino por reputación, DNS incompleto o mala higiene de salida. Por eso, el mayor “beneficio” del enfoque FlyWP + Stalwart no es prometer magia, sino hacer que el despliegue sea repetible y que la administración sea más cómoda, dejando al administrador centrarse en lo que de verdad determina el éxito: identidad del dominio, políticas y seguridad.
Por qué Stalwart está llamando la atención
Más allá del tutorial, Stalwart encaja con una tendencia clara: herramientas de infraestructura modernas, escritas en lenguajes de sistemas actuales (como Rust) y pensadas como productos integrados. Su propuesta de servidor “todo en uno” busca reducir el número de componentes que el administrador debe ensamblar y mantener por separado, algo especialmente valioso cuando el objetivo es montar un servicio serio sin convertirlo en un proyecto eterno.
Y, en el contexto actual —donde la privacidad, el control de datos y la soberanía tecnológica vuelven a estar encima de la mesa—, volver a operar servicios propios (incluido el correo) ya no se ve solo como “nostalgia sysadmin”, sino como una decisión de arquitectura.
Preguntas frecuentes
¿Se puede alojar Stalwart Mail Server en un VPS si el puerto 25 está bloqueado?
Sí, pero con limitaciones: podrías usarlo para pruebas, correo interno o recepción parcial según el caso. Para envío fiable a Internet, normalmente necesitarás salida por 25 o una estrategia alternativa (por ejemplo, un relay SMTP externo).
¿Qué ventajas tiene poner el panel web de Stalwart detrás de Nginx (proxy inverso)?
Permite centralizar el acceso HTTPS en un único punto, aplicar cabeceras de seguridad, límites, listas de control, e integrar el panel con el dominio del servidor sin exponer directamente el puerto interno.
¿Qué puertos mínimos hay que abrir para un servidor de correo moderno con IMAP y envío autenticado?
En la práctica, suele bastar con 587 (Submission) para envío autenticado y 993 (IMAPS) para lectura segura. El 25 se usa para entrega servidor-a-servidor, y 465 sigue siendo común para SMTPS en algunos clientes.
¿Es buena idea montar correo propio para una empresa pequeña o un proyecto personal?
Depende del objetivo. Si se busca control y aprendizaje, es viable. Si se busca “cero mantenimiento” y entregabilidad perfecta desde el día 1, suele ser más eficiente usar un proveedor especializado y reservar el self-hosting para casos donde el control compense el esfuerzo.
