Servidor de correo multidominio: arquitectura y costes

Administras un servidor de correo multidominio para 30 dominios de clientes. Cada uno necesita sus registros MX, su clave DKIM, su registro SPF, su política DMARC, sus reglas de cuarentena y el seguimiento de su reputación de envío. La pregunta no es si un servidor puede con todo, pues Postfix y Dovecot llevan dos décadas haciéndolo, sino cómo responderá la instalación cuando una campaña de un cliente perjudique la reputación de la IP compartida.

Un servidor de correo multidominio es una arquitectura adecuada para muchos operadores. Para otros, que esperan ahorrar frente a un servicio alojado multicliente, puede salir caro. Esta guía repasa la arquitectura, las configuraciones que ayudan a separar clientes, tres fallos de aislamiento importantes al crecer y los costes que conviene comparar entre una instalación propia y un plan alojado como TrekMail Agency. Las configuraciones son ejemplos incompletos que deben adaptarse a las versiones utilizadas; los precios y prestaciones reflejan el escenario del artículo, no una oferta vigente garantizada.

Qué es realmente un servidor de correo multidominio

Un servidor de correo multidominio es una pila de transporte que recibe y envía correo para varios dominios sobre la misma infraestructura. Una instancia de Postfix recibe mensajes para client1.com, client2.com y client3.com; una instancia de Dovecot almacena los buzones de los tres con controles de separación; una cola de salida envía mensajes con firma DKIM por dominio.

No es exactamente lo mismo que «alojamiento de correo multidominio» como expresión comercial, que suele describir un plan donde se añaden varios dominios a una cuenta de facturación. El servidor multidominio es la infraestructura que hace posible ese plan: la configuración real de Postfix y Dovecot. Puede ejecutarse en tu propio VPS o en un proveedor como TrekMail Agency, que asume la operación de la plataforma multicliente.

Tres arquitecturas para gestionar varios dominios

Al gestionar 10 dominios o más suelen aparecer tres modelos de arquitectura. Cada uno combina de forma distinta coste, control y complejidad operativa; la elección depende tanto del tiempo técnico disponible como del presupuesto. Elegir con previsión puede evitar una reestructuración costosa dos años después, cuando la instalación inicial se quede pequeña.

Modelo 1: un servidor por dominio

La opción más sencilla consiste en una instancia de Postfix/Dovecot por dominio de cliente. No hay clientes compartiendo esa pila, aunque siguen existiendo riesgos en el sistema operativo, el hipervisor y la administración. Cada dominio tiene su VPS, su IP y su gestión de reputación. Puede encajar con 3-5 dominios que correspondan a negocios de cierta entidad. Con 20+ dominios, aplicar parches, supervisar servidores y renovar certificados empieza a multiplicar el trabajo de forma casi lineal.

Modelo 2: un servidor multidominio multicliente

Es el modelo habitual de muchas agencias: una pila Postfix + Dovecot atiende todos los dominios mediante virtual_mailbox_domains, claves DKIM por dominio y una configuración de Dovecot consciente de cada cliente. Se administra una infraestructura para N dominios. Como referencia orientativa, el ahorro puede empezar alrededor de 10 dominios y la complejidad resultar considerable cerca de 200. A partir de ahí, algunos operadores pasan a un proveedor alojado o distribuyen los dominios entre servidores según sus necesidades y perfiles de reputación.

Modelo 3: servicio alojado multicliente, contratar o construir

Para una agencia, mantener correo multidominio puede exigir una dedicación técnica importante, en ocasiones superior al coste de contratarlo. El escenario del artículo sitúa TrekMail Agency en $29 al mes, o $23.25/mes con facturación anual, para 1,000 dominios, con gestión de claves DKIM y SPF/DMARC y controles sobre las colas de salida. Hay que verificar el alcance actual: una cola por cuenta no equivale a una cola aislada por dominio ni a reputaciones IP independientes. La agencia evita administrar Postfix, pero sigue gestionando usuarios, DNS y políticas. El punto de equilibrio depende de las horas de ingeniería anuales que realmente se ahorren, no de una equivalencia automática con una sola hora.

