Servidor de correo propio: guía operativa

Montar un servidor de correo propio es viable si controla una IP estable, DNS inverso, salida SMTP, vigilancia y respuesta a incidentes. Instalar Postfix y Dovecot es la parte fácil; mantener autenticación, reputación, colas, copias y parches exige trabajo continuo y no garantiza llegar a la bandeja de entrada.

Decida primero si debe alojar el correo

El correo público no es un servicio que se instala y se olvida. Cada mensaje depende de DNS, conectividad, certificados, filtros, colas y la reputación acumulada por la IP y el dominio. Si nadie vigilará el sistema fuera del horario cómodo, un servicio administrado suele ser la decisión sensata.

El autoalojamiento encaja cuando necesita control técnico real, puede aceptar guardias operativas y dispone de una infraestructura estable. No compensa por orgullo, por evitar una cuota pequeña ni por aprender sobre una cuenta empresarial crítica. Haga el laboratorio con un dominio separado y sin mensajes importantes.

Use el dominio principal solo cuando la retirada esté ensayada.

Antes de comprar un servidor, confirme estos requisitos:

• una dirección IP pública estable y no compartida con emisores desconocidos;
• capacidad del proveedor para configurar el registro PTR solicitado;
• conectividad entrante y saliente para SMTP, sin bloqueos incompatibles;
• DNS bajo su control y una persona responsable de cambios y renovaciones;
• vigilancia externa, alertas, copias y una ruta de recuperación probada;
• tiempo para revisar abusos, actualizar paquetes y responder a bloqueos.

Una carencia en esa lista no se arregla con más memoria RAM. El límite operativo manda más que el tamaño del servidor.

Compruebe la IP, el PTR y el puerto de SMTP

El nombre público, por ejemplo mail.ejemplo.es, debe resolver hacia la IP del servidor. El DNS inverso debe devolver un nombre coherente, pero el PTR lo administra normalmente quien controla el bloque de direcciones. Pregunte al proveedor antes de contratar; descubrir después que no ofrece cambios de PTR convierte la migración en una mudanza inmediata.

El puerto veinticinco se utiliza para transferencia SMTP entre servidores. Algunos proveedores restringen su salida o exigen una solicitud previa. Verifique tanto la política contractual como una prueba real desde la instancia prevista. Que el cortafuegos local permita una conexión no demuestra que la red del proveedor la transporte.

Compruebe también la historia de la IP. Una dirección reasignada puede arrastrar mala reputación, aunque usted no haya enviado nada. No existe una limpieza instantánea ni un registro DNS que garantice entrega. Si el rango tiene problemas persistentes, cambiar de IP o de proveedor puede ser más barato que discutir con cada receptor.

Fije un nombre coherente y publique el DNS mínimo

Use un nombre de host dedicado y estable. Su registro A, y el AAAA si realmente operará IPv6, deben apuntar al servidor. El PTR debe volver a ese nombre y la identificación SMTP debe ser coherente. Evite anunciar IPv6 a medias: una ruta sin PTR, filtros o vigilancia duplica la superficie de fallo.

El registro MX del dominio señala qué servidor recibe el correo. No debe apuntar directamente a una dirección IP ni a un alias improvisado. Después, publique y compruebe tres controles distintos:

Empiece DMARC con observación y revise los informes antes de endurecer la política. Un rechazo prematuro puede bloquear servicios legítimos que todavía envían sin alineación. El RFC vigente sustituyó al estándar experimental anterior, de modo que las recetas antiguas necesitan una revisión.

Rote las claves DKIM mediante selectores y guarde la clave privada fuera de directorios públicos. Rspamd puede firmar correo autenticado o local cuando se integra con Postfix, pero la firma debe comprobarse desde fuera. Que exista una clave en disco no demuestra que el mensaje haya salido firmado.

Separe recepción y envío autenticado

Un servidor público debe aceptar mensajes para sus dominios locales. No debe reenviar mensajes arbitrarios desde Internet hacia terceros. Postfix separa el control de relay de otros filtros; una regla permisiva mal situada puede convertir el sistema en relay abierto y quemar la reputación en pocas horas.

Los clientes de correo deben usar el servicio de submission con autenticación y TLS. El envío de usuario no debería compartir una política anónima con la recepción entre servidores. Limite además qué remitentes puede usar cada identidad autenticada y aplique límites razonables de conexiones y mensajes.

El servidor recibe mensajes para sus dominios públicos, pero solo debe reenviar hacia terceros cuando el cliente está autenticado. La cola gestiona fallos temporales; no concede permiso para usar el servidor como relay. Dos rutas, dos políticas: mezclarlas facilita el abuso y dificulta investigar quién envió cada mensaje.

Pruebe el relay desde una red externa y con destinatarios locales y remotos. Una entrega rechazada durante la prueba es preferible a descubrir el error mediante una lista de bloqueo. No copie una configuración completa sin entender el orden y el alcance de sus restricciones.

Proteja SMTP, IMAP y las claves con TLS

TLS cifra el transporte; no demuestra que un mensaje sea legítimo ni garantiza su destino. En la recepción SMTP pública suele negociarse de forma oportunista porque no todos los servidores remotos aplican la misma política. En el servicio de submission, la autenticación debe ofrecerse solo después de establecer TLS.

