Cómo montar tu propio mail server en casa en 2026

La pregunta ya no es si puedes correr un mail server en casa en 2026 — la respuesta técnica es sí. La pregunta es si tiene sentido operativo, económico y de soberanía para tu caso. Llevo seis años corriendo el mío propio con Postfix + Dovecot + OpenDKIM + rspamd, y este post es el resumen de qué cambió desde la última vez que escribí sobre esto, qué partes se simplificaron y dónde siguen los puntos de fricción reales con los proveedores grandes (Gmail, Outlook, Fastmail).

Si tu volumen es personal o de un grupo pequeño, y tu ISP no bloquea el puerto 25 saliente, esta guía es para ti. Si esperas entregar a Gmail sin warming up, mejor contratar Fastmail o Migadu y ahorrarte el dolor.

---

La verdad incómoda antes de empezar

Montar un servidor de correo en casa en 2026 es perfectamente posible. Lo que ya no es posible es hacerlo como se hacía en 2005: instalar Postfix, abrir el puerto 25 y esperar que Gmail te acepte los mensajes. Esa parte se rompió, y conviene entender por qué antes de invertir un fin de semana en algo que va a terminar en la carpeta de spam de todos tus contactos.

Hay dos barreras concretas, y ninguna se resuelve con configuración:

• Tu ISP bloquea el puerto 25 de salida. Prácticamente todos los proveedores residenciales lo hacen desde hace años como medida anti-botnet. No es negociable en la mayoría de planes de consumo, y llamar a soporte para pedir que lo abran casi nunca funciona en un plan residencial.
• Tu IP está en la Spamhaus PBL. La Policy Blocklist no es una lista de castigo: es un registro de rangos de IP desde los que por política no debería salir correo directo hacia el MX de destino. Los rangos residenciales y dinámicos están ahí por defecto, incluso si tu comportamiento es impecable. Como dice Spamhaus, incluso IPs estáticas de rangos de consumo pueden estar listadas. Salir de la PBL con una IP residencial dinámica no es un trámite: es imposible de sostener.

Sumado a eso, desde 2024 Gmail y Yahoo endurecieron sus requisitos: todos los remitentes necesitan SPF o DKIM, y los remitentes masivos necesitan SPF, DKIM y DMARC. Ya no basta con que el mensaje llegue: tiene que llegar autenticado.

El patrón que sí funciona: recepción en casa, salida por relay

La arquitectura realista para 2026 divide el problema en dos flujos independientes:

• Entrada (recepción): tu servidor en casa recibe el correo. Esto sí funciona con IP residencial, porque el que se conecta es el servidor remoto hacia ti. Necesitas un registro MX apuntando a tu dominio y el puerto 25 de entrada abierto en tu router. Muchos ISP bloquean el 25 de salida pero dejan pasar el de entrada — vale la pena verificarlo antes de descartar la idea.
• Salida (envío): tu servidor no entrega directo al MX destino. Le pasa el mensaje a un relay autenticado (un smarthost) que sí tiene reputación de IP y sale por el puerto 587 o 465. Esos puertos casi nunca están bloqueados.

El resultado es que tus correos, tus buzones y tus backups viven en tu casa —que es el objetivo real del autoalojamiento— mientras que la entrega delega en infraestructura que ya tiene reputación construida.

Cuánto cuesta el relay de salida

Servicio	Plan gratuito	Costo por volumen
Brevo	300 correos/día, permanente, sin expiración	Planes de pago para levantar el tope diario
SMTP2GO	1.000 correos/mes con tope de 200/día, sin expiración	Planes de pago desde el tier Starter
Amazon SES	No hay tier gratuito permanente	Plan Essentials: US$0,16 por cada 1.000 correos

Para un servidor familiar con dos o tres cuentas, el plan gratuito de Brevo o SMTP2GO alcanza de sobra: 300 correos al día es muchísimo más de lo que genera una casa. Dos detalles que conviene saber antes de elegir:

• SMTP2GO impone además un límite de 25 correos por hora en el plan gratuito, que desaparece cuando verificas tu dominio de remitente. Si no lo verificas, un lote de notificaciones puede topar el límite.
• Amazon SES reestructuró sus precios en planes (Essentials, Pro, Enterprise) y ya no hay un tier gratuito permanente. Además arranca en modo sandbox: solo puedes enviar a direcciones verificadas hasta que solicites y te aprueben la salida de producción.

Qué stack elegir

Antes de escribir una línea de configuración, decide qué nivel de control quieres. Las tres opciones razonables en 2026 son muy distintas en consumo de recursos:

Opción	RAM mínima	Qué obtienes	Para quién
Postfix + Dovecot a mano	~512 MB	Solo MTA + IMAP. Todo lo demás lo montas tú.	Quien quiere entender cada pieza
docker-mailserver	512 MB mínimo, 2 GB recomendado	Postfix, Dovecot, Rspamd, DKIM, sin base de datos: el filesystem es la configuración	El punto medio sensato
mailcow: dockerized	6 GiB + 1 GiB de swap	Suite completa: webmail SOGo, ActiveSync, antivirus, panel de administración	Quien quiere un Exchange casero

Dos advertencias importantes sobre mailcow que suelen costar una tarde:

• No se instala en LXC ni en OpenVZ. La documentación oficial es explícita: necesita virtualización completa (KVM, ESXi, Hyper-V) o bare metal. Si tienes un Proxmox y pensabas usar un contenedor LXC, tiene que ser una VM.
• Los 6 GiB son con la configuración por defecto. Puedes bajar bastante ese requisito poniendo SKIP_CLAMD=y y SKIP_FTS=y en mailcow.conf —el antivirus y el motor de búsqueda de texto completo son los que más RAM consumen— pero pierdes esas funciones. Cada worker de SOGo puede llegar a tomar unos 350 MiB, y la configuración por defecto arranca 20.
• En Debian 13 puede aparecer Exim ocupando el puerto 25. Es un problema típico de las actualizaciones desde Debian 12: si exim4 estaba instalado como MTA por defecto o venía arrastrado por otro paquete, el full-upgrade lo puede dejar activo, y eso bloquea el puerto antes de que mailcow arranque. Hay que quitarlo primero.

Si ya tienes un servidor con 2 GB de RAM y no quieres dedicarle 6 GiB al correo, docker-mailserver es la elección obvia. Es el que voy a usar como referencia en el resto del artículo, aunque los conceptos de DNS y relay aplican igual a cualquiera de los tres.

Lo que Debian 13 trae en 2026

Si vas por la ruta manual, vale la pena saber con qué versiones vas a trabajar. En Debian 13 (Trixie), los paquetes del repositorio estable son:

apt-cache policy postfix dovecot-core rspamd

Paquete	Versión en Trixie
postfix	3.10.13-0+deb13u1
dovecot-core	1:2.4.1+dfsg1-6+deb13u6
rspamd	3.12.1-1

El salto a Dovecot 2.4 es el cambio grande, y rompe configuraciones. Si vas a copiar y pegar un tutorial escrito para Dovecot 2.3, no va a funcionar. Verifica siempre con apt-cache policy qué versión tienes disponible antes de empezar, porque algunas de estas actualizaciones llegan por el repositorio de seguridad. Los cambios que más duelen:

• El primer ajuste de dovecot.conf debe ser dovecot_config_version. Hay un segundo ajuste obligatorio, dovecot_storage_version, para evitar incompatibilidades de formato de almacenamiento.
• La sección plugin { ... } ya no existe. Los ajustes de plugins pasaron a ser globales, como todos los demás.
• Las variables de una letra desaparecieron. Ahora se usa sintaxis de filtros con |: donde antes escribías %d ahora va %{user|domain}, y %u pasa a ser %{user}.
• mail_location se partió en varios ajustes independientes (mail_path, mail_driver, mail_index_path y compañía). Es el cambio que rompe más tutoriales viejos.
• Varios ajustes se renombraron: disable_plaintext_auth pasó a auth_allow_cleartext, auth_default_realm a auth_default_domain, mail_attachment_dir a mail_ext_attachment_path. Y login_access_sockets ya no existe: si sigue en tu configuración, Dovecot no arranca.
• Las secciones passdb y userdb exigen un nombre. passdb { ... } da error; tiene que ser passdb sql { ... } o similar.
• Las variables desconocidas ahora generan error en lugar de resolverse en silencio. Esto puede convertir un typo antiguo e inofensivo en un fallo de autenticación.
• El enlace simbólico dsync se eliminó. Usa doveadm sync o doveadm backup directamente.
• Los esquemas de contraseña débiles están deshabilitados por defecto. Si tu base de usuarios los usa, necesitas auth_allow_weak_schemes — o mejor, migra los hashes.

