Servidor de e-mail para vários domínios: arquitetura e custos

Você administra um servidor de e-mail para 30 domínios de clientes. Cada um precisa dos próprios registros MX, da própria chave DKIM, do próprio registro SPF, da própria política DMARC, de regras de quarentena e de acompanhamento da reputação de envio. A questão não é se um servidor consegue atender a todos: Postfix e Dovecot fazem isso há duas décadas. O desafio é saber como a operação reage quando uma campanha de um cliente prejudica a reputação do IP compartilhado.

Um servidor para vários domínios é a arquitetura certa para muitos operadores, mas pode ser uma escolha ruim para quem espera economizar em relação a uma hospedagem gerenciada com múltiplos clientes. Este guia apresenta a arquitetura, os padrões de configuração para separar os ambientes, três falhas de isolamento que aparecem com o crescimento e a comparação de custos entre operação própria e um plano como o TrekMail Agency. Diretórios e mapas separados, por si só, não garantem isolamento de segurança.

O que é um servidor de e-mail para vários domínios

É uma infraestrutura de transporte de e-mail que recebe e envia mensagens para mais de um domínio. Uma instância do Postfix recebe mensagens destinadas a client1.com, client2.com e client3.com; uma instância do Dovecot armazena as caixas dos três com a separação de acesso devidamente configurada; uma fila de saída envia mensagens com assinaturas DKIM específicas de cada domínio.

Isso não é exatamente o mesmo que a expressão comercial “hospedagem de e-mail para vários domínios”, que normalmente descreve um plano com vários domínios na mesma conta de cobrança. O servidor é a realidade técnica por trás dessa oferta: a configuração de Postfix e Dovecot que viabiliza o plano. Ele pode ficar em um VPS administrado por você ou em um provedor como o TrekMail Agency, que assume a operação técnica da infraestrutura compartilhada.

Três padrões de arquitetura para vários domínios

Para operações com 10 ou mais domínios, três padrões de arquitetura merecem consideração. Cada um combina custo, controle e complexidade operacional de forma diferente. A escolha depende tanto da capacidade da equipe técnica quanto das despesas diretas. Planejar esse modelo desde o início pode evitar uma reestruturação cara quando, dois anos depois, a solução anterior deixar de atender à demanda.

Padrão 1: um servidor de e-mail por domínio

A arquitetura mais simples usa uma instância de Postfix/Dovecot para cada domínio de cliente. Não há outros clientes na mesma instância, embora acessos administrativos e componentes compartilhados ainda precisem de proteção. Cada domínio tem seu VPS, seu IP e sua reputação de IP. Pode funcionar bem para 3-5 domínios de empresas independentes. Com 20+ domínios, o trabalho tende a crescer bastante, pois atualizações, monitoramento e renovação de certificados acompanham a quantidade de servidores.

Padrão 2: um servidor compartilhado para vários clientes e domínios

É o modelo tradicional de agência: uma instalação de Postfix + Dovecot atende a todos os domínios, com virtual_mailbox_domains, chaves DKIM por domínio e configuração do Dovecot para separar os clientes. O operador mantém uma infraestrutura e atende a N domínios. Como referência aproximada, a economia pode começar a fazer sentido perto de 10 domínios, enquanto a complexidade operacional pode se tornar expressiva perto de 200. Esses números não são limites universais. Conforme a carga e os requisitos, pode ser melhor contratar hospedagem gerenciada ou dividir a operação entre servidores de diferentes grupos de reputação.

Padrão 3: contratar uma plataforma gerenciada em vez de construir

Muitas agências percebem que administrar esse servidor internamente consome bastante trabalho especializado e pode custar mais que um plano gerenciado equivalente. O exemplo de tarifas usado aqui apresenta o TrekMail Agency por $29 mensais ou o equivalente a $23.25/mo com cobrança anual, para 1,000 domínios e recursos relacionados a DKIM, SPF/DMARC e filas de saída separadas. Confirme o escopo e a disponibilidade atuais: filas por conta não significam isolamento por domínio nem reputação de IP independente. A agência não precisa escrever a configuração do Postfix. Na análise financeira, compare o custo anual total das horas técnicas com o plano, e não apenas uma hora isolada.