Dovecot debe exigir una conexión protegida para el acceso a buzones. El certificado debe cubrir los nombres que usan los clientes y la clave privada necesita permisos restrictivos. Si un cliente ACME renueva el certificado, automatice también la validación y la recarga segura de los servicios.

Vigile la fecha de renovación y pruebe desde fuera. Un proceso automático que genera un certificado nuevo pero deja al servicio usando el antiguo es una automatización decorativa. El certificado válido es el que presenta el servidor, no el que descansa en el disco.

Entregue al buzón sin convertirlo en una caja negra

Postfix puede aceptar y poner en cola el mensaje; Dovecot puede servir buzones por IMAP y recibir entregas locales mediante LMTP. Esa separación ayuda a localizar fallos: recepción SMTP, filtro, entrega local y acceso del usuario deben tener registros y comprobaciones independientes.

Defina cuotas, límites de tamaño y política de buzones antes de abrir cuentas. Decida qué ocurre con destinatarios inexistentes y rechácelos durante la conversación SMTP cuando sea posible. Aceptar primero y rebotar después produce retrodispersión y oculta errores de directorio.

No almacene contraseñas reversibles. Use esquemas admitidos por la versión instalada, proteja los archivos de credenciales y limite los procesos que pueden consultarlos. La misma cuenta no debería dar acceso administrativo al sistema operativo.

Cada privilegio compartido amplía el daño de una credencial robada.

Filtre abuso sin prometer una bandeja perfecta

Rspamd puede inspeccionar mensajes a través de la integración Milter con Postfix. Combine reputación, SPF, DKIM, DMARC, análisis de contenido y aprendizaje con prudencia. Ninguna puntuación distingue siempre una factura legítima de un fraude bien escrito.

Empiece con acciones conservadoras y observe falsos positivos. Mantenga una cuarentena administrable o cabeceras de clasificación antes de aplicar rechazos agresivos. Los límites por usuario autenticado, dirección y ritmo reducen el daño si una contraseña se filtra.

Proteja el servicio de submission contra intentos repetidos, pero no convierta cada error de contraseña en un bloqueo permanente. Registre el origen, alerte por cambios bruscos y tenga un procedimiento para revocar sesiones, cambiar credenciales y detener la salida.

Vigile la cola, los registros y la reputación

La cola es el tablero de instrumentos del correo saliente. Observe su tamaño, antigüedad, motivos de aplazamiento y destinos afectados. Un aumento puede indicar DNS roto, rechazo remoto, falta de espacio, fallo de TLS o una cuenta comprometida.

Las alertas útiles describen una acción. Avise cuando crezca la cola, caduque un certificado, falle la firma DKIM, deje de responder IMAP o aparezca una tasa anómala de autenticación. Conserve registros el tiempo suficiente para reconstruir un incidente, con acceso restringido porque contienen direcciones y metadatos.

Pruebe recepción y envío desde redes externas. Revise cabeceras de autenticación y compare entregas a varios receptores, sin usar cuentas personales como única sonda. La aceptación SMTP no equivale a bandeja de entrada: reputación, contenido y política del receptor siguen decidiendo.

Haga copias que puedan restaurar el servicio

Copie buzones, índices necesarios, configuración, mapas, claves DKIM, certificados cuando proceda y la información que vincula usuarios con almacenamiento. Separe las copias del servidor y aplique cifrado y control de acceso. El correo contiene datos sensibles; una copia abierta es una fuga completa.

Una restauración válida recupera mensajes, permisos, identidades y capacidad de recibir correo nuevo. Pruebe en un entorno aislado y documente cuánto tarda. Dovecot ofrece herramientas de sincronización, pero ninguna orden sustituye la verificación de una cuenta real y sus carpetas.

La copia no conserva la reputación de una IP ni cambia un PTR. Si el plan de recuperación usa otra dirección, incluya DNS, certificados, calentamiento prudente y comunicación. Migrar también cuesta, sobre todo cuando el procedimiento solo existía en la memoria del administrador.

Parchee con una retirada preparada

Mantenga sistema operativo, Postfix, Dovecot, Rspamd y bibliotecas TLS dentro de versiones soportadas. Lea cambios incompatibles antes de actualizar y conserve una copia de la configuración efectiva. Pruebe sintaxis, reinicios, autenticación, entrega local y relay después de cada cambio.

Prepare la retirada antes del lanzamiento. Mantenga acceso a un servicio alternativo, inventario de buzones, exportación comprobada y control del DNS. Reducir TTL antes de una migración ayuda, pero no elimina cachés ni mensajes ya en cola.

Un plan de vuelta debe indicar quién decide, qué señales lo activan y cómo se evita perder mensajes durante el cambio. No improvise un MX secundario sin operarlo y filtrarlo correctamente: puede convertirse en otra entrada de spam o en un almacén olvidado.

Operar correo propio puede aportar control, pero ese control incluye las guardias, los rechazos y la reputación. Si cumple los requisitos y acepta esa carga, construya por capas y valide cada frontera. Si no, delegar el transporte no es rendirse: es quitar una pieza frágil de una nave de trabajo.