SPF Hard Fail em Produção: Correções no SPFBL, SpamExperts, DirectAdmin e cPanel

Se você usa o SpamExperts como camada de filtragem e começou a receber relatos sobre falhas de recebimento, principalmente de domínios como Outlook e Hotmail, provavelmente existe um conflito de SPF no seu fluxo de e-mail.

Neste guia, você vai ver a causa do problema e a correção definitiva no servidor.

O diagnóstico: conflito com SPF hard fail

O problema costuma aparecer quando o domínio do remetente usa SPF com -all (hard fail) e o e-mail passa pelo filtro antes de chegar ao servidor final.

O fluxo do erro é este:

1. O remetente envia o e-mail (por exemplo, Outlook/Hotmail).
2. O SpamExperts recebe e processa a mensagem.
3. O SpamExperts entrega para o seu servidor (Exim em DirectAdmin/cPanel).
4. O servidor valida SPF do remetente original, mas enxerga o IP do filtro.
5. Como o IP do filtro não está autorizado no SPF do remetente, a mensagem é rejeitada.

Nos logs do Exim (/var/log/exim/mainlog), geralmente aparece algo como:

rejected RCPT: SPF: [IP-DO-FILTRO] is not allowed to send mail from hotmail.com

A solução: whitelist de IPs confiáveis

A correção é confiar explicitamente nos IPs do SpamExperts no servidor de destino para evitar rejeição SPF indevida nesse cenário.

DirectAdmin: ajuste no arquivo de whitelist

No DirectAdmin, edite o arquivo abaixo:

nano /etc/virtual/whitelist_hosts_ip

No cPanel, o arquivo de hosts confiáveis é:

nano /etc/trustedmailhosts

Adicione os ranges oficiais do SpamExperts (exemplos mais comuns):

185.201.16.0/22
185.201.16.0/24
185.201.17.0/24
185.201.18.0/24
185.201.19.0/24
192.69.18.0/24
208.70.90.0/24
45.91.121.0/24
45.93.148.0/24
45.131.180.0/24
45.140.132.0/24
193.41.32.0/24
185.225.27.0/24
80.91.219.0/24
188.190.113.0/24
45.147.95.0/24
46.229.240.0/24
87.236.163.0/24
188.190.112.0/24
192.69.19.0/24
208.70.91.0/24
185.209.51.0/24
185.218.226.0/24

• Lista completa em: https://documentation.n-able.com/spamexperts/userguide/Content/Appendix/hc-deliv-ips.htm
• CSV: https://download.cdn.seinternal.com/public/delivery-subnets.csv

Nota: valide os blocos atuais na documentação oficial do fornecedor, porque os ranges podem mudar.

Reinicie o Exim:

service exim restart

Validação pós-ajuste

Após aplicar, acompanhe os logs em tempo real e faça um novo teste de envio (exemplo: Outlook -> domínio hospedado no seu servidor):

tail -f /var/log/exim/mainlog

Quando estiver correto, você deve ver entrada com status de entrega/salvamento, por exemplo:

2026-01-27 15:56:17 ... <= mail@hotmail.com H=out13-256.antispamcloud.com [45.93.148.2] ... Saved

Spam filtering e entregabilidade precisam caminhar juntos. Ao manter a whitelist de hosts confiáveis atualizada (/etc/virtual/whitelist_hosts_ip no DirectAdmin e /etc/trustedmailhosts no cPanel), você reduz falsos bloqueios SPF sem abrir mão da proteção antispam.

Identidade de remetente: o problema oculto do noreply@

Mesmo com relay e SPF ajustados, o bloqueio pode continuar quando o remetente usa noreply@ sem caixa real de entrada.

Checklist que uso:

1. Validar se a mailbox remetente existe de fato.
2. Testar roteamento local com exim -bt.
3. Revisar padrões de envio unilateral em aplicações.

Comandos úteis:

exim -bt noreply@seudominio.com
grep -i "noreply@" /var/log/exim/mainlog | tail -n 200

Boa prática operacional:

• trocar From: noreply@... por remetente funcional (sistema@...);
• manter Reply-To para suporte/atendimento;
• alinhar SPF, DKIM e DMARC ao novo endereço de envio.

Este post está licenciado sob CC BY-NC.