Postfix + Dovecot: la combinación habitual

Para una instalación propia, una combinación habitual en 2026 es Postfix para el transporte SMTP y Dovecot para IMAP, el almacenamiento y la entrega LMTP. Los ejemplos siguientes parten de Debian o Ubuntu LTS. Los principios también sirven en otras distribuciones, pero las rutas, permisos y directivas pueden variar según la versión.

virtual_mailbox_domains y los mapas

Postfix admite dominios virtuales mediante la directiva virtual_mailbox_domains. En lugar de escribir todos los dominios directamente en main.cf, puedes mantenerlos en un mapa hash o, al crecer, en un backend SQL o LDAP:

# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps    = hash:/etc/postfix/vmailbox
virtual_alias_maps      = hash:/etc/postfix/valias
virtual_transport       = lmtp:unix:private/dovecot-lmtp

El archivo /etc/postfix/vhosts enumera los dominios aceptados, uno por línea, con el dominio como clave y el valor correspondiente al formato hash, no como una lista de dominios sin valor. /etc/postfix/vmailbox permite comprobar los destinatarios virtuales; con este transporte LMTP, su valor no determina por sí mismo la ubicación final del buzón, que resuelve Dovecot. /etc/postfix/valias gestiona los alias, como info@client1.com → real-person@client1.com.

Directorios de Dovecot por dominio

Dovecot puede almacenar los buzones en directorios separados por dominio. Una disposición habitual es /var/vmail/<domain>/<user>/. El ejemplo se configura así:

# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmail

%d representa el dominio y %n la parte local de la dirección. Esta organización facilita las copias de seguridad y las tareas por cliente: permite usar rsync sobre un directorio concreto. No constituye por sí sola una barrera de seguridad; los permisos, la autenticación, la autorización y los procesos que acceden al almacenamiento también deben revisarse.

LMTP para la entrega de Postfix a Dovecot

Las instalaciones modernas suelen usar LMTP, Local Mail Transfer Protocol, para entregar el correo de Postfix a Dovecot. Puede evitar el coste de lanzar un proceso dovecot-deliver por mensaje y aplicar cuotas por destinatario, según la configuración. Dovecot debe escuchar en un socket Unix accesible para Postfix con los permisos adecuados.

SPF, DKIM y DMARC por dominio a escala

El reto no suele ser únicamente el transporte, sino mantener SPF, DKIM y DMARC correctamente para todos los clientes y gestionar las claves DKIM con una política acorde al riesgo. Una rotación bien preparada puede limitar la exposición de claves comprometidas; no corrige por sí misma una mala reputación. Estas tareas ayudan a explicar el coste operativo de una instalación propia y el valor potencial de un servicio alojado.

SPF por dominio

Los dominios utilizados como identidad SMTP deben autorizar sus emisores mediante los registros SPF correspondientes, que se publican en DNS y no en el servidor de correo. Al añadir una IP de salida hay que revisar las identidades afectadas y sus mecanismos SPF. No siempre es necesario modificar cada dominio si todos utilizan un include común que se actualiza correctamente. También necesitas acceso al proveedor DNS o la colaboración del cliente. Encontrarás el procedimiento en nuestra guía de configuración de SPF.

DKIM por dominio, con rotación trimestral como ejemplo

Gestionar DKIM para numerosos dominios requiere trabajo. Cada dominio firmante utiliza su par de claves: la privada firma el correo saliente y la pública se publica en DNS bajo un selector. Una política trimestral es una posibilidad, no una obligación universal. Implica publicar nuevos selectores y comprobar su disponibilidad antes de retirar los anteriores, conservándolos mientras puedan llegar mensajes firmados con ellos. Con 100 dominios, ese calendario supondría 400 actualizaciones DNS al año si se hace manualmente. La guía de DKIM explica el proceso de rotación.

Informes DMARC a escala