Postfix + Dovecot: a combinação tradicional

Na operação própria, Postfix para transporte SMTP e Dovecot para acesso IMAP, armazenamento e entrega LMTP continuam sendo uma combinação comum em 2026. Os trechos abaixo consideram Debian ou Ubuntu LTS. Os princípios podem ser aplicados a outras distribuições, mas os exemplos são incompletos e dependem das versões instaladas: não devem ser copiados para produção sem revisão.

virtual_mailbox_domains e os arquivos de mapeamento

O Postfix atende a vários domínios virtuais com a diretiva virtual_mailbox_domains. Em vez de fixar a lista no main.cf, você pode armazená-la em um mapa hash ou, em instalações maiores, em um backend SQL ou 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

O arquivo /etc/postfix/vhosts relaciona os domínios para os quais o servidor aceita mensagens, com uma chave de domínio e o valor apropriado por linha no formato esperado do mapa hash, não apenas uma lista de nomes de domínio. Nesta configuração com LMTP, /etc/postfix/vmailbox permite verificar a existência dos destinatários virtuais; o valor do mapa não determina o caminho real de armazenamento. Essa entrega é feita pelo Dovecot. O arquivo /etc/postfix/valias trata os aliases, como info@client1.com → real-person@client1.com.

Estrutura de diretórios do Dovecot por domínio

O Dovecot pode armazenar caixas em uma estrutura de diretórios por domínio. Um formato comum é /var/vmail/<domain>/<user>/. Um trecho de configuração correspondente seria:

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

%d representa a parte do domínio e %n, a parte local do endereço. As mensagens de cada usuário ficam no diretório do seu domínio, facilitando backups e tarefas específicas de um cliente, como copiar apenas seu ambiente com rsync. Essa organização não é uma barreira de segurança por si só: autenticação, permissões e caminhos de acesso também precisam estar corretos.

LMTP na passagem de mensagens do Postfix para o Dovecot

Instalações modernas costumam usar LMTP, o Local Mail Transfer Protocol, para passar mensagens do Postfix ao Dovecot. Isso pode reduzir o custo de iniciar um processo dovecot-deliver separado por mensagem e permite aplicar cotas por destinatário quando a configuração oferece esse suporte. Configure o Dovecot para escutar em um socket Unix acessível ao Postfix com as permissões adequadas.

SPF, DKIM e DMARC por domínio em escala

A parte mais difícil costuma ser manter SPF, DKIM e DMARC consistentes para todos os clientes, não o transporte em si. Também é preciso definir uma política de rotação de chaves DKIM que reduza o impacto de uma chave comprometida. A rotação não recupera reputação de envio prejudicada. Esse conjunto de tarefas representa boa parte do trabalho no servidor próprio e pode justificar o custo de uma hospedagem adequada.

SPF por domínio

Os domínios que enviam pelo seu servidor precisam autorizar corretamente as fontes de envio no SPF. Esses registros ficam no DNS de cada domínio, e não no servidor. Ao adicionar um IP de saída, atualize as autorizações afetadas. Se os domínios usam um include central bem mantido, a atualização pode acontecer ali, sem editar separadamente o DNS de todos os clientes. O passo a passo está em nosso guia de configuração de SPF.

DKIM por domínio e rotação trimestral como política possível

O DKIM pode gerar bastante trabalho com muitos domínios em infraestrutura própria. Cada domínio recebe um par de chaves: a privada assina as mensagens e a pública fica no DNS, sob um seletor. Rotacionar trimestralmente é uma política possível, não uma obrigação universal. O processo envolve publicar um novo seletor para cada domínio e considerar os caches de DNS e as mensagens ainda em trânsito antes de retirar as chaves antigas. Para 100 domínios, o exemplo representa 400 alterações de DNS por ano quando tudo é feito manualmente. O guia de configuração de DKIM explica esse fluxo.

Relatórios DMARC em escala

O DMARC por domínio pode gerar muitos relatórios agregados, enviados como arquivos XML, frequentemente todos os dias pelos destinatários que participam desse mecanismo. Nem todo servidor receptor envia relatórios, e a frequência pode variar. Interpretar os arquivos, atribuí-los ao cliente certo e destacar sinais úteis, como falsificação de domínio ou configuração incorreta de um remetente, pode exigir um projeto próprio de engenharia. O guia de configuração de DMARC aborda a análise desses dados.

