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 num retrato estático. Os fornecedores publicam faixas de IP que mudam; o registo 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 registo alojado 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 registo 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 fornecedores.
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: / redirect= | 1 (mais a cadeia que resolvem) |
a / mx / ptr / exists | 1 cada um |
ip4: / ip6: / all | 0 busca |
Não confunda este contador com um segundo limite, imposto pela mesma secção: as resoluções de endereço geradas por um mesmo termo mx estão limitadas a 10 consultas A/AAAA, mas não são imputadas ao orçamento de 10 buscas. Um mx num domínio com 5 servidores custa 1, não 5.
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 fiá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 registo A/AAAA ou MX) também geram permerror. A maioria dos validadores ignora isso; esta ferramenta conta as void lookups e expõe-nas no veredicto.
Cuidado para não confundir: o permerror de buscas é diferente do permerror de sintaxe (registo malformado, vários SPF no mesmo domínio). O achatamento não corrige nem a sintaxe nem o caso de SPF duplicado; o veredicto de erro da ferramenta deteta esses problemas antes. Para a sintaxe, use o SPF Syntax Check.
Porque o achatamento é arriscado (mudança de IP)
O risco vem de congelar IPs que continuam a mudar do outro lado:
- Falsos negativos: um novo IP legítimo do fornecedor não está na lista achatada e o envio falha no SPF.
- Superfície de spoofing: um IP desativado continua autorizado pelo seu registo, expondo o seu domínio.
- Falhas intermitentes: difíceis de diagnosticar, porque o registo parece válido.
Dois números, ambos com fonte:
- Mailhardener documentou um caso real: depois de um achatamento, um fornecedor 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 registo incha em dezenas de blocos ip4/ip6.
Sobre os grandes fornecedores: 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 fornecedor; é uma classificação editorial, não uma cadência inventada.
Para medir o impacto na receçã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 registo 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 o 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). Registo dinâmico, sem dívida de obsolescência. Técnica avançada, indicada para quem domina a sintaxe.
- Alojamento ou CNAME auto-atualizado. Mantém o registo sempre atual. Honestamente: gera dependência do fornecedor (vendor lock-in) e perda de controlo 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 reencaminhamento nem de listas de discussão, porque o SPF testa o IP que se liga, 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: já fez a limpeza, não pode delegar nem usar alojamento, está genuinamente acima de 10 buscas com remetentes todos essenciais, e se compromete a ressincronizar o registo. Não é um conserto único; é uma dívida de manutenção.
Quando achatar, prefira o dinâmico (macros ou alojamento) ao estático. Se mesmo assim optar pelo estático: monitorize continuamente (com o SPF Checker) e aceite o risco de mudança de IP descrito acima. Numa frase: um achatamento estático de uma única vez é uma dívida, não um conserto.
Como ler o veredicto da ferramenta
A ferramenta resume tudo em cinco veredictos e duas medidas de orçamento:
- ok: não precisa achatar; deixe o registo como está.
- em risco: perto do limite; monitorize.
- acima do limite: permerror; corrija com prioridade.
- erro: não dá para achatar; corrija a sintaxe ou o SPF duplicado primeiro.
- em falta: publique um SPF antes de tudo.
As medidas: "X / 10 buscas" e "V / 2 void lookups". Reforçando o ponto central: veredicto 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 registo SPF novo a partir dos seus fornecedores |
| 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.