Montaje de un Servidor de Correo con Postfix: Guía Definitiva para Sysadmins Linux

octubre 8, 2026 Alfonso Moreno | Sysadmin Senior 34 Visitas 12 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 4-6 horas la primera vez, 1-2 horas con Ansible.
Requisitos: VPS con IP estática y PTR configurable (Hetzner, OVH), dominio propio.
Resultado: Mail server SMTP/IMAP con antispam rspamd, deliverability aceptable.
Troubleshooting: PTR/DKIM/SPF/DMARC, mail-tester.com score, logs de Postfix.

Por qué montar tu propio servidor de correo en 2026

Llevas años usando Gmail, Outlook o Fastmail. Funcionan. Pero para un sysadmin, el correo es la pieza de infraestructura donde más claro se ve el costo de entregar tu privacidad y tu control a un tercero: Google lee tus mensajes para entrenar Gemini, Microsoft te filtra según políticas que cambian sin avisar, y cuando tu dominio escala a 200 empleados el costo por buzón te come el presupuesto. Hostear tu propio Postfix es viable, gracias a tres piezas que en 2026 están maduras: Postfix 3.11.7 como MTA, Dovecot 2.4.5 como IMAP/POP3, y Rspamd 3.11 como filtro antispam. El resto es TLS, DNS y disciplina.

El resultado: buzones ilimitados, sin rastreo, entregados por tu propio hostname con SPF/DKIM/DMARC configurables, y un servidor Linux de $10/mes en Hetzner o un homelab con tu dominio apuntando ahí. Esta guía asume Debian 12/13 o Ubuntu 24.04, MySQL/MariaDB para usuarios virtuales, y un hostname con PTR inverso configurado por tu proveedor.

Arquitectura del stack completo

Un servidor de correo autocontenido tiene cinco componentes hablando entre sí. Cada uno hace una sola cosa bien. El orden importa: si pones el filtro antispam antes de Postfix, Rspamd puede rechazar antes de que el mensaje toque tu cola.

Capa	Software	Función
MTA (envío/recepción)	Postfix 3.11.7	SMTP en puerto 25, enruta mensajes
MDA / IMAP	Dovecot 2.4.5	Entrega al buzón, IMAP/POP3, sieve filters
Antispam / DKIM	Rspamd 3.11	Filtro milter, firma DKIM, rechaza antes de cola
Base de datos	MariaDB 10.11	Usuarios virtuales, dominios, aliases
Certificados	Let’s Encrypt + certbot	TLS para SMTP submission (587), IMAP (993)

En conjunto: Postfix recibe el correo del mundo exterior, lo pasa por el milter de Rspamd, Rspamd agrega la firma DKIM y descarta spam, y Dovecot entrega el mensaje limpio al buzón del usuario. Tu cliente (Thunderbird, mutt, Roundcube) habla IMAPS con Dovecot para leer.

Requisitos previos antes de tocar apt

Antes de instalar nada, verifica tres cosas que ningún tutorial menciona pero que sin ellas tu servidor de correo acabará en la lista negra de Spamhaus en 48 horas:

PTR inverso (rDNS): tu proveedor debe configurar la resolución inversa de tu IP hacia tu hostname de correo. Sin PTR válido, Gmail rechaza con 550-5.7.25 reverse DNS. En Hetzner lo configuras desde el panel; en AWS con un Elastic IP + route53; en un homelab depende de tu ISP.
Puerto 25 abierto: muchos ISP residenciales bloquean el puerto 25 entrante para evitar spam casero. Confirma antes de invertir tiempo: nc -zv tu.servidor 25 desde un host externo.
Hostname con FQDN válido: mail.tudominio.com con A record apuntando a la IP del server. Esto se publica en el banner SMTP y en el HELO/EHLO.

Si alguno falla, resolver primero. Postfix bien configurado con PTR malo es invisible para tus destinatarios.

Instalación del stack base

En Debian 13 (Trixie) y Ubuntu 24.04 los paquetes están en los repos oficiales. Stable release de Postfix al momento de escribir esto es 3.11.7 (septiembre 2026), con legacy 3.10.12 para quienes priorizan estabilidad. Debian sid trae 3.11.7-1 desde el 8 de septiembre.