DMARC permite solicitar informes agregados por dominio. Muchos receptores participantes los envían como archivos XML, a menudo diariamente, pero no todos informan ni siguen el mismo calendario. Analizarlos, atribuirlos al cliente correcto y extraer señales útiles, como una posible suplantación o un emisor mal configurado, puede convertirse en un proyecto técnico propio. La guía de DMARC aborda ese análisis.

Tres fallos de aislamiento que conviene prever

La calidad de un servidor multidominio depende de cómo se separen los clientes y se controlen los recursos compartidos. Los tres fallos siguientes pueden quedar ocultos hasta un incidente real. Conviene detectarlos en las revisiones y pruebas previas, no durante un problema de entrega en producción.

Fallo 1: deterioro de la reputación de una IP compartida

Si varios clientes utilizan la misma IP de salida, una campaña mal gestionada puede afectar a los demás. Una lista de mala calidad o envíos no deseados pueden desencadenar bloqueos y limitaciones, incluso en Gmail. Separar determinados emisores en IP distintas puede reducir parte del impacto, pero requiere volumen adecuado, calentamiento y supervisión. Cambiar de IP no soluciona el abuso ni debe utilizarse para eludir bloqueos. Una IP dedicada tampoco garantiza la entrega; la reputación del dominio y el comportamiento del remitente siguen importando.

Fallo 2: congestión de la cola compartida

Cuando crece la cola de Postfix, por ejemplo porque un cliente recibe numerosos errores temporales 4xx, pueden escasear los recursos para otros envíos. Postfix dispone de controles por destino, pero no desaparece por ello la competencia por recursos globales. Con 50 dominios, una campaña de 500K mensajes podría retrasar durante horas el correo transaccional de otros clientes, según la capacidad y los controles de la instalación.

Fallo 3: confusión entre identidades de autenticación

Si la base de autenticación de Dovecot no distingue los dominios de forma coherente, un usuario del cliente A podría resolverse contra registros del cliente B cuando coincidan sus nombres. La validación debe incluir el dominio en toda la cadena. Configurar auth_username_format como %u, dirección completa, en lugar de %n, solo parte local, puede formar parte de la solución. No basta con esa línea: las consultas de autenticación, las normalizaciones, la autorización y el acceso al buzón también deben aplicar esa separación. El inventario de riesgos está en los riesgos del alojamiento de correo multidominio.

Servidor propio frente a servicio alojado

La decisión depende del coste real de tu tiempo. Una instalación propia parece barata al contar únicamente VPS y ancho de banda; cambia la comparación al sumar ajustes de Postfix, solicitudes de retirada de listas de bloqueo, rotaciones DKIM e incidentes de entrega a las 3 de la madrugada. La tabla ofrece escenarios orientativos, no presupuestos ni umbrales universales.

En estos ejemplos, contratar puede resultar favorable por debajo de 5,000 dominios, pero hay que comprobar capacidad, condiciones y horas efectivamente ahorradas. Las obligaciones de cumplimiento pueden cambiar la elección, por ejemplo si los datos deben residir físicamente en una jurisdicción que el proveedor no cubre. Una solución híbrida permite mantener un cliente excepcional en infraestructura propia sin asumir necesariamente toda la pila.

Qué puedes obtener de un servicio alojado multicliente

Conviene evaluar cuatro capacidades: gestión y registro de rotaciones DKIM por dominio; asistentes SPF/DMARC, con publicación mediante integraciones DNS cuando estén disponibles y autorizadas; supervisión de pools IP y reputación de dominios; y análisis de informes DMARC agregados. No todos los proveedores ofrecen todo ni con el mismo alcance. Comprueba las funciones actuales de TrekMail Agency, conserva acceso al DNS y valida los registros publicados. Contratar puede evitar desarrollar estas herramientas, pero no elimina la responsabilidad de revisar emisores y políticas.

Comparativa de servicios multidominio alojados

TrekMail, Migadu y Workspace son opciones que pueden entrar en una evaluación multidominio, aunque no agotan el mercado. Sus modelos y capacidades difieren. La tabla conserva el escenario ilustrativo del artículo: 50 dominios de clientes con ~10 buzones cada uno, 500 buzones en total. Los precios, modalidades de facturación y controles deben comprobarse antes de utilizarla para una compra.