Três falhas comuns de isolamento

A qualidade do servidor compartilhado depende da separação entre os clientes. Os três problemas abaixo podem surgir com o crescimento e às vezes só são identificados depois de um incidente. Avalie esses riscos antes: investigar falhas durante uma crise de entrega costuma ser muito mais difícil.

Falha 1: perda de reputação do IP de saída compartilhado

Clientes que usam o mesmo IP de saída compartilham sua reputação. Uma campanha de prospecção sem os cuidados necessários com consentimento e qualidade da lista pode gerar reclamações e bloqueios que atingem outros clientes, inclusive por limitação de envio no Gmail. Recursos de envio separados podem reduzir o alcance do problema, mas trocar ou rotacionar IPs não resolve abuso nem deve servir para contornar regras dos destinatários. É necessário tratar as causas e a qualidade do envio. No pior cenário, toda a base que usa o mesmo pool pode ser afetada.

Falha 2: acúmulo de mensagens na fila compartilhada

Quando a fila do Postfix cresce, por exemplo porque um destinatário responde às mensagens de um cliente com erros temporários 4xx, a disputa por recursos pode atrasar o envio dos demais. O Postfix oferece limitação por destino, mas a infraestrutura continua compartilhada. Em uma operação com 50 domínios, uma newsletter de 500K mensagens pode, em condições desfavoráveis, prejudicar por horas os e-mails transacionais de outros clientes. Esse é um cenário de carga possível, não um resultado inevitável de qualquer instalação.

Falha 3: confusão entre clientes na autenticação

Se o banco de autenticação do Dovecot não identifica o domínio de forma inequívoca, um usuário do cliente A pode ser validado contra o registro do cliente B quando a parte local do nome coincide. Todo o fluxo de autenticação e autorização deve levar o domínio em conta. A configuração auth_username_format pode precisar usar %u, o endereço completo, em vez de %n, apenas a parte local. Essa linha sozinha não corrige consultas de banco incorretas, contas ambíguas ou verificações de acesso insuficientes. Veja a análise mais ampla em riscos da hospedagem de e-mail para vários domínios.

Servidor próprio ou hospedagem gerenciada

A decisão depende do custo real do seu tempo. O servidor próprio parece barato quando a conta inclui apenas VPS e banda. A conclusão pode mudar ao incluir ajustes do Postfix, pedidos de retirada de listas de bloqueio, rotação DKIM e incidentes de entrega às 3 da manhã. A tabela ilustra três mudanças de patamar de custo com estimativas, não compromissos de preço ou capacidade atuais.

Nessa simulação, a hospedagem pode ser mais econômica em muitos cenários abaixo de 5,000 domínios. A conclusão depende de limites do plano, carga, custo de trabalho e requisitos reais. Uma exceção são exigências de conformidade não atendidas por um provedor, como armazenamento físico em uma jurisdição onde nenhum serviço adequado opera. Mesmo assim, uma solução híbrida pode bastar: hospedar a maioria dos clientes no provedor e manter infraestrutura própria apenas para o caso especial.

O que uma hospedagem gerenciada pode assumir

Um serviço adequado pode assumir quatro frentes que você teria de construir e operar: rotação DKIM por domínio com rastreabilidade, auxílio para SPF/DMARC, administração e desenvolvimento gradual da reputação dos IPs de saída e análise de relatórios DMARC agregados. Assistentes de DNS não necessariamente publicam registros sozinhos: isso depende de integrações e permissões disponíveis. Acompanhar reputação por domínio também não equivale a fornecer IPs isolados. No servidor próprio, essas funções podem consumir meses de desenvolvimento. Confirme na documentação atual quais delas o TrekMail Agency oferece e em que condições.

Comparação de hospedagens para vários domínios

