Debugando o erro SPFBL Check Blocked quando Hotmail/Outlook não sai pela Microsoft

Quando um e-mail de @hotmail.com é bloqueado com SPFBL check blocked, o erro geralmente não está no usuário final. O problema costuma estar no caminho de transporte: mensagem legítima saindo por relay intermediário com reputação ruim.

Este caso mostrou exatamente isso: o remetente era legítimo, mas o último hop até o servidor de destino não era infraestrutura Microsoft.

1) Coleta de evidência no Exim

Log observado:

H=gateway-out.servidor-antispam.com [45.xx.xx.x] rejected RCPT <usuario@destino.com.br>: SPFBL check blocked.

Comandos de investigação:

tail -f /var/log/exim_mainlog | egrep -i "spfbl|rejected RCPT|hotmail|outlook"
grep -i "gateway-out.servidor-antispam.com" /var/log/exim_mainlog | tail -n 200

2) Confirmar se destino está local (não é erro de roteamento interno)

exim -bt usuario@destino.com.br

Se saída indicar roteamento local (virtual_user, dovecot_virtual_delivery), o problema é de entrada/reputação no MTA e não de resolução local do domínio.

3) Entender por que Hotmail não saiu direto pela Microsoft

Cenários comuns em produção:

1. relay corporativo (smarthost) obrigatório para saída;
2. camada antispam de terceiros no caminho;
3. política de envio do cliente redirecionando SMTP;
4. outbound pool compartilhado com reputação variável.

Ou seja: remetente lógico é Microsoft, mas IP real de entrega pertence ao gateway terceirizado.

4) Causa raiz: reputação de IP/hostname do relay intermediário

Quando o relay entra em blacklist (ou reputação negativa na SPFBL), mensagens legítimas passam a falhar no RCPT stage.

Por isso, liberar apenas remetente final sem considerar o relay costuma falhar ou gerar comportamento inconsistente.

5) Correção aplicada com foco em estabilidade

5.1 Whitelist por hostname do relay confiável

No WHM:

• Service Configuration > Exim Configuration Manager
• Access Lists > Whitelist: Trusted Mail Hosts/IPs

Regra aplicada:

*.servidor-antispam.com

5.2 Validação de MX/SPF no fluxo real

dig +short MX destino.com.br
dig +short TXT hotmail.com

5.3 Verificação pós-regra

grep -i "spfbl" /var/log/exim_mainlog | tail -n 200
exim -bp | head -n 50

Critério de aceite:

1. sem novos SPFBL check blocked para o relay aprovado;
2. entrega normal para destinatários válidos;
3. fila sem crescimento por bloqueio do mesmo motivo.

6) O que eu não fiz (e por quê)

Não usei whitelist cega por IP único, porque o pool do relay pode rotacionar e a regra quebra no primeiro swap de IP. Hostname controlado do fornecedor é mais estável nesse cenário.

Também não removi SPFBL do fluxo global. O objetivo é exceção cirúrgica, não redução geral de proteção.

7) Controles de recorrência

1. monitor diário de spfbl no exim_mainlog;
2. revisão trimestral de whitelists;
3. validação de contrato técnico com fornecedor de relay (IP pool/reputação);
4. documentação por ticket de cada exceção aplicada.

SPFBL check blocked em Hotmail/Outlook não significa fraude automática. Em muitos casos, é reputação do hop intermediário. Com análise de rota, whitelist por hostname e validação de logs, a correção fica sólida e auditável.

Este post está licenciado sob CC BY-NC.