Crear un servidor de correo propio: ¿merece la pena?

Crear un servidor de correo propio es la decisión de administrar usted mismo la pila SMTP: el agente de transferencia de correo, el almacén IMAP, el motor antispam, los certificados TLS, los registros DNS de autenticación, el DNS inverso, las copias de seguridad y la reputación de una dirección IP de la que los grandes receptores no han oído hablar nunca. Lo que compra con eso es custodia total. Lo que cuesta no es la instalación inicial, que es un buen fin de semana. Es el goteo posterior, para siempre.

Quiero ser justo con la idea, porque he llevado mi propio correo y quien lo hace no se equivoca sobre lo que quiere. Se equivoca a menudo sobre lo que tiene que aceptar para conseguirlo.

¿Qué cuesta de verdad crear un servidor de correo propio?

Dinero, no. Atención, en cantidades pequeñas e imprevisibles, concentrada en la única parte que no puede controlar: si los servidores de otras personas aceptan su correo.

Empiece por la fontanería, que es la mitad fácil. Registros SPF, DKIM y DMARC alineados. Un registro PTR que coincida con su nombre HELO, lo que significa una IP cuyo DNS inverso pueda configurar. Certificados que se renueven solos durante años sin que ningún humano se dé cuenta. MTA-STS e informes TLS si quiere que el TLS entrante sea obligatorio y no oportunista. Parchear un demonio de correo que está expuesto directamente a internet. Una pila antispam que necesita corpus de entrenamiento y ajuste. Copias de seguridad de las que haya restaurado de verdad alguna vez, no copias de seguridad que haya configurado.

Ahora la mitad difícil. Muchas nubes bloquean por defecto el puerto 25 de salida — Google Cloud no lo abre en absoluto, AWS exige una solicitud, Azure lo bloquea para la mayoría de los tipos de suscripción — así que su elección de proveedor está limitada antes de empezar. Una IP nueva en un bloque pequeño recibe greylisting, diferimientos o rechazos de los grandes receptores por muy correcta que sea su configuración, y calentarla es cuestión de semanas de volumen bajo, constante y deseado. Las listas negras hay que vigilarlas, porque uno se entera de que está en una por un mensaje de rebote, normalmente el del destinatario que importaba. Desde febrero de 2024, Google y Yahoo exigen correo autenticado, DMARC para remitentes masivos, baja en un clic y una tasa de queja por spam por debajo de en torno al 0,3 %: un suelo que sigue subiendo y que nadie le consultó.

El estado estable es quizá una hora al mes. El estado malo es un sábado demostrándole a un sistema de reputación que usted no es un spammer mientras sus facturas se quedan sin entregar. Esa varianza es el precio de verdad, y no baja con la habilidad. Baja con un historial de volumen que no se puede falsificar.

¿Qué quería usted en realidad al montar el servidor propio?

Casi siempre tres cosas, y ninguna es el servidor de correo: la custodia del archivo, el correo en un dominio propio y la libertad de irse.

Custodia significa que los bytes están en un sitio del que nadie se los puede llevar: ninguna cuenta suspendida que se trague doce años de correspondencia, ninguna jurisdicción pegada al domicilio social de un proveedor, ningún tique de exportación que abrir. Dominio propio significa que las direcciones son suyas, así que el proveedor es un detalle de implementación y no su identidad. Portabilidad significa que el archivo está en un formato que se puede leer con algo que no sea el software del propio proveedor.

Hay un cuarto motivo, más callado: no ser una fuente de datos. Sin escaneo, sin segmentación publicitaria, sin entrenar modelos con el contenido de su bandeja.

Mire esa lista y fíjese en lo que falta. Nadie quería operar un MTA. Nadie quería tener opiniones sobre el greylisting. El demonio era el peaje, no el destino.

¿Cuándo es un servidor de correo propio la decisión correcta?

En cinco situaciones, y son reales.

Cuando el correo no sale nunca de su red. Notificaciones internas, salida de cron, ticketing, alertas de monitorización: un MTA local que entrega a buzones locales se salta todos los problemas de entregabilidad, porque no hay receptores externos a los que convencer.

Cuando necesita un control a nivel de protocolo que los servicios alojados no exponen: enrutados raros, Sieve personalizado a escala, políticas por dominio, integración con algo antiguo de lo que dependen cosas.

Cuando la normativa o un aislamiento físico exigen que usted opere el camino completo, y ninguna cantidad de custodia contractual sustituye al control físico.

Cuando ya administra infraestructura monitorizada con alguien de guardia. Si Prometheus ya avisa y alguien ya lleva el teléfono de guardia, añadir correo es un coste marginal y no una disciplina nueva.

Y cuando administrarlo es el objetivo. Aprender cómo funciona el correo operándolo es un uso genuinamente bueno de un fin de semana, y yo no se lo quitaría a nadie de la cabeza.

Dos variantes más ligeras merecen una mención, porque resuelven la mayor parte del problema. El servidor propio de solo recepción es fácil, porque el correo entrante no tiene requisito de reputación. Y enviar el correo saliente a través de un smarthost autenticado, conservando su propio almacén IMAP, se deshace de la única parte más difícil y le deja el resto.

¿Cuál es el camino intermedio?

Enrutado gestionado más almacenamiento propio. Un proveedor se encarga de los registros MX, de la verificación de SPF, DKIM y DMARC, del filtro de spam y de la reputación de envío; cada mensaje se cifra y se escribe en almacenamiento de objetos que está en su propia cuenta: su bucket S3 o R2, su servidor WebDAV, incluso un repositorio Git.

El reparto sigue a los modos de fallo, y por eso aguanta. Perder el archivo es permanente e irrecuperable. Un veredicto de spam equivocado es una molestia que se arregla el martes. La reputación saliente la deciden desconocidos con datos a los que usted no tiene acceso. Entregar los problemas reversibles y con mucha pericia técnica a alguien que se dedica a eso a tiempo completo, y quedarse con el irreversible, es el reparto que yo elegiría a propósito incluso si el servidor propio fuese gratis.

Lo que se obtiene, en concreto: la copia de seguridad pasa a ser versionado del bucket y una regla de ciclo de vida en lugar de una petición de función. La migración pasa a ser reapuntar a quien escribe en lugar de extraer el archivo. La región y la jurisdicción pasan a ser dos ajustes que se eligen por separado. Y si el servicio de enrutado desaparece el mes que viene, usted pierde una interfaz y no una década de correo.

¿Qué no le da el camino intermedio?

Cuatro cosas, y fingir lo contrario sería deshonesto.

Sigue confiando en un operador de enrutado. El filtro de spam tiene que leer el mensaje, así que su texto en claro existe en la memoria de otra empresa antes de cifrarse en reposo. Cualquier servicio que filtre su correo y a la vez asegure no verlo nunca describe algo que no puede funcionar.

Los metadatos de transporte siguen expuestos. El SMTP negocia en abierto entre saltos, así que las direcciones del sobre, las marcas de tiempo y el camino que recorrió un mensaje son visibles para cada relé que lo maneja. Dónde descansa un mensaje no es cómo viajó.

No puede cambiar el servidor de correo. Si lo que quería era parchear Postfix, esto no es eso.

Y la custodia le entrega la responsabilidad que viene con el poder. Una política de bucket permisiva publica su correo. Un bucket borrado borra su correo. Nadie va a restaurarlo desde la copia de seguridad que usted no hizo. Ese es el trato, y es el mismo trato que ofrece el servidor propio, menos la parte en la que un sistema de reputación que no conoce decide si su correo llega.