SPFBL check blocked: diagnóstico completo (SPF hard fail, hotmail/Outlook e relay)

Bloqueio com SPFBL check blocked em remetentes legítimos é um incidente comum e complexo em operações de e-mail gerenciadas sob o Exim e cPanel. O erro manifesta-se principalmente quando a origem lógica declarada do remetente (como Microsoft 365 ou Google Workspace) difere do IP real que realiza a entrega física da mensagem no MTA final.

Este artigo apresenta uma análise técnica detalhada de um cenário no qual o domínio do remetente publicava um registro SPF rigoroso com o qualificador -all (Hard Fail), mas a mensagem passava por um relay intermediário (como gateways de antispam). O resultado era a rejeição imediata da mensagem pelo serviço de RBL local SPFBL.

1) Sintoma observado em produção#

O primeiro sinal do incidente surge nos logs de transação SMTP do Exim, indicando que conexões legítimas estão sendo ativamente rejeitadas no comando RCPT TO:

rejected RCPT <[email protected]>: SPFBL check blocked

Para monitorar estes bloqueios em tempo real de forma interativa, utilize:

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

Para extrair e auditar o histórico de rejeições recentes associado a um remetente ou domínio específico:

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

2) Verificação prévia de saúde do daemon SPFBL#

Antes de realizar qualquer alteração cadastral ou de regras no banco de dados do antispam, certifique-se de que o daemon local do SPFBL está ativo, saudável e respondendo na porta padrão de consulta (8001 ou 9877 dependendo do setup):

# 1. Verificar o estado do serviço no gerenciador de processos
systemctl status spfbl

# 2. Consultar o endpoint de status da API local do SPFBL
curl -s http://localhost:8001/api/v1/status | head -5
# Nota: Caso a API REST não esteja habilitada, utilize consultas de teste via socket UDP/TCP:
# spfbl check 127.0.0.1 [email protected] [email protected]

# 3. Auditar a execução do processo no sistema operacional
ps aux | grep spfbl | grep -v grep

# 4. Validar se a porta de escuta do serviço está ativa
ss -lntp | grep -iE "8001|9877|spfbl"

# 5. Verificar a versão local do binário do SPFBL
spfbl version

# 6. Exibir o cabeçalho das configurações vigentes
cat /etc/spfbl/spfbl.conf 2>/dev/null | head -20

3) Backup preventivo das regras e do banco SPFBL#

Qualquer alteração em tabelas de whitelist ou regras de reputação deve ser precedida de um backup seguro. Isso garante que a reversão seja rápida caso regras inadequadas sejam propagadas:

# 1. Exportar todas as regras de whitelist vigentes para arquivo texto com timestamp
spfbl white show > /root/spfbl-whitelist-backup-$(date +%Y%m%d).txt

# 2. Realizar cópia física do banco de dados relacional do SPFBL (se aplicável ao setup local)
# O caminho padrão pode variar conforme a instalação (/var/lib/spfbl/ ou /var/spfbl/)
sudo cp /var/lib/spfbl/spfbl.db /root/spfbl-backup-$(date +%Y%m%d).db

4) Diagnóstico técnico e rota de entrega#

O diagnóstico correto exige a análise do caminho real percorrido pela mensagem e a verificação das configurações de DNS do remetente.

4.1 identificação do roteamento real via headers (Exim spool)#

Quando uma mensagem fica retida ou gera logs de rejeição intermediários na fila, você pode extrair a árvore de cabeçalhos (Received:) para mapear todos os hops físicos:

# Exibir o cabeçalho completo da mensagem ainda retida na fila de spool
exim -Mvh ID_MENSAGEM

Ao inspecionar as linhas Received:, identifique o IP físico do último servidor de borda que tentou autenticar-se contra o seu servidor de e-mail.

4.2 verificação de filas e conexões ativas no Exim#

Para entender o impacto operacional do bloqueio (por exemplo, se mensagens de um remetente parceiro estão se acumulando na fila local):

# 1. Contar o total de mensagens ativas na fila de saída/entrada do Exim
exim -bpc

# 2. Listar as primeiras 20 mensagens na fila com detalhes de remetente e destinatário
exim -bp | head -20