Los supuestos de la tabla arrojan diferencias de aproximadamente 13× frente al cálculo atribuido a Migadu y 240× frente al de Workspace. Son resultados aritméticos de esos supuestos, no una comparativa verificada de ofertas actuales, especialmente en el caso del modelo de Migadu. Una tarifa fija y otra por unidad pueden divergir mucho al crecer. También hay que evaluar capacidad, administración y exposición a la reputación compartida; ninguna de estas ofertas implica por defecto una IP dedicada por dominio. Cuando procedan, esas IP requieren gestión y no garantizan la entrega. Agrupar dominios independientes en una organización de Workspace tampoco asegura límites administrativos o de datos equivalentes: verifica dominios y requisitos de separación de cada cliente.

Cuándo puede compensar un servidor multidominio propio

Los ejemplos anteriores favorecen a menudo el servicio alojado, pero hay tres situaciones donde una instalación propia puede justificar su coste operativo. Entender las excepciones ayuda a decidir con criterio, en lugar de aplicar una recomendación general a todos los clientes.

Primer caso: requisitos normativos que las ofertas evaluadas no cumplen. Si un cliente exige una ubicación física que TrekMail, Migadu y las suites en la nube consideradas no ofrecen, puede ser necesaria una instalación propia u otro proveedor que sí la cubra. Muchas agencias optan por un modelo híbrido: infraestructura específica para ese cliente y servicio alojado para los demás. No hace falta trasladar toda la pila por un único caso.

Segundo caso: necesidades justificadas de IP dedicadas o gestión de reputación que las ofertas disponibles no cubren. Algunos servicios transaccionales o emisores de boletines de gran volumen pueden beneficiarse de separar IP. Muchos planes multicliente utilizan pools compartidos. Un VPS con IP y políticas de calentamiento adecuadas puede encajar, siempre con autorización, control del abuso y seguimiento. No todos los clientes que solicitan una IP dedicada la necesitan realmente.

Tercer caso: capacidad técnica interna ya disponible por otros motivos. Si tienes un especialista en correo que trabaja en otras necesidades de la empresa, ampliar sus tareas puede tener un coste marginal menor. Aun así, su tiempo tiene coste de oportunidad y capacidad limitada; que su salario ya esté presupuestado no convierte la operación adicional en gratuita.

Refuerzo de seguridad de un servidor multidominio

Un servidor multidominio es un objetivo valioso: un compromiso con privilegios suficientes puede afectar al flujo de correo de varios clientes. La siguiente lista recoge controles prácticos. Su eficacia depende de cómo se implementen, supervisen y prueben junto con el resto de la arquitectura.

La presentación de mensajes por clientes debe utilizar el puerto 587 con STARTTLS o el puerto 465 con TLS implícito, y exigir autenticación protegida por TLS válido, sin credenciales en claro ni presentación anónima. El puerto 25 debe seguir aceptando correo legítimo entrante entre servidores, normalmente sin autenticación de usuario. No rechaces indiscriminadamente mensajes entre direcciones locales: bloquea el relay no autorizado y evita que ese puerto sirva para eludir las políticas de presentación autenticada. Revisa específicamente que el puerto 25 no actúe como vía alternativa para saltarse esos controles.

Los límites de salida por cliente pueden reducir el daño de un buzón comprometido, no asegurar que una IP quede a salvo en 20 minutos. Conviene combinar límites por buzón y hora y por cuenta y día con alertas y respuesta rápida. Sin controles, una contraseña robada podría permitir una ráfaga de 100K mensajes de spam, según los recursos. El artículo cita límites de TrekMail como 1,000 mensajes por buzón y día y 6,000 por cuenta y día en Starter, o 50 mensajes de presentación SMTP por hora en Nano. Verifica sus valores y alcance actuales; son una referencia para diseñar controles, no una garantía contra el abuso.

