Mudança de DNS em produção pode derrubar recebimento de e-mail sem afetar imediatamente o envio local. O efeito mais comum é “aparente normalidade” no servidor, enquanto provedores externos continuam tentando o MX antigo.
Este runbook foi aplicado para recuperar entrega com evidência técnica, sem achismo de propagação.
1) Sintoma real do incidente
Padrão observado:
- envio interno funciona;
- recebimento externo (Gmail/Outlook) falha;
- mensagens somem ou voltam com bounce;
- fila Exim acumula defers/frozen.
Primeira coleta:
tail -f /var/log/exim_mainlog | egrep -i "defer|frozen|dns|host lookup|retry"
2) Validar integridade da zona no BIND (camada autoritativa)
Antes de checar internet, valide se a zona local está sintaticamente correta.
named-checkzone domain.com.br /var/named/domain.com.br.db
Pontos que costumo corrigir aqui:
- serial SOA sem incremento;
- FQDN sem ponto final;
- MX apontando para host sem A/AAAA válido;
- NS divergente do delegado no registrador.
Após correção:
rndc reload
rndc status
3) Validar resposta do servidor autoritativo local
dig @127.0.0.1 MX domain.com.br +short
dig @127.0.0.1 NS domain.com.br +short
dig @127.0.0.1 A mail.domain.com.br +short
Se autoritativo local já responde certo, passe para visão externa.
4) Rastrear delegação externa e propagação real
dig MX domain.com.br +trace
dig NS domain.com.br +trace
A análise do +trace mostra exatamente em qual etapa a internet ainda aponta infra antiga (root -> TLD -> NS autoritativo).
Checagens de resolvedores públicos:
dig @8.8.8.8 MX domain.com.br +short
dig @1.1.1.1 MX domain.com.br +short
dig @9.9.9.9 MX domain.com.br +short
Se cada resolvedor traz resultado diferente, você está em janela de propagação.
5) Auditoria da fila Exim durante a janela de transição
Listar mensagens relacionadas ao domínio:
exiqgrep -r "@domain.com.br"
exiqgrep -r "@domain.com.br" -c
Inspecionar mensagem específica:
exim -Mvh ID_DA_MENSAGEM
exim -Mvl ID_DA_MENSAGEM
Forçar tentativa após corrigir DNS:
exim -Mt ID_DA_MENSAGEM
exim -qff
Mensagens congeladas:
exiqgrep -z -i
6) Erros clássicos que encontrei nesse tipo de incidente
- MX novo configurado, mas registrador ainda delegando NS antigo.
- MX aponta para
mail.domain.com.br, porém A/AAAA do host não existe. - Firewall do novo host bloqueando 25/tcp.
- Fila com mensagens tentadas durante janela errada (já devolvidas no remoto).
Teste de porta SMTP pública no novo destino:
nc -vz mail.domain.com.br 25
7) Critério de recuperação operacional (aceite)
named-checkzonesem erros.- autoritativo local retornando MX/NS corretos.
- resolvedores públicos convergindo para novo destino.
- Exim processando fila sem novos defers por DNS.
- recebimento externo validado por pelo menos dois provedores.
8) Pós-incidente: prevenção
- executar pré-check DNS antes de qualquer mudança em produção;
- documentar TTL e janela de propagação esperada;
- manter monitor de fila Exim por domínio após cutover;
- incluir teste de recebimento externo no checklist de mudança.
Falha de e-mail pós-mudança DNS quase nunca é “bug misterioso”. Normalmente é combinação de delegação externa não convergida e fila em retry/frozen. Com sequência BIND -> trace -> Exim, a causa aparece rápido e a recuperação fica controlada.
Este post está licenciado sob CC BY-NC.
Comentários
Participe da discussão abaixo.
Comentários ainda não configurados. Adicione as opções do Cusdis em /assets/json/config/blog-comments-config.json.