O que é o SPF flattening (e o que não é)
O SPF flattening (achatamento) substitui os mecanismos que custam buscas DNS (include:, a, mx, redirect= e exists) pelos endereços IP literais que eles resolvem (ip4: / ip6:). Os mecanismos ip4, ip6 e all custam zero busca; é por isso que, no papel, o achatamento "funciona".
A armadilha aparece logo: o achatamento congela uma delegação viva em um retrato estático. Os provedores publicam faixas de IP que mudam; o registro achatado, não.
Atenção a uma distinção importante: o achatamento estático (uma fotografia única dos IPs) não é a mesma coisa que uma solução dinâmica (macros SPF ou um registro hospedado que se atualiza sozinho). Os dois reduzem as buscas, mas só o dinâmico acompanha a realidade. Mais sobre isso no guia SPF flattening versus macros.
Exemplo, antes do achatamento:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Esse registro consome várias buscas DNS (o Google sozinho usa cerca de 4).
Exemplo, depois do achatamento (retrato congelado):
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 ip4:167.89.0.0/17 ip4:198.2.128.0/18 ip4:205.201.128.0/20 ~all
Resultado: zero busca DNS, porque todos os endereços são explícitos. Mas esse "depois" é um retrato que se deteriora a cada mudança de faixa nos provedores.
O limite de 10 buscas DNS e o PermError
A RFC 7208 §4.6.4 impõe um máximo de 10 buscas DNS na avaliação do SPF. O custo de cada mecanismo:
| Mecanismo | Custo |
|---|---|
include: / a / mx / ptr / exists / redirect= | 1 busca ou mais |
ip4: / ip6: / all | 0 busca |
Acima de 10 buscas, o resultado é um permerror, e o efeito é uma dupla falha. Mensagens legítimas podem ser rejeitadas ou jogadas no spam, e os impostores deixam de ser bloqueados de forma confiável. Pior: o alinhamento DMARC quebra para todos os fluxos. Veja o guia do SPF PermError e too many DNS lookups para corrigir e revalidar com o SPF Checker.
Existe um segundo limite, quase sempre esquecido: mais de 2 void lookups (buscas que não retornam registro A/AAAA ou MX) também geram permerror. A maioria dos validadores ignora isso; esta ferramenta conta as void lookups e as expõe no veredito.
Cuidado para não confundir: o permerror de buscas é diferente do permerror de sintaxe (registro malformado, vários SPF no mesmo domínio). O achatamento não corrige nem a sintaxe nem o caso de SPF duplicado; o veredito de erro da ferramenta detecta esses problemas antes. Para a sintaxe, use o SPF Syntax Check.
Por que o achatamento é arriscado (mudança de IP)
O risco vem de congelar IPs que continuam mudando do outro lado:
- Falsos negativos: um novo IP legítimo do provedor não está na lista achatada e o envio falha no SPF.
- Superfície de spoofing: um IP desativado continua autorizado pelo seu registro, expondo seu domínio.
- Falhas intermitentes: difíceis de diagnosticar, porque o registro parece válido.
Dois números, ambos com fonte:
- Mailhardener documentou um caso real: depois de um achatamento, um provedor de e-mail adicionou um IP de balanceador de carga e cerca de 1 mensagem em 20 passou a falhar no SPF.
- Segundo a telemetria da AutoSPF, um include de terceiros muda, na mediana, a cada ~11,5 dias; alvos IPv6 mudam cerca de 2,1× mais que os IPv4. Trate como valor indicativo de melhor esforço.
Há ainda a armadilha de tamanho: o achatamento resolve o limite de buscas mas piora o limite de tamanho (255 caracteres por segmento TXT, 512 bytes por resposta UDP, na prática algo entre ~450 e 600 caracteres úteis). O registro incha em dezenas de blocos ip4/ip6.
Sobre os grandes provedores: Microsoft 365 (Exchange Online), Google Workspace, Amazon SES, SendGrid e Mailchimp publicam faixas de IP amplas e que mudam, o que torna um achatamento estático frágil. A ferramenta mostra badges de risco (baixo, médio, alto) por provedor; é uma classificação editorial, não uma cadência inventada.
Para medir o impacto na recepção, veja a pontuação de entregabilidade.
Alternativas a tentar antes de achatar
As recomendações da ferramenta seguem esta ordem, do mais seguro ao mais arriscado. Trabalhe a lista de cima para baixo.
- Limpeza primeiro. Remova os
include:não utilizados ou que nunca dão pass, elimine optr(desencorajado pela RFC), cortea/mxredundantes e deduplique. Muitas vezes isso já devolve o registro para baixo de 10 buscas, sem congelar nenhum IP. Cruze com os dados agregados do DMARC para saber quem realmente envia. - Delegação por subdomínio. Um subdomínio dedicado por fluxo de envio, cada um com seu próprio orçamento de 10 buscas. Sobre o medo comum: o alinhamento DMARC relaxado (
aspf=r) mantém tudo alinhado, o DMARC não quebra. - Macros SPF (RFC 7208 §7). Registro dinâmico, sem dívida de obsolescência. Técnica avançada, indicada para quem domina a sintaxe.
- Hospedagem ou CNAME auto-atualizado. Mantém o registro sempre atual. Honestamente: gera dependência do fornecedor (vendor lock-in) e perda de controle direto sobre o DNS.
- Transferir a confiança para DKIM e DMARC (com ARC e SRS). A chave conceitual: o achatamento nunca corrige falhas de encaminhamento nem de listas de discussão, porque o SPF testa o IP que conecta, que muda no forward. A robustez vem do DKIM (que sobrevive ao relay) e do alinhamento DMARC via DKIM, com ARC e SRS. Veja o DMARC Generator para configurar a política.
Quando o achatamento é realmente justificado
O caso é estreito: você já fez a limpeza, não pode delegar nem usar hospedagem, está genuinamente acima de 10 buscas com remetentes todos essenciais, e se compromete a ressincronizar o registro. Não é um conserto único; é uma dívida de manutenção.
Quando achatar, prefira o dinâmico (macros ou hospedagem) ao estático. Se mesmo assim optar pelo estático: monitore continuamente (com o SPF Checker) e aceite o risco de mudança de IP descrito acima. Em uma frase: um achatamento estático de uma única vez é uma dívida, não um conserto.
Como ler o veredito da ferramenta
A ferramenta resume tudo em cinco vereditos e duas medidas de orçamento:
- ok: não precisa achatar; deixe o registro como está.
- em risco: perto do limite; monitore.
- acima do limite: permerror; corrija com prioridade.
- erro: não dá para achatar; corrija a sintaxe ou o SPF duplicado primeiro.
- ausente: publique um SPF antes de tudo.
As medidas: "X / 10 buscas" e "V / 2 void lookups". Reforçando o ponto central: veredito verde significa não mexer.
Ferramentas complementares
| Ferramenta | Utilidade |
|---|---|
| SPF Record Check | Diagnostique o SPF publicado e revalide após qualquer mudança |
| SPF Syntax Check | Valide a sintaxe antes de publicar |
| SPF Generator | Monte um registro SPF novo a partir dos seus provedores |
| DMARC Record Check | Verifique o alinhamento DMARC e a política |
| DKIM Record Check | Confirme a robustez do DKIM, que sobrevive ao relay |
| Mail Tester | Valide a entrega de ponta a ponta |
| Mail Domain Check | Auditoria completa da autenticação de e-mail |
| IP Blacklist Check | Reputação do IP remetente |
| Domain Blacklist Check | Reputação do domínio remetente |
Recursos úteis
- RFC 7208 - Sender Policy Framework (SPF): a fonte do limite de 10 buscas, do limite de void lookups e das macros.
- RFC 4408 - SPF (versão anterior): versão legada da especificação.
- dmarcian - SPF Best Practices: autoridade que concluiu, na prática, que o achatamento não é a abordagem recomendada.
- Mailhardener - Do not flatten your SPF record: a fonte do caso de ~1 mensagem em 20.
- Google Workspace - configurar e solucionar problemas de SPF: guia para configurar e diagnosticar SPF com o Google.
- Microsoft 365 - configurar SPF: guia para configurar e diagnosticar SPF com a Microsoft.