Entre as opções que uma operação pode avaliar estão TrekMail, Migadu e Google Workspace, com modelos distintos. A comparação histórica abaixo considera 50 domínios de clientes com ~10 caixas cada, totalizando 500 caixas: um perfil possível de agência de médio porte. Antes de contratar, verifique preços, unidades de cobrança e recursos atuais. No Workspace, confira também a verificação dos domínios e os limites entre organizações: domínios de clientes diferentes na mesma organização não recebem automaticamente administração e dados independentes.

Com essas hipóteses específicas, o TrekMail Agency fica aproximadamente 13× mais barato que o modelo atribuído ao Migadu por domínio e 240× mais barato que o modelo por usuário do Workspace. É uma ilustração do efeito da cobrança fixa em comparação com a cobrança por unidade, não uma comprovação de economia universal. A hipótese de cobrança do Migadu por domínio precisa especialmente ser validada. Avalie separadamente o pool de IPs compartilhado e os IPs dedicados: um IP próprio pode separar reputação, mas não melhora a entrega automaticamente e exige qualidade e volume de envio adequados.

Quando o servidor próprio realmente faz sentido

A simulação anterior frequentemente favorece a hospedagem. Ainda assim, há três situações em que manter um servidor próprio pode fazer sentido apesar do trabalho adicional. Entender as exceções é tão importante quanto reconhecer a tendência de custo.

Primeira situação: requisitos regulatórios que nenhum provedor adequado atende. Se os dados de um cliente precisam permanecer fisicamente em uma jurisdição onde TrekMail, Migadu e as plataformas de nuvem consideradas não operam, uma infraestrutura própria ou especialmente contratada pode ser necessária. O custo operacional continua existindo. Uma alternativa para agências é o modelo híbrido: operar o ambiente desse cliente e hospedar os demais no provedor. Um caso especial não exige necessariamente trazer toda a infraestrutura para dentro.

Segunda situação: IPs dedicados por cliente e requisitos de reputação não cobertos pelas ofertas disponíveis. Alguns operadores de newsletters de alto volume ou serviços transacionais precisam de recursos de envio separados. Muitos planos compartilhados usam pools de IPs. Se o perfil realmente exige IPs dedicados e desenvolvimento controlado da reputação, VPS com separação por grupos de reputação pode ser apropriado. Essa necessidade deve ser comprovada; IP dedicado não é vantajoso para todo cliente.

Terceira situação: capacidade técnica interna já disponível. Quando um especialista em e-mail já integra a equipe por outras razões, o trabalho adicional de atender a mais domínios pode ser menor. Mas essas horas não são gratuitas: mesmo já remuneradas, têm custo de oportunidade e deixam de atender a outras prioridades. Isso muda a comparação financeira sem eliminar o esforço de operação.

Reforço de segurança do servidor compartilhado

Um servidor de vários domínios é um alvo valioso: uma invasão ampla pode comprometer o fluxo de mensagens de todos os clientes. A lista abaixo prioriza controles efetivos, em vez de medidas que apenas transmitem uma aparência de segurança.

A submissão autenticada de mensagens deve usar a porta 587 com STARTTLS ou a porta 465 com TLS implícito. Credenciais só devem ser transmitidas em uma conexão TLS corretamente protegida, nunca em texto aberto ou em envio anônimo. A porta 25 continua aberta para receber mensagens de outros servidores. Nela, impeça relay não autorizado e contorno das regras de submissão, sem rejeitar indiscriminadamente mensagens legítimas destinadas a usuários locais. Verifique que a porta 25 não funciona como alternativa desprotegida ao envio autenticado.

Limites de envio por cliente podem reduzir o dano de uma caixa invadida, mas não garantem que a reputação do IP fique intacta por 20 minutos. Defina limites por caixa e hora e por conta e dia de acordo com os padrões legítimos de envio. Sem controle, no cenário ilustrativo uma senha roubada poderia enviar 100K mensagens de spam pelo IP compartilhado antes de uma reação do monitoramento. Os limites TrekMail citados no exemplo, como 1,000 mensagens por caixa por dia e 6,000 por conta por dia no Starter, além de 50 mensagens por hora na submissão SMTP do Nano, ilustram esses controles. Confirme os valores e o escopo atuais.

Acesso administrativo deve usar senhas fortes e, sempre que possível, 2FA. A proteção das caixas com 2FA também é importante e não deve ser tratada como secundária diante da 2FA administrativa: uma única caixa invadida pode expor dados e prejudicar o ambiente compartilhado de envio. Dependendo do sistema, clientes IMAP podem precisar de senhas de aplicativo. A conta administrativa tem poderes especialmente amplos sobre a separação entre clientes e precisa de proteção proporcional.

Lista de tarefas para operar o servidor próprio

Na operação própria, as rotinas diárias e semanais são tão importantes quanto a configuração inicial. Postfix e Dovecot podem funcionar por anos quando recebem manutenção adequada. Monitoramento, atualizações e disciplina operacional fazem a diferença entre um ambiente saudável e uma crise de entrega. Abaixo está um possível calendário de trabalho.

Diariamente: monitore o tamanho da fila e a taxa de saída por cliente. Um cliente que passa a enviar 10× sua média pode estar executando uma campanha ou ter sido comprometido; ambas as situações merecem análise. Acompanhe o status dos IPs de saída em listas de bloqueio com MX Toolbox ou ferramenta equivalente. Confira a execução das tarefas cron noturnas, como rotação de logs, processamento de relatórios DMARC e rotação de backups.

Semanalmente: analise os relatórios DMARC agregados disponíveis de cada domínio. Plataformas de newsletter, novos provedores de pagamento e ferramentas comerciais acrescentam fontes de envio que precisam de autorização adequada por SPF e DKIM. Revise o crescimento de armazenamento por cliente; caixas acima de 30 GB podem exigir uma política de arquivamento ou revisão do plano, conforme as condições reais. Acompanhe os contadores de conexões IMAP do Dovecot: limites esgotados podem interromper sincronizações e gerar chamados.

Trimestralmente: rotacione as chaves DKIM por domínio conforme a política de segurança escolhida. No exemplo, publique o novo seletor no DNS, espere 48 horas, altere a configuração de assinatura e retire o seletor antigo após outras 48 horas de sobreposição. Esses prazos não são uma garantia: considere tempos reais de cache, mensagens atrasadas e assinaturas antigas. Para 100 domínios, a estimativa é de 8-12 horas por trimestre, aproximadamente 40 horas anuais só para essa manutenção manual. Um serviço hospedado pode automatizá-la, desde que o plano realmente ofereça esse recurso.

Anualmente: faça uma verificação completa dos backups, restaurando as mensagens de um cliente em uma instância limpa do Dovecot, e audite os backends de autenticação. A renovação dos certificados SSL/TLS dos serviços SMTP e IMAP precisa de monitoramento contínuo, independentemente dessa revisão anual. Os 90 dias citados para Let's Encrypt são o prazo do exemplo, não uma regra permanente para todo certificado; a automação pode falhar e casos manuais também precisam de acompanhamento. A auditoria deve localizar contas antigas cujos domínios foram removidos do Postfix, mas cujos usuários ainda conseguem autenticar.

Próximos passos

Operar seu próprio servidor para vários domínios é tecnicamente viável, mas pode consumir bastante tempo. Postfix e Dovecot fornecem a base conhecida; rotação DKIM por domínio e análise DMARC representam parte importante da manutenção. A vantagem financeira da hospedagem depende dos requisitos reais da agência e das ofertas atuais.

O exemplo de TrekMail Agency apresentado aqui cita $29 por mês ou $23.25 de equivalente mensal com pagamento anual, limites nominais de 1,000 domínios × 1,000 caixas por domínio, 200 GB compartilhados entre e-mail e TrekMail Drive, rotação DKIM por domínio, editor Sieve para filtros personalizados, suporte específico, 100 aliases por caixa e importação CSV de, por exemplo, 50 domínios de clientes. Essas quantidades nominais não garantem capacidade operacional ilimitada; confirme armazenamento, limites de envio e recursos disponíveis. No modelo descrito, o teste gratuito de 14 dias exige cartão de crédito. O plano gratuito Nano, sem cartão e sem período de teste temporário, contempla 10 domínios × 10 caixas para conhecer o painel. As condições atuais prevalecem. Para avaliar os riscos por domínio, consulte também nosso guia de hospedagem de e-mail para vários domínios. A comparação de planos e os preços atuais estão em trekmail.net/pricing.