# Refresca índices e instala los paquetes del stack
sudo apt update
sudo apt install postfix postfix-mysql dovecot-core dovecot-imapd 
                 dovecot-lmtpd dovecot-mysql mariadb-server rspamd certbot
# Durante la instalación de Postfix eliges "Internet Site" +
# system mail name: mail.tudominio.com. El resto lo sobrescribimos a mano.

Postfix se divide en tres binaries separados (master, qmgr, showq) y los binarios auxiliares (postqueue, postmap) viven en /usr/sbin/. Los mapas de transporte van en /etc/postfix/transport y se compilan con postmap. Dovecot usa ahora un único archivo /etc/dovecot/dovecot.conf con includes por protocolo y por servicio (formato 2.4, distinto del 2.3 monolítico).

Configurar usuarios virtuales en MariaDB

Para evitar cuentas Unix por cada buzón (caos a 50 buzones), los usuarios viven en una base MariaDB con tres tablas: dominios, direcciones y alias. La password se guarda como SHA512-crypt:

sudo mysql <<'EOF'
CREATE DATABASE mailserver CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'mailuser'@'localhost' IDENTIFIED BY 'CAMBIAR-POR-PASSWORD-FUERTE';
GRANT SELECT ON mailserver.* TO 'mailuser'@'localhost';
FLUSH PRIVILEGES;
USE mailserver;
CREATE TABLE virtual_domains (
  id INT NOT NULL AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  PRIMARY KEY (id)
);
CREATE TABLE virtual_users (
  id INT NOT NULL AUTO_INCREMENT,
  domain_id INT NOT NULL,
  password VARCHAR(106) NOT NULL,
  email VARCHAR(100) NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY email (email),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id)
);
CREATE TABLE virtual_aliases (
  id INT NOT NULL AUTO_INCREMENT,
  domain_id INT NOT NULL,
  source VARCHAR(100) NOT NULL,
  destination VARCHAR(100) NOT NULL,
  PRIMARY KEY (id),
  FOREIGN KEY (domain_id) REFERENCES virtual_domains(id)
);
EOF
# Hashear password en SHA512-crypt (compatible con dovecot SHA512)
sudo doveadm pw -s SHA512-CRYPT
# Pegar el output en el INSERT de abajo

El doveadm pw genera el hash compatible con Dovecot. Lo insertas con un INSERT normal: INSERT INTO virtual_users (domain_id, password, email) VALUES (1, '{SHA512-CRYPT}$6$rounds=10000$...', '[email protected]');. Nunca guardes la password en texto plano, ni siquiera dentro de un script de aprovisionamiento.

Postfix: main.cf + master.cf para virtual users

Postfix resuelve usuarios, dominios y aliases preguntando a MySQL. Cada lookup es un archivo en /etc/postfix/mysql-virtual-*.cf. El detalle clave en 2026: smtputf8_enable = yes está activo por default en 3.11, lo cual permite direcciones con caracteres internacionales sin romper. Si quieres deshabilitarlo para compatibilidad con clientes viejos, agrega smtputf8_enable = no.

sudo tee /etc/postfix/main.cf <<'EOF'
myhostname = mail.tudominio.com
mydomain = tudominio.com
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4, ipv6
# Virtual mailbox setup
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-users.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-aliases.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
# TLS: obligatorio moderno
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.tudominio.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.tudominio.com/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_ciphers = high
smtpd_tls_mandatory_ciphers = high
smtpd_tls_eecdh_auto_curves = X25519:P-256:P-384
# Restrictions anti-relay
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service unix:private/quota-status
# Milter para Rspamd (DKIM + spam)
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = inet:127.0.0.1:11332
EOF
sudo tee /etc/postfix/master.cf <<'EOF'
# Submission para clientes autenticados (puerto 587)
submission inet n - y - - smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
# Smtps legacy (puerto 465)
smtps inet n - y - - smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
EOF
sudo systemctl restart postfix

El smtpd_tls_eecdh_auto_curves = X25519:P-256:P-384 es la lección aprendida de Postfix 3.11: con OpenSSL 3.5+ el default cambió a curvas híbridas post-quantum que algunos firewalls intermedios no negocian bien, así que fijamos las curvas clásicas explícitamente. Sigue aprovechando el TLS moderno, pero sin sorpresas en el handshake.

