Como mover Postfix para novo servidor sem perder configurações

15 min de leitura  ·  Guia técnico

Mover o Postfix para um novo servidor consiste em transferir todas as configurações, filas de email, certificados TLS e integrações SASL de uma máquina para outra sem interromper o fluxo de mensagens. Para migrar o Postfix sem perder configurações, siga estes passos:

1. Faça backup completo dos arquivos de configuração do servidor de origem
2. Instale e prepare o Postfix no servidor de destino com a mesma versão
3. Transfira os arquivos de configuração, certificados TLS e banco de dados SASL
4. Reconstrua os mapas de hash e ajuste permissões no destino
5. Valide a configuração e envie emails de teste antes de alterar o DNS
6. Atualize o registro MX e monitore a fila do servidor antigo até o TTL expirar

Pré-requisitos para migrar o Postfix entre servidores

• Acesso root ou sudo nos dois servidores (origem e destino)
• Postfix instalado no servidor de destino — preferencialmente a mesma versão do servidor de origem (verifique com postconf mail_version)
• Acesso SSH com chave ou senha entre os dois servidores para transferência via rsync ou scp
• Certificados TLS válidos disponíveis (Let's Encrypt ou certificado comercial)
• Controle sobre a zona DNS do domínio para alterar o registro MX
• TTL do registro MX reduzido para 300 segundos com antecedência de pelo menos 24 horas
• Pacotes auxiliares instalados no destino: libsasl2-modules, mailutils e, se aplicável, postfix-mysql ou postfix-ldap
• Firewall do novo servidor com as portas 25, 587 e 465 liberadas

Como fazer backup completo das configurações do Postfix no servidor de origem

Antes de qualquer transferência, consolidar todos os arquivos relevantes em um único pacote compactado reduz o risco de esquecer dependências críticas. O diretório principal do Postfix é /etc/postfix/, mas certificados TLS e configurações SASL ficam em caminhos separados.

No servidor de origem, execute:

mkdir -p /root/postfix-backup
cp -a /etc/postfix/ /root/postfix-backup/postfix-conf
cp -a /etc/aliases /root/postfix-backup/
cp -a /etc/ssl/certs/postfix* /root/postfix-backup/ 2>/dev/null
cp -a /etc/ssl/private/postfix* /root/postfix-backup/ 2>/dev/null
cp -a /etc/letsencrypt/live/ /root/postfix-backup/letsencrypt 2>/dev/null
cp -a /etc/sasl2/ /root/postfix-backup/sasl2 2>/dev/null
tar -czf /root/postfix-backup-$(date +%Y%m%d).tar.gz /root/postfix-backup/
ls -lh /root/postfix-backup-*.tar.gz

-rw-r--r-- 1 root root 48K Jan 15 10:23 /root/postfix-backup-20250115.tar.gz

Registre também as configurações ativas em memória, que podem diferir dos arquivos em disco:

postconf -n > /root/postfix-backup/postconf-n.txt
postconf -M > /root/postfix-backup/postconf-M.txt

O arquivo postconf-n.txt lista apenas os parâmetros que diferem dos padrões — útil para comparar após a migração. Se você usa o Virtualmin como painel de gerenciamento, exporte também as configurações de domínio virtual pelo painel antes de prosseguir.

Transferindo os arquivos de configuração para o novo servidor

A transferência segura dos arquivos de configuração do Postfix é a etapa central da migração. Use rsync com SSH para preservar permissões e links simbólicos, especialmente importantes para os certificados TLS.

Atenção: o comando abaixo sobrescreve arquivos existentes no destino. Faça um backup do estado atual do servidor de destino antes de executar.

rsync -avz --progress /root/postfix-backup-20250115.tar.gz root@IP_NOVO_SERVIDOR:/root/

No servidor de destino, extraia e aplique os arquivos:

cd /root
tar -xzf postfix-backup-20250115.tar.gz
cp -a postfix-backup/postfix-conf/* /etc/postfix/
cp -a postfix-backup/aliases /etc/aliases

Para os certificados TLS, o caminho depende da origem. Se usar Let's Encrypt:

rsync -avz --progress root@IP_SERVIDOR_ANTIGO:/etc/letsencrypt/ /etc/letsencrypt/

Se os certificados forem autoassinados ou comerciais, copie os arquivos .crt e .key para os mesmos caminhos referenciados em main.cf (verifique com grep tls /etc/postfix/main.cf).

Transfira também os mapas de transporte e virtual:

rsync -avz root@IP_SERVIDOR_ANTIGO:/etc/postfix/virtual /etc/postfix/virtual
rsync -avz root@IP_SERVIDOR_ANTIGO:/etc/postfix/transport /etc/postfix/transport
rsync -avz root@IP_SERVIDOR_ANTIGO:/etc/postfix/sasl_passwd /etc/postfix/sasl_passwd 2>/dev/null

Reconstruindo mapas de hash e ajustando permissões no destino

Após copiar os arquivos de texto, os bancos de dados binários (.db) precisam ser regenerados no servidor de destino. Nunca copie arquivos .db diretamente — eles são dependentes da arquitetura e da versão do Berkeley DB instalada.

postmap /etc/postfix/virtual
postmap /etc/postfix/transport
postmap /etc/postfix/sasl_passwd 2>/dev/null
newaliases

postmap: warning: /etc/postfix/sasl_passwd: No such file or directory

O aviso acima é normal se você não usa autenticação SASL de relay. Se usar, confirme que o arquivo foi copiado corretamente antes de executar postmap.

Ajuste as permissões dos arquivos sensíveis:

chmod 600 /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd.db
chown root:root /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db
chmod 640 /etc/postfix/virtual /etc/postfix/transport

Verifique se o pacote libsasl2-modules está instalado no destino (necessário para autenticação SMTP):

dpkg -l | grep libsasl2-modules

ii  libsasl2-modules:amd64  2.1.28+dfsg-10  amd64  Cyrus SASL - pluggable authentication modules

Se o pacote não estiver listado, instale-o:

apt install libsasl2-modules -y

Validando a configuração do Postfix antes de alterar o DNS

Antes de redirecionar o tráfego de email para o novo servidor, execute uma bateria de verificações para garantir que a configuração está íntegra. Esta etapa evita que emails legítimos sejam rejeitados ou perdidos após a mudança do registro MX.

postfix check

postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out

Avisos sobre makedefs.out são inofensivos. Erros reais aparecem com o prefixo fatal: ou error: e precisam ser corrigidos antes de continuar.

Inicie o Postfix no novo servidor e verifique o status:

systemctl start postfix
systemctl enable postfix
systemctl status postfix

● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/lib/systemd/system/postfix.service; enabled)
     Active: active (running) since Wed 2025-01-15 10:45:12 UTC; 3s ago

Envie um email de teste diretamente pelo servidor de destino:

echo 'Teste de migração Postfix' | mail -s 'Teste migração' [email protected]

Monitore o log em tempo real para confirmar a entrega:

tail -f /var/log/mail.log

Jan 15 10:46:01 novoservidor postfix/smtp[12345]: 3A2B4C5D6E: to=, relay=mail.provedor.com[1.2.3.4]:25, status=sent (250 2.0.0 OK)

Verifique também se as portas estão acessíveis externamente. Se o servidor usa UFW:

ufw allow 25/tcp
ufw allow 587/tcp
ufw allow 465/tcp
ufw status

Confirme a abertura das portas com telnet ou nc a partir de uma máquina externa:

nc -zv IP_NOVO_SERVIDOR 25
nc -zv IP_NOVO_SERVIDOR 587

Connection to IP_NOVO_SERVIDOR 25 port [tcp/smtp] succeeded!

Para garantir que o DNS do domínio está configurado corretamente para o novo servidor, consulte o artigo Como Configurar DNS Personalizado para Seu Domínio na AviraHost antes de alterar o registro MX.

Alterando o registro MX e gerenciando a transição

Com o novo servidor validado, o próximo passo é redirecionar o fluxo de emails alterando o registro MX na zona DNS do domínio. Mantenha o servidor antigo ativo durante todo o período de propagação do DNS.

No painel DNS do seu provedor, atualize o registro MX para apontar para o hostname do novo servidor:

; Antes da migração
@   IN  MX  10  mail.seudominio.com.br.  ; IP antigo

; Após a migração
@   IN  MX  10  mail-novo.seudominio.com.br.  ; IP novo

Adicione também o registro A correspondente:

mail-novo  IN  A  IP_NOVO_SERVIDOR

Verifique a propagação do MX com:

dig MX seudominio.com.br +short

10 mail-novo.seudominio.com.br.

Durante a propagação (que pode levar até o TTL configurado), emails podem chegar tanto no servidor antigo quanto no novo. No servidor antigo, monitore a fila:

mailq

-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
3A2B4C5D6E     1234 Wed Jan 15 10:50:01  [email protected]
                                         [email protected]

-- 1 Kbytes in 1 Request.

Para forçar a reentrega imediata dos emails na fila do servidor antigo após o MX propagar:

postqueue -f

Atenção: só execute postqueue -f no servidor antigo após confirmar que o novo servidor está recebendo emails corretamente. Caso contrário, os emails serão reenviados para o servidor antigo novamente.

Problemas comuns e como resolver

Sintoma: Postfix retorna "fatal: open /etc/postfix/main.cf: Permission denied"

Causa: as permissões do arquivo main.cf foram alteradas durante a cópia, impedindo que o processo do Postfix (que roda como usuário postfix) leia o arquivo.
Solução: restaure as permissões corretas com chmod 644 /etc/postfix/main.cf e chown root:root /etc/postfix/main.cf. Execute postfix check novamente para confirmar.

Sintoma: Emails rejeitados com "Relay access denied" após a migração

Causa: o parâmetro mynetworks ou mydestination no main.cf do novo servidor não inclui os IPs ou domínios corretos. Isso ocorre quando o IP do novo servidor difere do antigo e o arquivo foi copiado sem ajuste.
Solução: edite /etc/postfix/main.cf e atualize mynetworks com o IP do novo servidor e myhostname com o hostname correto. Execute postfix reload após salvar.

Sintoma: TLS falha com "certificate verify failed" após migração

Causa: os caminhos dos certificados TLS em main.cf apontam para arquivos que não existem no novo servidor, ou os certificados foram copiados com permissões incorretas.
Solução: verifique os parâmetros smtpd_tls_cert_file e smtpd_tls_key_file com postconf smtpd_tls_cert_file. Confirme que os arquivos existem nos caminhos indicados e que têm permissão 640 com dono root:postfix. Se usar Let's Encrypt, execute certbot renew --force-renewal no novo servidor para gerar novos certificados vinculados ao hostname correto.

Sintoma: Autenticação SASL falha — clientes de email não conseguem enviar

Causa: o arquivo sasl_passwd.db foi copiado diretamente do servidor antigo sem ser regenerado, ou o pacote libsasl2-modules não está instalado no destino.
Solução: confirme que libsasl2-modules está instalado (dpkg -l | grep libsasl2), depois execute postmap /etc/postfix/sasl_passwd para regenerar o .db. Verifique também se smtpd_sasl_auth_enable = yes está presente no main.cf e reinicie o Postfix com systemctl restart postfix.

Sintoma: Emails chegam no servidor antigo mesmo após alterar o MX

Causa: o TTL do registro MX ainda não expirou em todos os resolvers DNS, ou servidores de email remotos estão usando cache antigo.
Solução: aguarde o TTL configurado (verifique com dig MX seudominio.com.br). No servidor antigo, mantenha o Postfix ativo e execute postqueue -f periodicamente para reencaminhar emails para o novo destino. Após 48 horas da propagação completa, você pode desativar o Postfix no servidor antigo com segurança.

Perguntas frequentes sobre migração do Postfix

É possível migrar o Postfix sem downtime de email?

Sim, é possível minimizar o downtime mantendo o servidor antigo ativo durante a migração e alterando o registro MX apenas após validar o novo servidor. Emails recebidos durante a transição ficam na fila do servidor antigo e podem ser reentregues manualmente com o comando postqueue -f. A chave é reduzir o TTL do registro MX para 300 segundos com pelo menos 24 horas de antecedência, o que acelera a propagação após a troca.

Quais arquivos do Postfix precisam ser copiados para o novo servidor?

Os arquivos essenciais são /etc/postfix/main.cf, /etc/postfix/master.cf, /etc/postfix/virtual, /etc/postfix/transport, /etc/aliases e os certificados TLS em /etc/ssl/. Se usar SASL, copie também /etc/sasl2/smtpd.conf e o arquivo de senhas em /etc/postfix/sasl_passwd — mas nunca copie o .db diretamente; sempre regenere com postmap no servidor de destino.

Como verificar se o Postfix está funcionando corretamente após a migração?

Execute postfix check para validar a configuração, depois envie um email de teste com echo 'Teste' | mail -s 'Teste migração' [email protected] e monitore o log em /var/log/mail.log. Confirme também que as portas 25, 587 e 465 estão abertas e acessíveis no novo servidor usando nc -zv IP_NOVO_SERVIDOR 25 a partir de uma máquina externa.

O que fazer com emails na fila do servidor antigo após a migração?

Acesse o servidor antigo e execute mailq para listar os emails pendentes. Use postcat -q ID_DA_MENSAGEM para inspecionar cada mensagem e postqueue -f para tentar reentrega imediata. Se o novo servidor já estiver operacional e o MX propagado, os emails serão entregues automaticamente. Mantenha o servidor antigo ativo por pelo menos 48 horas após a troca do MX para garantir que nenhuma mensagem seja perdida.

Como migrar as senhas SASL do Postfix sem reconfigurar tudo do zero?

Copie o arquivo /etc/postfix/sasl_passwd para o novo servidor e execute postmap /etc/postfix/sasl_passwd para regenerar o banco de dados .db. Verifique as permissões com chmod 600 /etc/postfix/sasl_passwd e confirme que o pacote libsasl2-modules está instalado no destino. Nunca copie o arquivo .db diretamente entre servidores, pois ele é gerado de forma dependente do ambiente local.

Conclusão

• Faça backup antes de tudo: consolide main.cf, master.cf, mapas de virtual/transport, certificados TLS e credenciais SASL em um único arquivo compactado antes de iniciar qualquer transferência.
• Nunca copie arquivos .db entre servidores: sempre regenere os mapas de hash com postmap e o banco de aliases com newaliases no servidor de destino para evitar incompatibilidades de versão do Berkeley DB.
• Valide antes de alterar o MX: envie emails de teste, verifique os logs em /var/log/mail.log e confirme a abertura das portas 25, 587 e 465 antes de redirecionar o tráfego — isso garante que a transição seja transparente para os usuários finais.

Leia também

• Entenda o Postfix travando após upgrade no AlmaLinux 9
• Solucionar falhas do Postfix não enviando emails no Debian 12
• Entenda o que é blacklist de IP: como verificar e remover seu servidor

Precisa de ajuda com migração de servidor de email?

Migrar o Postfix envolve múltiplas camadas de configuração que, se mal executadas, podem resultar em perda de emails ou interrupção do serviço. Um VPS Linux com suporte técnico especializado pode tornar esse processo mais seguro e controlado.

Conheça os planos de VPS da AviraHost e migre seu servidor de email com segurança