Otro detalle de Postfix que causa confusión: en las distribuciones que quitaron Berkeley DB, el tipo de base de datos por defecto para las tablas indexadas pasó a ser lmdb. Debian 13 todavía enlaza Postfix contra libdb5.3t64, así que ahí hash: sigue siendo el predeterminado y funciona. Pero si sigues esta guía en Arch, Fedora reciente o un build propio, el default puede ser otro. No adivines: pregúntale al binario antes de escribir main.cf.

postconf -d default_database_type

Si la respuesta es lmdb, tus líneas de main.cf tienen que decir lmdb:/etc/postfix/sasl_passwd en lugar de hash:. Con lmdb, postmap /etc/postfix/sasl_passwd genera un archivo .lmdb; con hash, genera un .db. Apuntar al tipo equivocado produce un error de tabla no encontrada que se lee como un problema de permisos y no lo es.

DNS: la parte que realmente decide si llegas o no

Esta es la sección que la gente hace rápido y luego pasa tres días depurando. Los registros mínimos, con ejemplo.com como dominio y mail.ejemplo.com como nombre del servidor:

# Nombre            Tipo       Valor
mail                A          198.51.100.10
@                   MX 10      mail.ejemplo.com.
autoconfig          CNAME      mail.ejemplo.com.
autodiscover        CNAME      mail.ejemplo.com.

Los registros autoconfig y autodiscover no son decorativos: son los que permiten que Thunderbird y los clientes de escritorio configuren la cuenta solos en lugar de pedirte servidores y puertos a mano.

Encima de eso van los tres registros de autenticación. SPF declara quién puede enviar en nombre de tu dominio:

@                   TXT        "v=spf1 mx a -all"

Ese -all significa “cualquier otro servidor no está autorizado, rechaza”. Aquí hay un detalle que casi nadie explica y que causa fallos de DMARC silenciosos: SPF se evalúa contra el dominio del remitente del sobre (envelope sender), no contra el From: que ve el usuario. Cuando envías a través de un relay, ese remitente del sobre suele ser del proveedor.

Con Amazon SES, por ejemplo, los mensajes usan por defecto un subdominio de amazonses.com como MAIL FROM. SPF pasa —pero pasa contra amazonses.com, no contra tu dominio, así que no alinea para DMARC. Tienes dos caminos limpios:

• Alinear vía DKIM. Es la ruta simple: si el mensaje va firmado con la clave DKIM de tu dominio, DMARC pasa por alineación DKIM aunque SPF apunte al proveedor. Para un servidor casero es lo que recomiendo.
• Configurar un MAIL FROM personalizado. Declaras un subdominio dedicado —por ejemplo bounce.ejemplo.com— con su propio registro SPF y un MX que apunte al host de feedback de la región de SES. Ese subdominio no debe usarse para enviar ni recibir correo normal.

Lo que no hay que hacer es meter include:amazonses.com en el apex del dominio y dar el problema por resuelto: eso autoriza los servidores del proveedor, pero no cambia contra qué dominio se evalúa SPF, así que la alineación DMARC sigue fallando.

Si tu relay reescribe el remitente del sobre a tu dominio —en Postfix se hace con sender_canonical_maps— entonces sí basta con el SPF simple de arriba, porque el dominio evaluado ya es el tuyo.

Después va DKIM, que firma criptográficamente cada mensaje. En docker-mailserver la clave se genera dentro del contenedor:

docker exec -it mailserver setup config dkim

Eso deja el registro TXT listo para copiar al DNS, con la forma:

mail._domainkey     TXT        "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

