Se o seu SPF parou de funcionar "do nada", a causa mais provável é o erro permerror por excesso de lookups. É um limite técnico que pega muita gente de surpresa — mas tem solução. Vamos por partes.
O que é o permerror
permerror (permanent error) significa que o seu registro SPF é inválido e não pode ser avaliado. Quando isso acontece, é como se você não tivesse SPF nenhum: o resultado da autenticação falha, o DMARC pode reprovar a mensagem, e seus e-mails passam a cair em spam ou serem rejeitados.
A regra dos 10 lookups
A especificação do SPF (RFC 7208) define um limite rígido: a avaliação de um SPF pode fazer no máximo 10 consultas de DNS. Passou disso? permerror na hora.
Os mecanismos que consomem um lookup são:
| Consome lookup | Não consome |
|---|---|
include: | ip4: |
a | ip6: |
mx | all |
ptr (evite!) | |
exists | |
redirect= |
O detalhe traiçoeiro: cada include pode conter outros includes. Um único include:_spf.google.com já vale por vários lookups internos. Por isso o limite estoura mais rápido do que parece.
Por que acontece
Geralmente é acúmulo: a empresa adiciona Google, depois uma ferramenta de marketing, depois um ERP, depois um sistema de NF-e... cada um pede para incluir o seu include. Quando se percebe, são 11, 12 lookups.
Como resolver
1. Remova o que não usa
O ganho mais fácil. Aquele serviço que você testou e abandonou ainda está no SPF? Tire. Revise cada include e pergunte: "isto ainda envia e-mail por mim?".
2. Troque includes por IPs, quando fizer sentido
Se um remetente usa IPs fixos e estáveis, você pode usar ip4: em vez de include: — IPs não consomem lookup. Cuidado: só faça isso com IPs que realmente não mudam.
3. Separe remetentes por subdomínios
Em vez de empilhar tudo no domínio principal, use subdomínios: o marketing envia por news.suaempresa.com.br (com o SPF do provedor de marketing) e o corporativo por suaempresa.com.br. Cada um tem seu próprio orçamento de 10 lookups.
4. Considere o "achatamento" (SPF flattening) com cautela
É a técnica de substituir os includes pelos IPs que eles resolvem, deixando um SPF "plano". Resolve o limite, mas tem um risco: se o provedor mudar os IPs dele, o seu SPF fica desatualizado e quebra. Só use com monitoramento ativo.
5. Nunca use ptr
O mecanismo ptr é lento, consome lookup e é desaconselhado pela própria RFC. Se estiver no seu registro, remova.
Evite que volte a acontecer
O SPF estoura justamente quando você adiciona um novo serviço — e ninguém percebe na hora. Com monitoramento contínuo, você é avisado assim que passa do limite, antes de os e-mails começarem a falhar. Para reconstruir um SPF limpo, use o gerador de SPF.