Exige contraseñas robustas y 2FA para el acceso administrativo. La 2FA de los buzones también importa, especialmente cuando sirven para recuperar otras cuentas. En IMAP convencional pueden necesitarse contraseñas de aplicación u otros mecanismos compatibles, en lugar de un desafío interactivo. La 2FA administrativa merece especial atención porque ese acceso tiene un alcance amplio sobre la separación de clientes.

Lista operativa para un servidor multidominio

Si eliges una instalación propia, las tareas diarias y semanales son tan importantes como la configuración inicial. Postfix y Dovecot pueden funcionar durante años con mantenimiento adecuado, pero la continuidad y la entrega dependen de la disciplina operativa. La lista siguiente sirve como punto de partida, no sustituye las necesidades de tu instalación.

A diario: supervisa la profundidad de la cola y el volumen saliente por cliente. Un aumento repentino de 10× respecto a lo habitual puede ser una campaña prevista o un compromiso; ambos merecen revisión. Comprueba las listas de bloqueo de tus IP con MX Toolbox o herramientas equivalentes. Revisa los trabajos cron nocturnos: rotación de registros, recepción de informes DMARC y copias de seguridad.

Semanalmente: revisa los informes DMARC disponibles para cada dominio. Los clientes incorporan plataformas de boletines, proveedores de pagos o herramientas comerciales que pueden añadir emisores nuevos. Comprueba su autorización SPF, su firma DKIM y la alineación aplicable. Supervisa el crecimiento del almacenamiento; un buzón que supere 30 GB puede requerir archivo o una revisión de capacidad, según el plan. Revisa las conexiones IMAP de Dovecot por cliente: acercarse a un límite puede causar fallos intermitentes de sincronización y consultas al soporte.

Trimestralmente: si has adoptado esa política, rota las claves DKIM por dominio. El ejemplo consiste en publicar el selector nuevo, esperar 48 horas, cambiar la firma de Postfix y mantener el selector anterior otras 48 horas. Esas ventanas no garantizan nada por sí solas: comprueba TTL, cachés, publicación y mensajes firmados todavía en tránsito antes de retirar claves. Con 100 dominios, el artículo estima 8-12 horas por trimestre, unas 40 horas al año. Son cifras orientativas; la automatización de planes como TrekMail Agency debe verificarse y supervisarse.

Anualmente: revisa la gestión de certificados SSL/TLS de SMTP e IMAP, utilizando TLS vigente y sin esperar a esa revisión para renovarlos. El artículo usa como ejemplo certificados Let's Encrypt de 90 días con renovación automática; vigencia y automatización deben comprobarse y vigilarse continuamente. Valida las copias restaurando el correo de un cliente en una instancia limpia de Dovecot y audita los backends de autenticación. Busca registros obsoletos, incluidos usuarios de dominios retirados de Postfix que todavía puedan autenticarse.

Próximos pasos

Un servidor multidominio combina una pila técnica madura con una operación que puede exigir bastante tiempo. La gestión DKIM por dominio y el análisis DMARC pueden ocupar semanas al año, según la escala y la automatización. Un servicio alojado suele merecer evaluación cuando evita ese trabajo, pero la elección debe apoyarse en costes, requisitos y capacidad reales.

El escenario del artículo presenta TrekMail Agency a $29 al mes, $23.25/mes con facturación anual, para 1,000 dominios × 1,000 buzones por dominio y 200 GB compartidos entre correo y TrekMail Drive. También describe rotación DKIM por dominio, editor Sieve, soporte dedicado, 100 alias por buzón e importación masiva de 50 dominios mediante CSV. La prueba de 14 días requiere tarjeta en ese escenario; Nano se describe como gratuito, sin tarjeta ni prueba temporal, para 10 dominios × 10 buzones. Comprueba precios, funciones, requisitos y cuotas vigentes, así como el efecto real de cualquier complemento Drive sobre el almacenamiento de correo. Para profundizar en los riesgos, consulta nuestra guía de alojamiento multidominio. La comparación de planes y los precios actuales están en trekmail.net/pricing.