Voltar para blog

Como diagnosticar e resolver falhas de entrega de e-mail após alterações de DNS (Exim e BIND)

26/10/2025 · 2 min · E-mail

Compartilhar

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:

  1. envio interno funciona;
  2. recebimento externo (Gmail/Outlook) falha;
  3. mensagens somem ou voltam com bounce;
  4. 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:

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

  1. MX novo configurado, mas registrador ainda delegando NS antigo.
  2. MX aponta para mail.domain.com.br, porém A/AAAA do host não existe.
  3. Firewall do novo host bloqueando 25/tcp.
  4. 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)

  1. named-checkzone sem erros.
  2. autoritativo local retornando MX/NS corretos.
  3. resolvedores públicos convergindo para novo destino.
  4. Exim processando fila sem novos defers por DNS.
  5. recebimento externo validado por pelo menos dois provedores.

8) Pós-incidente: prevenção

  1. executar pré-check DNS antes de qualquer mudança em produção;
  2. documentar TTL e janela de propagação esperada;
  3. manter monitor de fila Exim por domínio após cutover;
  4. 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.

CC BY-NC

Este post está licenciado sob CC BY-NC.

Comentários

Participe da discussão abaixo.