Dovecot 2.4: el cambio de formato que rompe configs viejas

Dovecot 2.4 (enero 2025) reorganiza la configuración: ya no existe mail_location como setting global, ahora es mailbox.default.mail dentro del namespace inbox. Si copias una config de un tutorial 2.3, Dovecot devuelve Unknown setting: mail_location y arranca en modo roto silencioso. La nueva estructura usa includes separados por protocolo:

sudo tee /etc/dovecot/dovecot.conf <<'EOF'
!include_try /usr/share/dovecot/protocols.d/*.protocol
!include conf.d/*.conf.ext
dovecot_storage_version = 2.4
protocols = imap lmtp sieve
# Directorio de buzones en /var/mail/vmail (formato maildir)
mailbox.default.mail = maildir:/var/mail/vmail/%d/%n
mailbox.default.index = maildir:/var/mail/vmail/%d/%n/index
namespace inbox {
  separator = /
  prefix =
  inbox = yes
}
# Auth contra MariaDB
passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
EOF
sudo tee /etc/dovecot/dovecot-sql.conf.ext <<'EOF'
driver = mysql
connect = host=localhost dbname=mailserver user=mailuser password=TU-PASSWORD
default_pass_scheme = SHA512-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
user_query = SELECT 5000 AS uid, 5000 AS gid, '/var/mail/vmail/%d/%n' AS home 
            FROM virtual_users WHERE email='%u';
EOF
sudo useradd -r -u 5000 -g 5000 -d /var/mail/vmail -s /usr/sbin/nologin vmail
sudo systemctl restart dovecot

El cambio más relevante para sysadmins que vienen de 2.3: las directivas passdb y userdb ya no van dentro de auth-system.conf.ext, ahora se declaran en dovecot.conf directamente. Intentar mezclarlas deja al servicio arrancando sin usuarios válidos.

Rspamd: antispam moderno con DKIM incluido

Rspamd reemplaza a SpamAssassin para servidores nuevos. Procesa 10× más mensajes por segundo con menos RAM y trae DKIM signing integrado, así que no necesitas OpenDKIM separado. El módulo arc valida forwarding y greylist rechaza el primer intento de servidores desconocidos (los spammers no reintentan).

# Configuración básica via web UI https://mail.tudominio.com:11334/
# Primer login: contrasena autogenerada en /var/lib/rspamd/rspamd_password
cat /var/lib/rspamd/rspamd_password
# Habilitar DKIM signing: edita /etc/rspamd/local.d/dkim.conf
sudo tee /etc/rspamd/local.d/dkim.conf <<'EOF'
dkim_signing = yes;
sign_local = true;
use_domain = header_from;
selector = "default";
path = "/var/lib/rspamd/dkim/$domain.$selector.key";
EOF
# Generar clave DKIM para tudominio.com
sudo rspamadm dkim_keygen -b 2048 -s default -d tudominio.com
# Publicar el registro TXT en DNS: default._domainkey.tudominio.com

El registro DKIM publicado en DNS debe respetar el formato DKIM1 con k=rsa; p=MIIBIj.... Si publicas mal, Rspamd firma correctamente pero Gmail rechaza. Verifica con dig TXT default._domainkey.tudominio.com y con MX Toolbox DKIM check.

DNS: SPF, DKIM, DMARC y la diferencia que pocos explican

SPF, DKIM y DMARC hacen cosas distintas pero complementarias. La confusión típica es tratarlos como un solo registro. SPF declara qué IPs pueden enviar a nombre de tu dominio. DKIM firma cada mensaje con clave criptográfica que el receptor verifica. DMARC dice qué hacer cuando fallan SPF o DKIM y adónde enviar reportes.

# SPF: IPs autorizadas a enviar
tudominio.com.  IN  TXT  "v=spf1 ip4:1.2.3.4 -all"
# ip4 es la IP de tu server, -all es fail estricto (recomendado)
# DKIM: clave pública (pegar la p= de rspamadm dkim_keygen)
default._domainkey.tudominio.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."
# DMARC: política + reportes
_dmarc.tudominio.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100"
# MX: declara tu server de correo (obligatorio)
tudominio.com.  IN  MX  10  mail.tudominio.com.

DMARC p=reject es lo que debes apuntar desde el día uno. Empezar con p=none para “ver qué pasa” deja la puerta abierta a suplantación. Con p=reject Gmail y Outlook descartan los mensajes que fallan DKIM/SPF, y los spammers no pueden usar tu dominio. El parámetro rua= activa reportes automáticos que Gmail envía diariamente; revisarlos te muestra cuántos ataques estás bloqueando.

Troubleshooting: los cinco errores que vas a ver

Después de instalar este stack, lo normal es pasar dos horas peleando con logs. Cinco escenarios cubren el 90% de los problemas:

Gmail rechaza con 550-5.7.1 Our system has detected that this 550-5.7.1 message does not meet IPv6 sending guidelines: o no tienes PTR inverso IPv6 o tu IPv6 no tiene registro AAAA. Solución: habilitar IPv6 solo si configuraste rDNS; si no, inet_protocols = ipv4 en Postfix.
Thunderbird dice “el servidor no soporta el método de autenticación”: Dovecot no está viendo a Postfix via LMTP. Verifica postqueue -p y journalctl -u dovecot: el socket LMTP en private/dovecot-lmtp debe existir.
SPF falla con PermError: Too many DNS lookups: tu registro SPF incluye más de 10 mecanismos (include:, a:, mx:, ip4:). Cada include añade lookups. Consolida o usa ip4: directo.
DKIM signature body hash did not verify: tu MTA o un filtro intermedio está modificando el cuerpo del mensaje después que Rspamd firma. Si tienes un content_filter o Amavis en el pipeline, retíralos: Rspamd hace todo lo necesario.
Rspamd no arranca: cannot bind to 127.0.0.1:11332: el puerto lo está usando otro milter. ss -tlnp | grep 11332 mata al PID intruso antes de reiniciar Rspamd.

Para diagnóstico activo en producción: sudo journalctl -fu postfix dovecot rspamd en una terminal, y en otra tail -F /var/log/mail.log. El log de Postfix muestra exactamente qué restricción SMTP rechazó cada mensaje, incluido el código que Gmail intercambia con tu server.

Vale la pena en 2026: para quién sí, para quién no

La respuesta honesta: hostear tu propio servidor de correo cuesta ~$10-15/mes en infraestructura más 4-6 horas de configuración inicial, después un par de horas al año de mantenimiento (actualizaciones, certificados, ajustes DMARC según reportes). Si tienes 1-3 buzones personales, no vale la pena: Google Workspace cuesta $7/usuario y te libera de toda esta complejidad. Si tienes 50+ buzones, el ahorro se vuelve relevante (~$300/mes vs $7,000/año por licencias) y el control operacional justifica el esfuerzo. El sweet spot está en empresas medianas, ISP/cooperativas, periodismo/ONGs con necesidades de privacidad, y sysadmins que quieren aprender cómo funciona realmente Internet.

Si vas a hacerlo, no improvises el flujo: prueba en un servidor sandbox con un dominio de práctica, valida que el correo llega a Gmail/Outlook/ProtonMail sin caer en spam, y recién entonces apunta tu dominio de producción. Tres meses de sanción anti-spam por IP nueva quemada pesan más que cualquier ahorro de licencias.

Resumen

Un servidor de correo Postfix + Dovecot + Rspamd autocontenido en 2026 es viable, mantenido y razonablemente seguro. El stack está estandarizado, los paquetes están en los repos oficiales de Debian/Ubuntu, y el flujo DNS+TLS+Milter está documentado por décadas de uso. Los riesgos reales son operacionales: PTR inverso, DKIM bien firmado, DMARC estricto desde el inicio, y monitoreo activo de logs. Hecho bien, te queda una pieza de infraestructura que responde, no rastrea, y pertenece a tu organización.

Preguntas frecuentes

¿Por qué Montaje de un Servidor de Correo con Postfix: Guía Definitiva para Sysadmins Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Montaje de un Servidor de?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Montaje de un Servidor de?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Montaje de un Servidor de y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Montaje de un Servidor de?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.