# 3. Verificar processos do Exim em execução para detectar gargalos de entrega
ps aux | grep exim | grep -v grep

5) Validação de DNS e checagem do registro SPF#

O SPFBL rejeita a conexão quando o domínio publica uma regra restritiva (-all) e o IP do relay não consta na lista de servidores autorizados.

5.1 loop de verificação de propagação multicasting#

Para descartar problemas de propagação ou inconsistências entre diferentes resolvers globais, consulte o TXT do domínio em múltiplos servidores de nomes externos:

# Validar o registro SPF nos servidores do Google, Cloudflare e OpenDNS simultaneamente
for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "DNS $dns: $(dig @$dns por-que-emails-legitimos-sao-bloqueados-spfbl-spf-hard-fail.html.com TXT +short | grep spf1)"
done

5.2 validação do TTL (time to live) do registro#

Consulte o TTL vigente para prever o tempo de cache necessário até que modificações no registro SPF do remetente sejam enxergadas pelo seu MTA:

dig domain.com TXT | grep -A1 "ANSWER SECTION"

6) Auditoria de reputação e segurança do relay intermediário#

Se a mensagem chega por um relay intermediário (como SpamExperts, antispamcloud.com ou Mimecast), é crítico validar a reputação e a criptografia desse canal antes de aplicar qualquer whitelist.

6.1 consulta de reputação do IP do relay#

Evite whitelistar relays comprometidos ou com histórico de envio de spam. Utilize as APIs de reputação de mercado:

# 1. Consultar reputação do IP do relay via AbuseIPDB API
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=45.xx.xx.x" \
  -H "Key: SUA_API_KEY_AQUI" \
  -H "Accept: application/json"

# 2. Consultar o reverso DNS (PTR) para garantir que o IP do relay possui um FQDN válido
dig -x 45.xx.xx.x +short

6.2 auditoria de segurança TLS do relay#

Verifique se a conexão entre o relay intermediário e o seu MTA é protegida por criptografia de transporte (TLS):

# 1. Testar se o gateway do relay suporta STARTTLS na porta padrão de SMTP (25)
openssl s_client -connect gateway-out.servidor-antispam.com:25 -starttls smtp

# 2. Validar o período de validade do certificado SSL do relay
echo | openssl s_client -connect gateway-out.servidor-antispam.com:25 2>/dev/null | openssl x509 -noout -dates

# 3. Auditar conexões TLS recentes no log do Exim para assegurar o uso de cifras seguras
grep -i "tls" /var/log/exim_mainlog | tail -n 10

7) Análise de logs do Exim e escopo de impacto (blast radius)#

Antes de aplicar a correção, investigue se o problema afeta múltiplos domínios locais.

7.1 filtragem avançada nos logs de produção#

Para coletar e classificar logs de erros específicos de SPF e relay no Exim:

# 1. Filtrar erros recentes relacionados especificamente a bloqueios de SPFBL
grep -i "spf\|rejected\|blocked" /var/log/exim_mainlog | tail -n 50

# 2. Verificar tentativas de entregas bem-sucedidas para o domínio afetado
grep -i "=>.*dominio.com" /var/log/exim_mainlog | tail -n 20

# 3. Identificar potenciais falhas de autenticação de relay ou gateways
grep -i "relay\|gateway" /var/log/exim_mainlog | tail -n 20

7.2 análise de múltiplos domínios bloqueados#

Este comando auxilia na identificação de outros domínios de clientes locais que estejam enfrentando o mesmo problema de bloqueio via SPFBL:

# Listar e ordenar de forma decrescente os domínios mais bloqueados por SPFBL recentemente
grep -i "spfbl check blocked" /var/log/exim_mainlog | \
  awk '{print $6}' | sort | uniq -c | sort -rn | head -n 20

# Verificar quais domínios estão recebendo e-mails através do mesmo host de relay afetado
grep -i "antispamcloud.com" /var/log/exim_mainlog | \
  awk '{print $6}' | sort -u

8) Solução: whitelist qualificada e segura#

