Alojar su servidor de correo en un VPS con Mailcow

La subida de tarifas de Microsoft 365 que entró en vigor el 1 de julio de 2026 — hasta un 43 % según el plan — supuso un electrochoque para muchas pymes. Una organización de 20 empleados que pagaba unos 200 € al mes pasa ahora a 285 € o más, sin ninguna contrapartida funcional destacable. Y eso no es todo: Microsoft ha oficializado la retirada de Exchange Web Services (EWS) para octubre de 2026, dejando obsoletas decenas de integraciones de terceros que se apoyaban en ese protocolo — agendas compartidas, herramientas de CRM, automatizaciones propias.

Ante estas turbulencias tarifarias y técnicas, el autoalojamiento del correo vuelve a las conversaciones con una legitimidad renovada. Alojar la mensajería en su propio VPS ofrece tres ventajas principales: el control total de los costes (un VPS adecuado cuesta entre 15 y 40 € al mes para 20 a 50 buzones), la soberanía de los datos (sus mensajes no pasan por los centros de datos de un gigante tecnológico) y el cumplimiento simplificado del RGPD (usted sabe con precisión dónde se almacenan y se tratan sus datos). Para despachos de abogados, profesionales sanitarios, agencias de comunicación o cualquier estructura que maneje datos sensibles, este argumento suele ser decisivo.

Antes de lanzar la instalación, asegúrese de que su VPS y su configuración de red cumplen las condiciones siguientes. En el plano del hardware, la documentación de Mailcow pide como mínimo 6 GB de RAM más 1 GB de swap en la configuración por defecto: por debajo, queda fuera de lo que prevén sus autores, y los contenedores más voraces (antispam, antivirus, base de datos) son los primeros en sufrirlo. Prevea 2 vCPU y al menos 20 GB de espacio en disco para los contenedores y los correos — 50 GB es un punto de partida razonable para una estructura pequeña.

En el plano de la red, varios puntos no son negociables. Primero, el puerto 25 debe estar desbloqueado en salida: muchos proveedores lo bloquean por defecto para combatir el spam. Compruébelo con su proveedor antes de contratar. Segundo, debe poder configurar el rDNS (DNS inverso / registro PTR) de su IP: es lo que permite a los servidores destinatarios verificar que su IP corresponde efectivamente al nombre de dominio de su correo — sin un PTR correcto, sus mensajes acabarán en spam en la mayoría de los grandes proveedores. Tercero, necesita un nombre de dominio cuyos DNS gestione usted (añadir registros MX, A, TXT). Por último, se recomienda un VPS con Debian 12 o Ubuntu 24.04 LTS para una compatibilidad óptima con Docker y los scripts de Mailcow. La documentación de Mailcow declara compatibles Debian 11 a 13, Ubuntu 22.04 y versiones posteriores, AlmaLinux 8 y 9 y Rocky Linux 9; Alpine solo aparece con compatibilidad limitada y ajustes manuales.

Un servidor de correo técnicamente correcto puede ver igualmente sus mensajes en la carpeta de spam si no se respetan ciertas condiciones de red y de DNS. Estos son los fallos más frecuentes.

Las listas negras (blacklists): la IP de su VPS puede figurar en listas negras como Spamhaus o Barracuda si se usó antes para enviar spam — algo habitual en los rangos de IP de centros de datos. Compruebe su IP en mxtoolbox.com/blacklists.aspx antes incluso de la instalación. Si aparece listada, solicite la retirada a cada organismo o cambie de IP.

El puerto 25 bloqueado: algunos proveedores bloquean el puerto 25 de salida en todas las IP nuevas durante un periodo de prueba. Contacte con el soporte antes de empezar.

DKIM ausente o mal configurado: un correo sin firma DKIM válida es tratado con desconfianza por Gmail y Outlook. Compruebe con dig TXT dkim._domainkey.votredomaine.com que el registro es visible.

DMARC en modo demasiado permisivo: empiece con p=none para recopilar los informes sin bloquear, y pase después a p=quarantine y luego a p=reject cuando esté seguro de que todos sus flujos legítimos están cubiertos por SPF y DKIM.

Ausencia de PTR (registro inverso): es el punto que más se olvida. Sin un registro PTR que resuelva hacia el hostname de su correo, Microsoft Outlook rechazará sus mensajes con el error 550.

La migración de los correos existentes suele ser lo que frena a las organizaciones. Mailcow integra tareas de sincronización IMAP directamente en su interfaz, lo que hace la operación accesible sin conocimientos avanzados.

