SPFBL Check Blocked: Diagnóstico Completo (SPF Hard Fail, Hotmail/Outlook e Relay)

Bloqueio com SPFBL check blocked em remetente legítimo é um incidente comum em operações de e-mail com Exim. O erro aparece principalmente quando a origem lógica do remetente (Microsoft, Google etc.) não coincide com o IP real de entrega no hop final.

Neste caso, o domínio remetente publicava SPF com -all, e o e-mail chegava via relay intermediário (infraestrutura antispam). Resultado: hard fail na validação e bloqueio pelo SPFBL.

1) Sintoma observado em produção

No exim_mainlog, o padrão era:

rejected RCPT <destinatario@dominio.com>: SPFBL check blocked

Comando para observar em tempo real:

tail -f /var/log/exim_mainlog | egrep -i "spfbl|rejected RCPT|spf"

Comando para extrair histórico recente do remetente:

grep -i "@domain.com" /var/log/exim_mainlog | tail -n 200

2) Causa raiz técnica: SPF com -all + entrega fora da origem autorizada

SPF publicado pelo remetente:

v=spf1 include:spf.protection.outlook.com -all

Interpretação operacional:

• include:spf.protection.outlook.com autoriza infraestrutura Microsoft;
• -all exige reprovação explícita para qualquer IP fora dessa política.

Se o e-mail é entregue por relay externo (por exemplo, antispam gateway), o IP do último hop pode não bater com o SPF do domínio. Nesse ponto, SPFBL aplica bloqueio por hard fail.

3) Como eu validei tecnicamente (sem suposição)

3.1 Validar rota real de entrega no Exim

exim -Mvh ID_DA_MENSAGEM

Use exim -Mvh para extrair Received: e identificar o host/IP efetivo do hop que chegou no seu MTA.

3.2 Testar SPF do domínio remetente

dig +short TXT domain.com

Se retornar política com -all, o comportamento de hard fail está confirmado.

3.3 Testar decisão do SPFBL antes da mudança

spfbl check IP_ORIGEM remetente@domain.com destinatario@seudominio.com

No caso analisado, a saída vinha com BLOCK mesmo para remetente legítimo, porque a origem de entrega não era a autorizada no SPF.

4) Por que a whitelist simples falha nesse cenário

Tentativa comum:

spfbl white add domain.com

Em cenário de hard fail, isso pode não ser suficiente porque o SPFBL pode priorizar o resultado técnico de autenticação da origem de entrega.

Ou seja, sem qualificar também o relay, a regra fica genérica demais para esse caso.

4.1) Quando Hotmail/Outlook chega por relay terceirizado

Esse é o cenário clássico que gera ruído no suporte: o remetente é legítimo, mas o último hop não é Microsoft e sim um gateway intermediário.

Exemplo típico:

H=gateway-out.servidor-antispam.com [45.xx.xx.x] rejected RCPT: SPFBL check blocked

Nessa situação, vale validar reputação do relay e tratar a exceção com escopo mínimo.

5) Correção aplicada: whitelist qualificada por remetente + infraestrutura

Regra que resolveu o caso:

/usr/local/bin/spfbl white add "@domain.com;antispamcloud.com"

Semântica da regra:

• @domain.com: escopo do remetente;
• ;antispamcloud.com: qualificador de infraestrutura (HELO/EHLO/relay).

Isso libera apenas o cenário legítimo esperado, sem abrir exceção ampla para qualquer origem.

6) Pós-correção: validação e critérios de aceite

6.1 Validar regra cadastrada

spfbl white show | grep -i "domain.com\|antispamcloud.com"

6.2 Reexecutar teste de decisão

spfbl check IP_ORIGEM remetente@domain.com destinatario@seudominio.com

Esperado após correção:

First WHITE match: @domain.com;antispamcloud.com

6.3 Confirmar entrega no Exim

grep -i "remetente@domain.com" /var/log/exim_mainlog | tail -n 100

Critério de aceite operacional:

1. sem SPFBL check blocked para o fluxo qualificado;
2. e-mail entregue no destino sem freeze/bounce indevido;
3. exceção limitada ao par remetente + relay autorizado.

7) Hardening e boas práticas para não repetir incidente

1. Evite whitelist genérica sem qualificador de infraestrutura.
2. Monitore exim_mainlog com filtro de SPFBL diariamente.
3. Revise mudanças de rota SMTP dos clientes (smarthosts novos, relays híbridos).
4. Documente exceções por ticket (quem pediu, por quê, prazo de revisão).
5. Audite regras antigas do SPFBL para remover permissões obsoletas.

8) Checklist rápido para incidentes com Hotmail/Outlook

1. Confirmar rota SMTP real com exim -Mvh.
2. Extrair padrão no log por domínio e relay.
3. Validar SPF publicado com dig.
4. Reproduzir decisão no spfbl check.
5. Aplicar exceção mínima (remetente + relay autorizado).
6. Documentar a regra e prazo de revisão.

9) Comando rápido de rollback (se exceção abrir demais)

spfbl white drop "@domain.com;antispamcloud.com"

Depois do drop, revalide com spfbl check e monitore log para garantir retorno ao comportamento padrão.

Esse tipo de incidente não é “erro do usuário final”; é desalinhamento entre política SPF e caminho real de transporte. Com validação de headers, teste de SPFBL e whitelist qualificada, a correção fica estável e auditável.

Este post está licenciado sob CC BY-NC.