Cadastrar uma whitelist genérica para o domínio (spfbl white add dominio.com) é uma má prática de segurança corporativa, pois abre espaço para ataques de spoofing caso o IP de origem real envie mensagens maliciosas.

A solução madura consiste em associar o domínio do remetente à assinatura de infraestrutura (HELO/EHLO) do relay parceiro:

/usr/local/bin/spfbl white add "@dominio-remetente.com;antispamcloud.com"

Análise da regra#

• @dominio-remetente.com: Restringe a liberação somente a remetentes daquele domínio específico.
• ;antispamcloud.com: Exige que a conexão SMTP de entrega seja realizada exclusivamente por servidores com HELO/EHLO pertencentes a essa infraestrutura de relay.

9) Monitoramento pós-correção e alertas no cron#

Após inserir a regra, realize o monitoramento dinâmico para garantir o fluxo correto de entrega de mensagens.

9.1 testar decisão do SPFBL#

Valide se a regra foi aplicada e é reconhecida pelo daemon local:

# O retorno deve indicar a regra de whitelist correspondente
spfbl check IP_DO_RELAY [email protected] [email protected]

9.2 monitorar logs em tempo real#

tail -f /var/log/exim_mainlog | grep -iE "@dominio-remetente.com|spfbl"

9.3 script de alerta automático para SPFBL#

Para evitar novos downtimes silenciosos, você pode configurar um monitor básico executado a cada 5 minutos no crontab do root para alertar sobre surtos de bloqueio do SPFBL:

# Adicione a seguinte linha ao crontab (/etc/crontab ou crontab -e):
# */5 * * * * /usr/bin/grep -c "spfbl check blocked" /var/log/exim_mainlog | xargs -I{} test {} -gt 10 && echo "Alerta: Mais de 10 bloqueios SPFBL detectados no Exim recentemente." | mail -s "SPFBL Blocks Alert" [email protected]

10) Checklist: diagnóstico de bloqueio SPFBL#

Utilize este roteiro operacional para triagem ágil em campo:

Fase 1: Diagnóstico e validação do estado#

• [ ] Daemon SPFBL: Validou o status do serviço (systemctl status spfbl) e sua escuta na porta 8001.
• [ ] Logs Iniciais: Coletou as mensagens de erro detalhadas no exim_mainlog.
• [ ] Rota Efetiva: Extraiu o IP e o hostname do último hop de rede com exim -Mvh.
• [ ] Versão e Configuração: Verificou a versão do binário (spfbl version) e leu o arquivo spfbl.conf.

Fase 2: Auditoria de segurança e redes#

• [ ] Segurança TLS: Validou se o relay suporta STARTTLS e se possui certificado SSL válido.
• [ ] Reputação do IP: Realizou consultas no AbuseIPDB e reverso DNS para o IP do relay.
• [ ] Propagação DNS: Consultou o registro SPF em resolvers distintos descartando lags de propagação.
• [ ] Error Budget e Filas: Monitorou a volumetria da fila de mensagens (exim -bpc).

Fase 3: Mitigação e homologação#

• [ ] Backup Realizado: Exportou a tabela de whitelist vigente antes de aplicar novas regras.
• [ ] Regra Scoped: Adicionou a whitelist delimitando remetente + HELO/EHLO do relay.
• [ ] Validação da Regra: Confirmou a whitelist executando a simulação direta em spfbl check.
• [ ] Auditoria de logs: Monitorou a entrega bem-sucedida no Exim após o cadastramento da regra.

Referências#

• RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. (Especificação oficial do comportamento de Hard Fail -all).
• RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security. (Especificação do STARTTLS).
• SPFBL Project Documentation: Guia oficial de integração de MTAs (Exim/Postfix) e comandos de whitelist delimitados por HELO/EHLO.

Veja também

E-mail O buraco negro do Exim, falhas de alinhamento DMARC e como recuperar a reputação de IP

E-mail Whitelist de Domínio vs. Bloqueio RBL no cPanel e Exim: Por Que Liberar o Domínio Falha e Como Funcionam as DNSBLs

Infraestrutura Diário de infra: domando gateways antispam, falhas de SPF e filtros em Bash

Este post está licenciado sob CC BY-NC.