El procedimiento básico consiste en: (1) crear los buzones de destino en Mailcow, (2) abrir *E-Mail Configuration → Synchronizations* en la interfaz de administración (un usuario dispone de la misma herramienta en *User Settings → Sync Jobs*), (3) indicar el host, el puerto, el usuario y la contraseña del servidor de origen, elegir el cifrado — TLS suele encajar con el puerto 143, SSL con el 993, y el modo PLAIN se desaconseja con firmeza — y activar la tarea. Copia los mensajes carpeta por carpeta. La migración puede relanzarse varias veces antes del cambio definitivo (los mensajes ya copiados se omiten en las pasadas siguientes), lo que permite realizar un cutover progresivo: usted sigue recibiendo en la dirección antigua mientras los datos migran, y después cambia el MX en una sola operación. Hecho el cambio, desactive o elimine la tarea.

Para Microsoft 365, no cuente con EWS: según la documentación de Microsoft, empieza a desactivarse para todas las organizaciones en octubre de 2026 y quedará desactivado por completo en abril de 2027, de modo que las herramientas de migración que se apoyan en él dejarán de funcionar. Mailcow usa IMAP, no EWS, por lo que no se ve afectado — un argumento más para migrar pronto.

En cuanto a los clientes de correo, Thunderbird, Apple Mail y las aplicaciones móviles (iOS, Android) se configuran con IMAP/SMTP estándar. Outlook también funciona, incluida la sincronización del calendario y de los contactos mediante ActiveSync (SOGo).

Mailcow no es la única solución de correo self-hosted basada en Docker. Así se posiciona frente a sus principales competidores.

Mailu es más ligera en recursos (funciona con 1 GB de RAM) y encaja en un uso personal o en estructuras muy pequeñas. Su interfaz es minimalista, no incorpora SOGo y sus funcionalidades son más limitadas. Es una excelente opción si la simplicidad prima sobre las funciones.

iRedMail es una solución madura, disponible en versión comunitaria y en versión Pro de pago (iRedMail Pro). Admite varios backends de base de datos (MySQL, PostgreSQL, LDAP) y se instala directamente en el sistema anfitrión, sin Docker. Su curva de configuración es más pronunciada y las actualizaciones están menos automatizadas. iRedMail Pro añade una interfaz web de gestión de pago que compite con la de Mailcow.

Mailcow destaca por la riqueza de sus funcionalidades, la calidad de su interfaz de administración, el ritmo de sus actualizaciones (versiones mensuales) y el tamaño de su comunidad (más de 13 200 estrellas en GitHub). Es la elección natural para una pyme que quiere una solución completa, mantenida activamente y con documentación abundante. El precio a pagar es el consumo de RAM: 6 GB como mínimo es un requisito no negociable.

Mailcow publica una versión al mes, y su etiqueta lleva el año y el mes (2026-10 para la del 21 de octubre de 2026). Corrigen fallos de seguridad, mejoran los filtros antispam y añaden funcionalidades. El procedimiento oficial de actualización es sencillo y está bien documentado.

Desde la carpeta /opt/mailcow-dockerized, ejecute ./update.sh. Este script descarga las nuevas imágenes de Docker, aplica las posibles migraciones de configuración y reinicia los contenedores afectados. La operación suele tardar entre 5 y 15 minutos, con un corte de servicio de menos de un minuto en los contenedores reiniciados.

No utilice Watchtower (la herramienta de actualización automática de contenedores Docker) con Mailcow. Las actualizaciones de Mailcow implican a veces migraciones de base de datos o cambios de configuración que exigen ejecutar update.sh en el orden correcto. Dejar que Watchtower descargue y reinicie las imágenes por su cuenta puede corromper su instalación.

Planifique sus actualizaciones en una ventana de mantenimiento conocida (por ejemplo, el sábado por la mañana), lea la nota de la versión en la página de releases del repositorio de Mailcow antes de aplicarla y compruebe el estado de los contenedores con docker compose ps después de cada actualización. Haga una copia de seguridad completa justo antes de cada actualización. Cuando la versión es una actualización de seguridad, no espere: la sección siguiente da el procedimiento de urgencia.

Mailcow no es una aplicación PHP instalada sobre su sistema: incorpora su propio PHP, en el contenedor php-fpm-mailcow, que ejecuta la interfaz de administración. Las correcciones de PHP de su distribución no le afectan, y un apt upgrade en el VPS no cambia nada en la versión que usa Mailcow. Eso es lo que motivó el hilo #7533, abierto el 21 de octubre de 2026 con el título «[UPDATE NOW] PHP RCE Vulnerability (CVE-2026-109618 and CVE-2026-109619)»: allí los administradores piden una corrección de Mailcow mismo. Las dos vulnerabilidades se detallan en nuestro artículo [PHP2Shell: corregir CVE-2026-109618 y CVE-2026-109619](/blog/php2shell-cve-2026-109618-109619-mettre-a-jour-php).

