Autoalojar tu servidor de correo

Artículo original ↗ Discusión en Hacker News ↗

Autoalojar un servidor de correo promete mayor control, independencia de los grandes proveedores y cierto aislamiento frente al escaneo gubernamental o corporativo de mensajes privados. Los comentaristas señalan que las herramientas modernas y los stacks listos para usar (por ejemplo, Mailcow, Stalwart, Mail-in-a-Box, rspamd) hacen que la configuración básica y el filtrado de spam sean bastante manejables, especialmente en un VPS con una IP limpia y SPF/DKIM/DMARC bien configurados. Sin embargo, muchos sostienen que la entrega saliente fiable a grandes proveedores se ha vuelto tan frágil —debido a sistemas de reputación de IP, listas negras y filtrado opaco— que para la mayoría de la gente es más seguro alojar solo el correo entrante o simplemente usar un proveedor de pago manteniendo un dominio propio para conservar la portabilidad.

Sentimiento general sobre autoalojar correo electrónico

  • Opiniones muy divididas.
  • Algunos informan de 10–20+ años de autoalojamiento sin problemas o con pocos incidentes.
  • Otros lo describen como un dolor de cabeza constante, especialmente para la entrega saliente, y dicen que nunca volverían a hacerlo dada la existencia de servicios alojados baratos.

Dificultad y carga operativa

  • Recibir correo y la configuración básica del stack (Postfix/Dovecot/rspamd, etc.) se considera sencillo por muchos.
  • La parte difícil es el mantenimiento a largo plazo: seguir el ritmo de los estándares (SPF/DKIM/DMARC, DANE, certificados), el filtrado de spam y la depuración de problemas intermitentes y opacos.
  • Varios subrayan que ser administrador de correo es un trabajo real; hacerlo bien en el tiempo libre no es trivial.

Entregabilidad y reputación de IP

  • Se cita ampliamente como el principal problema, no el filtrado de spam en sí.
  • Incluso con SPF/DKIM/DMARC, PTR e IPs limpias configurados correctamente, la gente informa de:
    • Mensajes descartados silenciosamente o enviados a spam, especialmente en grandes proveedores (Gmail, Outlook/Hotmail, Yahoo, dominios alojados por Microsoft).
    • Rangos de IP de proveedores populares de VPS que a veces están efectivamente “quemados” por abusos pasados.
  • Otros informan de una entregabilidad casi perfecta durante muchos años, atribuyendo el éxito a:
    • IPs limpias y de larga vida; ASes reputados; a veces conexiones de nivel empresarial o colocation.
    • Solicitudes ocasionales de inclusión manual en listas blancas.
  • Muchos recomiendan relays SMTP (SES, smtp2go, MailPace, etc.) como un seguro barato.

Privacidad, control y descentralización

  • Argumentos a favor del autoalojamiento:
    • Evitar el bloqueo de proveedor y los baneos arbitrarios de cuentas.
    • Mantener los datos fuera de los grandes proveedores, especialmente bajo regímenes de escaneo regulatorio.
    • Preservar la naturaleza descentralizada del correo electrónico; más servidores independientes contrarrestan la centralización.
  • Contraargumentos:
    • El correo electrónico es intrínsecamente entre dos partes; si el otro lado usa un gran proveedor, igualmente ve el contenido.
    • Para muchos, clientes offline más dominios propios en un proveedor alojado dan “control suficiente”.

Arquitecturas y herramientas

  • Stacks/soluciones mencionados: Stalwart, Mailcow, Mail-in-a-Box, docker-mailserver, iRedMail (se prefiere la versión de pago), maddy, el clásico Postfix+Dovecot+rspamd, qmail.
  • Patrones híbridos:
    • Autoalojar el almacenamiento entrante y reenviar el saliente mediante un tercero.
    • Servidores domésticos usando relays VPS para evitar bloqueos de puertos del ISP o problemas de reputación.

Alternativas y punto intermedio

  • Recomendación común: comprar tu propio dominio y usar un proveedor que soporte dominios y alias personalizados; esto ofrece portabilidad sin la carga de administración.
  • Algunos proponen alojamiento cooperativo/comunitario como compromiso entre el hazlo tú mismo total y los grandes proveedores.