Tutoriais de VPS
Instalar o Mailcow em uma VPS (2026): Docker, DNS, antispam, backups e entregabilidade
Instale o servidor de e-mail auto-hospedado Mailcow em uma VPS, com configuração completa de Docker, PTR, SPF, DKIM, DMARC, TLS, antispam, backups externos, atualizações e diagnóstico de entregabilidade.
Se você quer enviar e receber e-mails com seu próprio domínio sem instalar separadamente Postfix, Dovecot, Rspamd, webmail e serviços de certificado, o Mailcow é uma das suítes de e-mail auto-hospedadas mais completas disponíveis. Ele reúne SMTP, IMAP, webmail SOGo, antispam, verificação de vírus, DKIM e um painel de administração em um único projeto Docker Compose.
Mas um servidor de e-mail não é algo que "funciona assim que os contêineres sobem". A porta 25 da VPS, um IP público dedicado, o PTR de resolução reversa e a reputação histórica do IP costumam importar mais do que o desempenho da CPU. Se você escolher a máquina errada, os e-mails enviados para Gmail, Outlook ou caixas corporativas ainda podem ser rejeitados ou cair em spam mesmo com o painel de administração todo verde.
Este tutorial começa com as verificações a fazer antes de comprar uma VPS, usa o repositório oficial do Mailcow mailcow-dockerized para concluir a instalação, configura A, MX, PTR, SPF, DKIM, DMARC, TLS, antispam, backups e atualizações, e traz uma lista de verificação de entregabilidade e solução de problemas comuns.
O Mailcow é uma suíte completa de e-mail e colaboração, não um encaminhador SMTP leve.
| Necessidade | O Mailcow é adequado | Motivo |
|---|---|---|
| Uma equipe pequena usando caixas, calendários e contatos no próprio domínio | Adequado | Inclui SOGo, IMAP, SMTP, recursos relacionados ao ActiveSync e um painel de administração unificado |
| Necessidade de controlar os dados das caixas, o arquivamento e o ciclo de vida das contas | Adequado | Os dados ficam na sua própria VPS e nos volumes do Docker |
| Um site que só precisa enviar códigos de verificação e e-mails de notificação | Normalmente não adequado | Um serviço de e-mail transacional dedicado exige menos manutenção e constrói reputação de envio com mais facilidade |
| E-mail marketing em massa, e-mail frio | Não adequado | Danifica facilmente a reputação do IP e do domínio, e pode violar os termos de serviço da VPS |
| Uma VPS em que você não consegue obter um PTR nem abrir a porta 25 | Não adequado | Servidores de e-mail externos podem rejeitar diretamente ou reduzir sua reputação |
Se você só precisa enviar notificações para Ghost, WordPress ou um sistema de negócio e não precisa de caixas para funcionários, prefira serviços de e-mail transacional como Amazon SES, Postmark ou Mailgun. O Mailcow é mais indicado para equipes que realmente precisam de caixas completas, webmail, calendários e gerenciamento de domínio.
Primeiro leia a Política de Uso Aceitável do provedor e confirme com o suporte que servidores de e-mail auto-hospedados são permitidos. Algumas VPS baratas proíbem serviços de e-mail ou bloqueiam permanentemente o TCP 25 de saída por padrão.
"Você pode abrir a 25 no grupo de segurança" não significa que a rede upstream permita tráfego de saída. Pergunte explicitamente antes de comprar:
- Se o TCP 25 de entrada está aberto;
- Se o TCP 25 de saída está aberto e se exige uma solicitação de desbloqueio;
- Se portas como 465, 587, 993, 80 e 443 têm restrições;
- Se há períodos de espera ou requisitos de KYC para contas novas.
Se o provedor só consegue abrir a 587, isso ainda não substitui a porta 25 necessária para a entrega entre servidores.
O PTR do IPv4 público deve ser configurado pelo provedor de VPS/IP com o hostname do Mailcow, por exemplo:
203.0.113.10 -> mail.example.com
Ao mesmo tempo, o registro A de mail.example.com deve resolver para o mesmo IP. Uma divergência entre direto e reverso é uma causa comum de e-mails caírem em spam ou serem rejeitados.
Depois de obter o IP, verifique primeiro as listas negras em tempo real comuns e os registros históricos de abuso. Se o IP já tem uma reputação grave de spam, a opção que economiza mais tempo costuma ser pedir ao provedor que troque o IP, em vez de tentar "limpar" aos poucos com um domínio novo.
Para continuar o diagnóstico de rejeições, chegada à pasta de spam e resultados de autenticação, use isto junto com o guia de diagnóstico de entregabilidade de e-mail auto-hospedado em VPS.
O mínimo oficial do Mailcow para a configuração padrão é 6GiB de memória mais 1GiB de Swap, com pelo menos 20GiB de disco sem incluir os dados de e-mail; a recomendação oficial é 8GiB de memória para cerca de 5 a 10 usuários. O ClamAV e a busca de texto completo consomem bastante memória.
| Caso de uso | Configuração de VPS recomendada | Observações |
|---|---|---|
| Pessoal ou até 3 caixas | 4 núcleos, 8GB, 80GB SSD | Mantenha o ClamAV e a busca de texto completo, e reserve espaço para o sistema e os backups |
| 5-10 usuários | 4 núcleos, 8-16GB, 160GB SSD | Amplie conforme anexos, período de retenção e conexões móveis |
| Cerca de 50 IMAP simultâneos, vários dispositivos ActiveSync | 8 núcleos, 16GB ou mais | O exemplo oficial recomenda 16GiB; faça uma avaliação de capacidade antes de implantar |
| Menos de 6GB de memória | Configuração padrão não recomendada | Mesmo com ClamAV/FTS desativados, reduz recursos e margem de segurança |
Não olhe apenas o número de caixas. Conexões móveis de longa duração, indexação de texto completo, anexos grandes, treinamento antispam e backups também afetam os recursos. Se você ainda não definiu as especificações da máquina, consulte primeiro o guia de escolha de configuração de VPS.
A virtualização deve ser completa, como KVM, ESX ou Hyper-V. O Mailcow não oferece suporte oficial a VPS baseadas em contêineres OpenVZ, Virtuozzo ou LXC. O sistema usado como exemplo é Ubuntu 24.04 LTS, x86_64.
Este artigo usa o seguinte exemplo:
邮件域名：example.com
Mailcow 主机名：mail.example.com
服务器 IPv4：203.0.113.10
O hostname deve ser um nome de domínio totalmente qualificado, não apenas mail, e você não deve usar diretamente o domínio raiz example.com. Se o DNS estiver hospedado na Cloudflare, mail.example.com deve ser definido como DNS only e não deve ter o proxy de nuvem laranja ativado, porque o proxy comum da Cloudflare não encaminha portas de e-mail como SMTP e IMAP.
Defina o hostname e o fuso horário do servidor antes da instalação:
sudo hostnamectl set-hostname mail.example.com
sudo timedatectl set-timezone Asia/Shanghai
hostname -f
timedatectl status
Um horário incorreto afeta TLS, a correlação de logs e a autenticação de dois fatores TOTP, então não pode ser ignorado.
O Mailcow usa estas portas TCP por padrão:
| Porta | Uso |
|---|---|
| 25 | Entrega SMTP entre servidores de e-mail |
| 465 / 587 | Envio criptografado a partir de clientes de e-mail |
| 143 / 993 | IMAP / IMAPS |
| 110 / 995 | POP3 / POP3S |
| 4190 | Regras de filtro ManageSieve |
| 80 / 443 | Painel de administração, webmail, validação de certificados |
Antes de instalar, verifique se Nginx, Apache, Postfix ou outros serviços já ocupam as portas:
sudo ss -tlpn | grep -E -w '25|80|110|143|443|465|587|993|995|4190'
O ideal é que a saída esteja vazia. O Mailcow já inclui seu próprio Nginx e componentes de certificado, então para uma primeira instalação não é recomendado colocar Caddy ou Nginx Proxy Manager por cima. Se um site existente ocupa a 80/443, ajuste as portas vinculadas conforme a documentação oficial de proxy reverso do Mailcow, em vez de editar o arquivo Compose sem cuidado.
O Mailcow atualmente exige Docker Engine 24.0 ou superior e Docker Compose 2.0 ou superior. Instale a partir do repositório oficial do Docker, não de pacotes da distribuição desatualizados há anos.
Instale as ferramentas de que o Mailcow precisa:
sudo apt update
sudo apt install -y git openssl curl gawk coreutils grep jq
docker --version
docker compose version
Para logs do Docker, espaço em disco e princípios de reversão em produção, consulte a lista de verificação de configuração de produção do Docker Compose em VPS. Não edite diretamente o docker-compose.yml, que o Mailcow mantém automaticamente; use o método de configuração oficialmente suportado para personalizações.
Clone o repositório oficial e gere a configuração:
sudo -i
umask 0022
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
Quando o script perguntar o hostname, informe:
mail.example.com
Depois verifique os itens principais do /opt/mailcow-dockerized/mailcow.conf:
MAILCOW_HOSTNAME=mail.example.com
TZ=Asia/Shanghai
SKIP_LETS_ENCRYPT=n
SKIP_CLAMD=n
SKIP_FTS=n
ENABLE_IPV6=false
Defina ENABLE_IPV6 como true apenas se a VPS tiver IPv6 público, AAAA e PTR de IPv6 configurados corretamente. Forçar isso sem um caminho de e-mail IPv6 completo pode fazer com que algumas entregas saiam de um IPv6 que nunca construiu reputação.
O generate_config.sh gera configurações aleatórias, como senhas de banco de dados; não envie o mailcow.conf para um repositório Git público.
Inicie os serviços:
docker compose pull
docker compose up -d
docker compose ps
O Mailcow inclui vários contêineres, e o primeiro download e a inicialização levam alguns minutos. Não verifique apenas se um contêiner está Up; verifique todos os serviços principais:
docker compose ps
docker compose logs --tail=100 nginx-mailcow
docker compose logs --tail=100 postfix-mailcow
docker compose logs --tail=100 dovecot-mailcow
docker compose logs --tail=100 acme-mailcow
Primeiro crie os registros que permitem ao servidor ficar online e receber e-mails. Os nomes dos campos variam um pouco entre consoles de DNS:
mail A 203.0.113.10
@ MX 10 mail.example.com.
autodiscover CNAME mail.example.com.
autoconfig CNAME mail.example.com.
@ TXT "v=spf1 mx a -all"
_dmarc TXT "v=DMARC1; p=none; rua=mailto:[email protected]"
Também configure o seguinte no console do provedor da VPS:
PTR 203.0.113.10 -> mail.example.com
Comece com p=none para coletar relatórios DMARC e, após confirmar que todas as fontes legítimas passam no alinhamento SPF ou DKIM, mude gradualmente para quarantine ou reject. Se o domínio também envia e-mails por serviços de terceiros, não copie o v=spf1 mx a -all literalmente; você deve mesclar todas as fontes de envio legítimas em um único registro SPF.
Após a propagação do DNS, verifique:
dig +short A mail.example.com
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10
A e PTR devem corresponder entre si, e o destino MX deve ser um hostname, não um IP.
Abra no navegador:
https://mail.example.com/admin
A conta inicial oficial é admin e a senha padrão é moohoo. Imediatamente após o primeiro login:
- Altere a senha do administrador;
- Ative a autenticação de dois fatores;
- Crie um segundo administrador controlado como via de recuperação;
- Confirme que o certificado TLS foi emitido e que o navegador não mostra avisos;
- Não permita que contas de caixa comuns tenham privilégios de administração desnecessários.
Se o painel de administração já está acessível pela internet mas você ainda não alterou a senha padrão, restrinja o acesso antes de continuar a configuração.
No painel de administração do Mailcow, conclua o seguinte na ordem:
- Configuration → Mail Setup → Domains, adicione
example.com; - Crie as caixas necessárias, como
[email protected]e[email protected]; - Gere uma DKIM Key para o domínio;
- Copie o valor TXT completo do DKIM exibido no painel para o DNS;
- Após a propagação, execute novamente a verificação de DNS no painel.
O registro DKIM geralmente é parecido com:
dkim._domainkey TXT "v=DKIM1; k=rsa; p=这里使用后台生成的公钥"
Não invente manualmente a chave pública após p= nem coloque a chave privada no DNS. Se o registro for muito longo, o provedor de DNS pode dividi-lo automaticamente em várias strings; desde que a consulta TXT final consiga remontar o valor completo, está correto.
As portas publicadas pelo Docker passam pela cadeia de encaminhamento. O Mailcow alerta oficialmente que escrever apenas regras UFW/INPUT pode não restringir as portas dos contêineres; as restrições precisam ser colocadas em DOCKER-USER ou em um firewall de nuvem externo.
Um servidor de e-mail deve permitir pelo menos as portas públicas realmente necessárias. Se o painel de administração for apenas para uso da equipe, você pode restringir os IPs de origem no firewall upstream; a SMTP 25 e as portas de protocolo de e-mail usadas pelos destinatários não devem ser bloqueadas por engano.
Após aplicar as regras, teste de verdade a partir de outra máquina em vez de verificar apenas localmente:
nc -vz mail.example.com 25
nc -vz mail.example.com 443
nc -vz mail.example.com 587
nc -vz mail.example.com 993
openssl s_client -starttls smtp -connect mail.example.com:25 \
-servername mail.example.com </dev/null
Firewalls de nuvem, regras do host e cadeias do Docker devem ser verificados juntos. Não limpe em massa as regras do iptables em uma sessão SSH remota.
Antes de migrar formalmente as caixas do domínio, conclua pelo menos quatro rodadas de testes:
Envie um e-mail do Gmail, Outlook ou outra caixa externa para [email protected] e confirme que ele chega ao SOGo e ao cliente IMAP.
Envie separadamente para Gmail, Outlook e outra caixa corporativa, e verifique se o e-mail chega à caixa de entrada. Não envie apenas entre caixas do mesmo domínio, pois isso não passa pelo caminho real de entrega na internet.
No lado do destinatário, veja os cabeçalhos da mensagem original e confirme:
spf=pass
dkim=pass
dmarc=pass
Os três passarem ainda não garante a chegada à caixa de entrada; a reputação do IP, o conteúdo, o ritmo de envio e o feedback dos usuários também influenciam o resultado.
cd /opt/mailcow-dockerized
docker compose logs --since=30m postfix-mailcow
docker compose logs --since=30m rspamd-mailcow
docker compose exec postfix-mailcow postqueue -p
Ao encontrar timeout, connection refused, blocked using ou 550 5.7.x, guarde a resposta completa do par antes de agir, e não reenvie repetidamente criando mais sinais negativos.
O Mailcow oferece oficialmente o helper-scripts/backup_and_restore.sh, que pode fazer backup de e-mails, bancos de dados, material de criptografia, Redis, Rspamd e dados do Postfix. Não copie o script para outro lugar; execute-o diretamente no repositório:
sudo mkdir -p /opt/mailcow-backups
cd /opt/mailcow-dockerized
MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
./helper-scripts/backup_and_restore.sh backup all --delete-days 7
Após verificar o diretório de backup gerado e os logs, configure o Cron:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
30 3 * * * cd /opt/mailcow-dockerized && MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups ./helper-scripts/backup_and_restore.sh backup all --delete-days 7 >> /var/log/mailcow-backup.log 2>&1
O /opt/mailcow-backups ainda fica na mesma VPS, então só protege contra exclusão acidental, não contra falha de disco ou suspensão da conta. Sincronize os backups criptografados com outro armazenamento de objetos ou servidor externo, e restaure periodicamente usando uma máquina de teste em branco. Você pode reutilizar os métodos de verificação, retenção e aceitação de restauração do guia de simulação de backup e restauração em VPS.
Os critérios de uma restauração bem-sucedida incluem: o administrador consegue fazer login, os e-mails históricos e anexos estão completos, a configuração de domínio e DKIM existe, e o envio e recebimento funcionam — não que o código de saída do script seja 0.
O Mailcow é composto por vários serviços de rede, e as atualizações de segurança não podem ser adiadas por muito tempo. O repositório oficial oferece o update.sh; não faça atualizações não planejadas de cada imagem por conta própria.
Processo de atualização:
cd /opt/mailcow-dockerized
./update.sh --check
# 先执行完整备份并确认异地副本可读
./update.sh
docker compose ps
docker compose logs --tail=100 nginx-mailcow
docker compose logs --tail=100 postfix-mailcow
docker compose logs --tail=100 dovecot-mailcow
Após atualizar, verifique o painel de administração, o SOGo, o login IMAP, o envio SMTP, o envio e recebimento externos, a fila, o TLS e o DKIM. Mantenha o branch stable em produção e não mude diretamente para o nightly.
dig +short MX example.com
nc -vz mail.example.com 25
docker compose logs --tail=200 postfix-mailcow
Primeiro confirme que o MX aponta para o hostname correto, que o registro A aponta para o IP atual e que a 25 de entrada está aberta. A nuvem laranja da Cloudflare, MX antigos e bloqueios da operadora podem causar timeouts.
nc -vz gmail-smtp-in.l.google.com 25
docker compose exec postfix-mailcow postqueue -p
docker compose logs --tail=300 postfix-mailcow
Se todas as conexões externas na porta 25 derem timeout, entre em contato primeiro com o provedor da VPS para confirmar o bloqueio de saída. Não confunda a porta 587 de envio do cliente com a porta 25 de entrega do servidor.
Verifique o direto e reverso de A/PTR, SPF, DKIM, DMARC, as listas negras de IP e os cabeçalhos originais da mensagem. Não comece a enviar em massa de repente a partir de um IP novo; primeiro construa reputação gradualmente com comunicação de negócio real um a um. Para códigos de erro e diagnóstico de entrega mais completos, consulte o guia de entregabilidade de e-mail linkado anteriormente.
dig +short A mail.example.com
docker compose logs --tail=300 acme-mailcow
sudo ss -lntp | grep -E ':80|:443'
Confirme que o domínio resolve diretamente para a VPS do Mailcow, que a 80/443 está acessível e não está ocupada por outros serviços. Se o IPv6 não estiver configurado corretamente, exclua o AAAA errado e desative o IPv6 no Mailcow.
free -h
docker stats --no-stream
docker compose ps
journalctl -k --since '1 hour ago' | grep -i -E 'oom|killed process'
Com a configuração padrão abaixo de 6GiB de memória, a prioridade é ampliar a VPS. Em uma emergência você pode configurar SKIP_CLAMD=y e SKIP_FTS=y conforme as instruções oficiais, mas isso desativa a verificação de vírus ou a busca de texto completo e não deve ser apresentado como uma otimização sem custo.
Prefira 993 IMAPS e 587 Submission, e confirme que o nome de usuário é o endereço de e-mail completo. Verifique o horário, o certificado, a senha e os logs do Dovecot:
docker compose logs --since=30m dovecot-mailcow
openssl s_client -connect mail.example.com:993 \
-servername mail.example.com </dev/null
- A VPS permite serviços de e-mail, e o TCP 25 de entrada/saída foi testado
- Usa virtualização suportada como KVM, com a configuração padrão de pelo menos 6GiB de memória mais 1GiB de Swap
- O registro A de
mail.example.come o PTR do IP público coincidem em direto e reverso - MX, SPF, DKIM, DMARC, autodiscover e autoconfig foram resolvidos
- Os registros DNS não estão proxificados por um CDN comum
- A senha padrão do administrador foi alterada e a autenticação de dois fatores está ativada
- O certificado TLS é válido, e as portas SMTP, IMAPS e Submission estão acessíveis
- O recebimento externo e o envio para vários serviços foram testados com sucesso
- SPF, DKIM e DMARC passam nos cabeçalhos de mensagens reais
- Os backups completos foram copiados para fora do site e a simulação de restauração em máquina em branco foi concluída
- O processo de atualização, os locais dos logs e os contatos de plantão foram registrados
O Mailcow reduz a barreira para instalar componentes e para a gestão diária, mas não resolve por você a reputação do IP, a propriedade do DNS nem a conformidade de e-mail. Verificar primeiro a porta 25, o PTR e o histórico do IP, e depois implantar e migrar as caixas de produção, costuma economizar mais tempo do que instalar primeiro e depois recorrer em todo lugar.