En cuanto a la versión, la release 2026-10, publicada el 21 de octubre de 2026, se titula «Security Update: PHP 8.2.35, SOGo 5.12.12 & Nginx 1.30.6». Sus notas no citan los números CVE: el vínculo se establece por la versión de PHP, ya que 8.2.35 es la versión corregida de la rama 8.2 en el aviso del proyecto PHP del mismo día, y la imagen phpfpm entregada con esa release lleva la etiqueta 8.2.35-1. Lea la nota de la release antes de actuar: una release posterior puede haber cambiado esos números.

En un VPS que ya aloja otros contenedores Docker, el contenedor netfilter-mailcow puede ponerse a reiniciarse sin fin. El síntoma visible: la interfaz web deja de responder, el contenedor unbound-mailcow se declara defectuoso («dependency failed to start: container mailcowdockerized-unbound-mailcow-1 is unhealthy») y los registros de netfilter repiten «MAILCOW target not found in ip forward table, restarting container to fix it...».

Causa comunicada: al arrancar, netfilter comprueba la posición de su cadena MAILCOW en la tabla FORWARD. Según el hilo #6795, el código de NFTables.py supone que la cadena está en primera posición y la coloca por inserción; si Docker ya ha creado sus propias cadenas, la comprobación falla, el contenedor se detiene y cada reinicio añade un salto MAILCOW más. En #6995, un participante cuenta más de 9 000, y otro describe el mismo efecto tras una actualización de Docker en Debian.

Lo que se sabe del estado: #6795, abierto en septiembre de 2025, se cerró como «not planned» en diciembre de 2025 tras una etiqueta «stale»; #6995, abierto en enero de 2026, se cerró del mismo modo en octubre de 2026. Ningún mantenedor confirma allí una corrección, y un participante estima que la causa raíz exige un rediseño. Lo que sigue es, por tanto, una solución alternativa de la comunidad, no un procedimiento oficial.

El autoalojamiento del correo no es la respuesta universal. Hay situaciones en las que Google Workspace o Microsoft 365 sigue siendo la opción más razonable, incluso después de la subida de tarifas.

Si no cuenta con competencias técnicas internas: gestionar un servidor de correo exige una vigilancia de seguridad regular, actualizaciones proactivas y la capacidad de diagnosticar problemas de entregabilidad. Sin esas competencias, corre el riesgo de quedarse sin mensajería durante un incidente crítico.

Si la entregabilidad es absolutamente crítica: las grandes operaciones de correo transaccional (bancos, aseguradoras, plataformas de comercio electrónico de alto volumen) se benefician de la reputación de IP compartidas y gestionadas profesionalmente por ESP (Mailgun, Postmark, Brevo). Un VPS en solitario parte con una IP virgen cuya reputación habrá que construir.

Si su proveedor bloquea el puerto 25: algunos operadores de nube (sobre todo en las ofertas de entrada de gama) bloquean definitivamente ese puerto para combatir el spam. Compruébelo antes de comprometerse.

Si opera en una jurisdicción con regulación estricta: algunos sectores (finanzas, salud) imponen requisitos de certificación o de auditoría de las infraestructuras de correo que pueden ser difíciles de satisfacer en autoalojamiento sin acompañamiento especializado.

Alojar su servidor de correo con Mailcow en un VPS está hoy al alcance de cualquier organización con un mínimo de madurez técnica. La solución es madura, se mantiene activamente y ofrece un nivel funcional que rivaliza honestamente con las ofertas comerciales, a una fracción del coste.

La subida de tarifas de Microsoft 365 y la desaparición de EWS en 2026 han convertido el autoalojamiento de una opción marginal en una alternativa estratégica para miles de pymes y agencias. Con un VPS bien dimensionado (6 GB de RAM, IP dedicada con rDNS configurado), una instalación de Mailcow lleva menos de una hora, y la migración de los buzones existentes puede hacerse de forma progresiva sin interrupción del servicio.

Los tres puntos que hay que recordar antes de lanzarse: comprobar que el puerto 25 está realmente abierto en su proveedor, configurar el registro PTR de su IP antes incluso de enviar el primer correo y poner en marcha una copia de seguridad externa desde el primer día. Con estos cimientos, su servidor de correo será tan fiable — y mucho más económico — como una suscripción en la nube.

Añada un cuarto reflejo a estos tres: Mailcow lleva su propio PHP, así que cada aviso de seguridad de PHP se resuelve con ./update.sh seguido de una comprobación dentro del contenedor, como con PHP2Shell en octubre de 2026.