Instalar un servidor de correo no es simplemente “poner Postfix y ya”. Un servidor de correo real depende de varios elementos que tienen que quedar consistentes al mismo tiempo: DNS, certificados, puertos, autenticación, reputación de envío, antispam y operación diaria.
En este post voy a documentar un enfoque práctico para montar correo en una máquina virtual con Debian 12, con una meta clara: que sea reproducible, mantenible y que no se convierta en una pesadilla cuando algo falle.
La idea es simple: dejar que Debian sea una base sólida y estable, y montar el correo con un stack moderno que ya integre lo que normalmente habría que armar a mano.
- Antes de instalar: lo que debe estar resuelto sí o sí
Antes de tocar Docker o cualquier instalador, una VM de correo necesita cuatro cosas:
- IP pública fija (o al menos estable).
- Nombre de host (FQDN): por ejemplo mail.tudominio.com.
- rDNS (PTR) correcto en el proveedor: tu IP debe resolver hacia ese hostname.
- Recursos adecuados: correo sufre si el disco es lento o la RAM es corta.
Si el servidor “a ratos responde y a ratos no”, muchas veces no es “el correo”: es la VM (I/O, memoria, reinicios, límites del proveedor o firewall mal puesto).
- Puertos: lo mínimo necesario para que esto sea correo de verdad
El correo no funciona bien si se intenta inventar puertos. Hay estándares y conviene respetarlos:
- 25/tcp: SMTP entrante (lo que permite que el mundo te entregue correo).
- 587/tcp: Submission (envío autenticado desde clientes). Este es el estándar moderno para enviar.
- 993/tcp: IMAPS (lectura segura de correo).
- 443/tcp: webmail y panel.
Opcional:
- 465/tcp: SMTPS (aún usado por algunos clientes, pero 587 es el eje principal).
Si tu proveedor bloquea el 25, hay que decidirlo desde el principio: o se usa un relay (smarthost) o se cambia de proveedor. Pero para un servidor completo, el 25 tiene que estar habilitado.
- En Debian 12: base limpia + Docker
En lugar de instalar y configurar manualmente Postfix, Dovecot, antispam, webmail, bases de datos, cachés, etc., el enfoque más limpio hoy es:
- Debian 12 limpio y actualizado
- Docker y Docker Compose
- Un stack integrado para correo (por ejemplo mailcow)
Esto tiene una ventaja real: reduce variabilidad. Y en infraestructura, menos variabilidad significa menos horas perdidas.
- DNS: el punto donde se define si tus correos llegan o van a spam
Para que el correo sea confiable, el DNS debe quedar correcto. Aquí no hay atajos:
- A/AAAA: mail.tudominio.com -> IP del servidor
- MX: tu dominio apunta a mail.tudominio.com
- PTR (rDNS): la IP “revierte” a mail.tudominio.com (se configura en el proveedor)
- SPF: autoriza a tu servidor a enviar
- DKIM: firma los correos
- DMARC: define política y genera reportes
Sin PTR + SPF + DKIM, aunque el servidor “envíe”, la entregabilidad puede ser mala.
- Certificados SSL/TLS: lo correcto es automatizar
Hoy lo sano es que los certificados se renueven solos (Let’s Encrypt). Un stack como mailcow ya trae un componente ACME que hace este trabajo automáticamente, siempre que el DNS y el acceso por nombre estén bien.
Un detalle que causa problemas innecesarios: entrar al webmail por IP.
Eso rompe sesiones y certificados porque el certificado no está emitido para una IP, sino para un nombre (FQDN). Lo correcto es entrar por https://mail.tudominio.com.
Si además querés publicar el webmail sin exponer directamente la interfaz al mundo, una opción moderna es usar Cloudflare Tunnel (cloudflared) para la parte web (HTTPS). Esto reduce superficie de ataque para el panel/webmail. Eso sí: cloudflared no reemplaza SMTP/IMAP; el correo sigue necesitando sus puertos reales.
- Validación por pasos: no avanzar si no hay evidencia
Un error común es seguir configurando sin confirmar lo básico. Yo prefiero validar en capas:
- Ver puertos en escucha en el host (ss -lntp)
- Ver servicios activos en Docker (docker compose ps)
- Revisar logs del watchdog/healthchecks si algo reinicia
- Probar TLS real con herramientas estándar (openssl s_client)
- Probar envío/recepción desde un proveedor externo
- Medir reputación y configuración con herramientas como MXToolbox o mail-tester
Esto evita el típico escenario: “parece que todo está bien” pero no llega nada.
- Operación: un servidor de correo no se instala, se administra
El correo requiere disciplina básica:
- Backups de volúmenes y configuración
- Monitoreo de disco (el correo llena discos rápido)
- Revisión de colas (mail queue)
- Rotación de logs
- Actualizaciones planificadas
- Verificación periódica de DNS/SSL
Cuando el correo es crítico para una empresa, esto no es opcional.
Conclusión
Montar correo en una VM con Debian 12 puede ser una experiencia ordenada si se hace con el enfoque correcto: base estable + stack integrado + DNS impecable + TLS automatizado + validación por evidencia.
Esa combinación no solo hace que “funcione hoy”. Hace que siga funcionando mañana, después de actualizaciones, cambios y crecimiento.
En los siguientes posts voy a bajar esto a tierra con comandos y checklist, para que cualquiera lo pueda repetir paso a paso y sin improvisar.