Análise de Causa Raiz: Falha Global de Roteamento de E-mails em Migração cPanel

Resumo da Ocorrência

Assumi este chamado de emergência após uma migração noturna em lote paralisar o recebimento de e-mails de dezenas de clientes corporativos. A diretoria acusou o gestor de infraestrutura de ter cometido um erro de projeto na transferência das contas. Conduzi uma perícia técnica em laboratório isolado e provei que o problema foi gerado por um bug nativo do próprio cPanel/WHM, inocentando o profissional e restabelecendo o serviço.

Responsável técnico: Percio Andrade Castelo Branco (Infraestrutura Linux e Perícia N3).

Ambiente e Parâmetros Operacionais

• Cluster Afetado: Servidores cPanel/WHM em CentOS/CloudLinux rodando MTA Exim.
• Topologia de E-mail: Contas corporativas conectadas a um gateway AntiSpam em nuvem.
• Regra de Roteamento: Política de Remote Mail Exchanger salva no arquivo /etc/remotedomains.
• Janela de Migração: Transferência em lote via Transfer Tool do WHM (madrugada, das 00:27 às 04:13).

image_02 - Roteamento remoto (Remote Mail Exchanger) configurado no cPanel para entrega via AntiSpam externo.

O Cenário da Falha e a Cobrança Interna

1. Durante a janela noturna, dezenas de contas foram movidas do servidor antigo para o novo.
2. Para não sobrescrever zonas DNS customizadas e regras de subdomínios externos, o gestor de infraestrutura desmarcou a opção "Update DNS Zone" na ferramenta de transferência.
3. Pela manhã, os clientes começaram a abrir chamados relatando que não recebiam nenhuma mensagem externa.
4. Uma checagem rápida no servidor mostrou que os domínios migrados haviam mudado sozinhos para Local Mail Exchanger.
5. A diretoria acusou o gestor de ter errado a configuração ou esquecido de conferir as contas antes de fechar a janela.

Auditoria nos Logs em Produção

Para tirar a discussão de suposições e focar em dados concretos, fui direto aos logs do sistema:

# 1. Checando a tabela de entrega local do Exim
grep dominio-cliente.com.br /etc/localdomains

# 2. Testando a resolucao do host de correio
ping mail.dominio-cliente.com.br

# 3. Conferindo o historico de edicoes manuais no Zone Editor do cPanel
grep usuario_cpanel /usr/local/cpanel/logs/access_log | grep zone_editor/index.html

• Logs de Acesso: O access_log do cPanel comprovou que ninguém alterou o Zone Editor nem mexeu no roteamento após a migração.
• Logs de Restauração: O log da Transfer Tool continha avisos que passaram em silêncio: The system could not restore the zone [...] because it does not match any domain on this account.

image_03 - Coleta de evidências no terminal: checagem de /etc/localdomains e leitura dos logs brutos do cPanel.

Reprodução Controlada em Laboratório (PoC)

Para isolar o comportamento sem tocar nas contas em produção, montei um ambiente de testes idêntico:

1. Criei um domínio de teste (dominio123.com.br) com Remote Mail Exchanger ativo, conferindo a entrada em /etc/remotedomains.
2. Excluí as entradas MX e CNAME no Zone Editor para simular a zona incompleta deixada pela migração.
3. Rodei manualmente o script nativo de verificação periódica de MX do cPanel:

/scripts/checkalldomainsmxs --yes

image_04 - O flagrante: o script nativo /scripts/checkalldomainsmxs alterou compulsoriamente a rota para LOCAL MAIL EXCHANGER ao não encontrar registros MX locais.

image_05 - O resultado no disco: domínio retirado de /etc/remotedomains e gravado em /etc/localdomains.

Causa Raiz Confirmada (RCA)

• Bug de Software (Ticket cPanel #95782358): A ferramenta Transfer Tool do cPanel descartava a diretiva de roteamento de e-mails no destino quando a opção "Update DNS Zone" estava desmarcada.
• Rotina de Fallback Agressiva: O script periódico do cron /scripts/checkalldomainsmxs encontrou a zona sem registros MX locais e forçou a rota para Local Mail Exchanger.
• Conclusão Pericial: O gestor de infraestrutura agiu corretamente para proteger os registros customizados de DNS dos clientes. O problema foi causado por uma falha do cPanel.

Procedimento de Contorno Aplicado

Para normalizar o ambiente e proteger as próximas etapas da migração, criei uma rotina de correção via CLI:

# 1. Reconstruir a zona DNS no BIND
/scripts/rebuilddnszone dominio-cliente.com.br

# 2. Forcar a rota remota via API do WHM desativando deteccao automatica
whmapi1 set_manual_mx_redirects domain=dominio-cliente.com.br mx=remote

# 3. Conferir se o dominio voltou para a tabela correta do Exim
grep -E '^dominio-cliente.com.br$' /etc/remotedomains

# 4. Rodar a checagem manual para confirmar estabilidade
/scripts/checkalldomainsmxs --yes

Resultado Operacional

• 100% dos domínios normalizados com entrega externa de volta ao gateway AntiSpam.
• Gestor de infraestrutura inocentado: O laudo técnico e o vídeo da reprodução foram apresentados à diretoria, encerrando as acusações.
• Procedimento Homologado: A rotina foi aplicada nas janelas seguintes sem novas ocorrências de roteamento.