Un detalle que confunde a mucha gente: cada cadena de texto dentro de un registro TXT del DNS está limitada a 255 octetos por la RFC 1035. Una clave RSA de 2048 bits produce más de 300 caracteres en base64, así que el archivo generado la publica como un único registro TXT partido en dos cadenas entre comillas. Eso es normal y correcto — hay que pegarla completa, con las divisiones tal como vienen. El resolvedor las concatena al leerlas.

Y finalmente DMARC, que le dice al receptor qué hacer cuando SPF y DKIM fallan, y a dónde mandarte los reportes:

_dmarc              TXT        "v=DMARC1; p=reject; rua=mailto:[email protected]"

Mi recomendación práctica: arranca con p=none. Con esa política recibes los reportes agregados sin que nadie rechace tu correo mientras terminas de ajustar SPF y DKIM. Cuando lleves un par de semanas viendo reportes limpios, sube a p=quarantine y después a p=reject. Poner p=reject el primer día es la forma más rápida de perder correo legítimo sin darte cuenta.

El PTR: el registro que no controlas

El registro PTR (DNS inverso) debe resolver tu IP pública al nombre de tu servidor de correo. Lo configura quien te asignó la IP, no tú, y en una conexión residencial casi siempre resuelve a algo como modem-198-51-100-10.isp.net. Que el PTR no concuerde con el nombre anunciado en el saludo SMTP no suele provocar un rechazo directo en los grandes proveedores, pero sí penaliza tu puntuación de reputación en la mayoría de filtros anti-spam — y cuando arrancas sin historial, esa puntuación es todo lo que tienes.

Esta es exactamente la razón por la que el patrón de relay no es una concesión sino la arquitectura correcta: cuando la salida va por un smarthost, el PTR que importa es el del relay, no el tuyo.

dig -x 198.51.100.10 +short

Si eso devuelve el hostname de tu ISP y no mail.ejemplo.com, ya sabes que la entrega directa no es una opción.

Configurar el relay de salida en Postfix

Esta es la pieza central. En /etc/postfix/main.cf:

relayhost = [smtp.proveedor.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Los corchetes alrededor del host importan: le dicen a Postfix que trate ese valor como un nombre literal y no busque su registro MX. Y recuerda ajustar hash: a lmdb: si postconf -d default_database_type te dijo eso.

Las credenciales van en /etc/postfix/sasl_passwd, una línea con el mismo host entre corchetes:

[smtp.proveedor.com]:587 usuario:contraseña

Ese archivo contiene una contraseña en texto plano, así que hay que tratarlo como tal: generar el índice, restringir permisos y recargar.

sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.*
sudo systemctl reload postfix

Cada vez que cambies el archivo de texto tienes que volver a ejecutar postmap: Postfix lee el índice, no el texto.

Puertos que hay que abrir

Antes de arrancar el servicio, verifica que nada más esté ocupando los puertos. El comando que la propia documentación de mailcow recomienda:

ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'

El reparto de responsabilidades es este:

Puerto	Servicio	Hay que abrirlo en el router?
25	SMTP entre servidores	Sí, solo entrada
465	SMTP con TLS implícito (envío de clientes)	Solo si accedes desde fuera
587	SMTP submission con STARTTLS	Solo si accedes desde fuera
993	IMAP sobre TLS	Solo si accedes desde fuera
4190	ManageSieve (filtros del lado del servidor)	Opcional
80 / 443	Webmail y validación ACME de certificados	Sí, si usas Let’s Encrypt con HTTP-01

Un consejo que ahorra exponer media casa a internet: si ya tienes una VPN montada —WireGuard o Tailscale— deja 993, 587 y 465 accesibles solo por la VPN y abre al mundo únicamente el 25 de entrada. Tus clientes de correo se conectan por el túnel y la superficie de ataque se reduce a un solo puerto.

Otra nota de la documentación de mailcow que aplica a cualquier stack en Docker: firewalld y ufw chocan con las reglas que Docker gestiona. Si necesitas filtrar tráfico hacia contenedores, las reglas van en la cadena DOCKER-USER, que sobrevive a un reinicio del servicio de Docker. Ojo: sobrevivir a systemctl restart docker no es lo mismo que sobrevivir a un reinicio del host — para eso necesitas persistir las reglas con netfilter-persistent o el equivalente de tu distribución.

Verificar que funciona de verdad

El error clásico es dar por bueno el montaje porque un correo llegó a otra cuenta propia. Eso no prueba nada: entre dos servidores desconocidos hay filtros que tu propio buzón no aplica. Tres verificaciones que sí sirven:

• Revisa la cola. postqueue -p te muestra qué quedó atascado y con qué error. Una cola que crece es tu primera señal de que la salida no está saliendo.
• Lee los logs en tiempo real. journalctl -u postfix -f en instalación nativa, o docker compose logs -f mailserver en Docker. Los mensajes de rechazo de los servidores remotos son explícitos y suelen incluir la razón exacta.
• Usa un verificador externo. Envía un correo a un servicio de prueba de correo y revisa el reporte: te devuelve el resultado de SPF, DKIM, la verificación iprev y la puntuación de spam. Es el único chequeo que evalúa lo mismo que evalúa Gmail.

Si SPF pasa y DKIM falla, casi siempre es la clave TXT mal pegada en el DNS. Si ambos pasan pero el correo cae en spam, mira la reputación de la IP de salida y verifica que estás usando el relay y no entrega directa.

Backups: sin esto, no tienes un servidor de correo

Un servidor de correo autoalojado sin backups es una forma elaborada de perder tu historial. En docker-mailserver los mensajes viven en /var/mail/${dominio}/${usuario} y las cuentas se gestionan con archivos planos (postfix-accounts.cf), sin MariaDB de por medio como en mailcow. Eso hace el respaldo trivial con cualquier herramienta de snapshots incrementales cifrados.

Hay tres cosas que respaldar, y la tercera es la que se olvida:

• Los buzones completos, con su estructura de directorios.
• El directorio de configuración, que en docker-mailserver es también la base de datos de cuentas.
• Las claves DKIM privadas. Si las pierdes, todo el correo que ya enviaste queda con firmas que nadie puede volver a verificar contra una clave que ya no existe, y tienes que publicar un selector nuevo desde cero.

En instalación nativa con Dovecot 2.4 la herramienta de sincronización es doveadm backup, no el viejo dsync. Ten en cuenta que los comandos de doveadm que actúan sobre buzones concretos —backup, sync, fetch, expunge, move— exigen -u, -F o -A, o pasar --no-userdb-lookup explícitamente. Los comandos administrativos globales, como doveadm reload, no lo necesitan.

Cuándo no vale la pena

Voy a ser honesto porque es la parte que casi ningún tutorial dice: si tu objetivo es tener correo confiable para tu dominio y nada más, alquilar un buzón administrado te va a costar unos pocos dólares al mes y te va a ahorrar el problema completo de reputación de IP.

El autoalojamiento de correo tiene sentido cuando el objetivo es otro:

• Quieres que tus mensajes estén físicamente en tu casa, en tu disco, bajo tu control.
• Necesitas decenas de direcciones y alias sin pagar por buzón.
• Quieres aprender cómo funciona SMTP de verdad, no en teoría.
• Tienes servicios internos —Nextcloud, Gitea, alertas de monitoreo— que necesitan un buzón local sin salir a internet.

Ese último caso es, de hecho, el más sólido de todos, y suele ser el que menos requisitos tiene: para correo puramente interno no necesitas reputación, ni PTR, ni pelear con la PBL.

Conclusión

Montar un servidor de correo en casa en 2026 no es difícil por la configuración: Postfix, Dovecot y Rspamd están mejor documentados que nunca, y docker-mailserver reduce el montaje a un archivo de Compose y un puñado de registros DNS. Es difícil por la política de internet: el puerto 25 de salida está cerrado, la Spamhaus PBL lista tu rango por diseño y el PTR no está en tus manos.

La respuesta no es rendirse, es dividir el problema. Recibe y almacena en casa —ahí ganas privacidad y control real— y delega la salida a un relay autenticado que ya tenga reputación construida. Con SPF, DKIM y DMARC bien puestos, y arrancando DMARC en p=none hasta que los reportes estén limpios, tu correo llega a Gmail igual de bien que el de cualquiera. Y sigue viviendo en tu disco.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux