SPF "Too Many DNS Lookups": o guia completo para corrigir o limite de 10 lookups
Por CaptainDNS
Publicado em 3 de março de 2026

- A RFC 7208 impõe um máximo de 10 DNS lookups por avaliação SPF, acima disso, o resultado é
permerrore os seus e-mails falham - Os mecanismos
include,a,mx,redirecteexistscontam como um lookup cada,ip4eip6não contam - Com 3-4 fornecedores de e-mail (Google Workspace, SendGrid, Mailchimp), facilmente atinge 9-12 lookups
- 5 métodos para corrigir: remover mecanismos desnecessários, substituir por IPs diretos, SPF flattening, SPF macros, subdomínios dedicados
- Existe também um limite de 2 void lookups (mecanismos que não retornam nenhum resultado) frequentemente ignorado
O seu registo SPF contém uma dezena de include: para cobrir todos os seus fornecedores de e-mail. Um dia, adiciona um novo serviço e os seus e-mails começam a ser rejeitados. O diagnóstico revela um permerror: ultrapassou o limite de 10 DNS lookups imposto pela RFC 7208.
Esse problema afeta a maioria das organizações que utilizam mais de 3 fornecedores de e-mail. O Google Workspace sozinho já consome 4 lookups. Adicione SendGrid, Mailchimp e um servidor MX dedicado, e já está perto do limite antes mesmo de configurar a sua última ferramenta de marketing.
Este guia explica exatamente como funciona o limite de 10 lookups, como contar os seus, e detalha 5 métodos práticos para corrigir o problema, do mais simples ao mais robusto.
O que é o limite de 10 DNS lookups SPF?
O que diz a RFC 7208
A RFC 7208, secção 4.6.4 impõe um limite estrito: a avaliação de um registo SPF não deve gerar mais de 10 consultas DNS. Esse limite existe para proteger os servidores de recebimento contra ataques de amplificação DNS. Sem ele, um atacante poderia publicar um SPF com centenas de include: aninhados e forçar os servidores a realizar milhares de consultas.
O limite aplica-se de forma recursiva: se o seu SPF inclui _spf.google.com, e este por sua vez inclui outros 3 domínios, cada inclusão conta no total de 10.
Quais mecanismos contam como um lookup?
| Mecanismo | Conta como lookup | Explicação |
|---|---|---|
include: | Sim | Resolução do SPF do domínio alvo |
a | Sim | Resolução do registo A/AAAA |
mx | Sim | Resolução MX e depois A/AAAA de cada servidor MX |
redirect= | Sim | Resolução do SPF do domínio alvo |
exists: | Sim | Verificação de existência do domínio |
ip4: | Não | Endereço IP direto, sem consulta DNS |
ip6: | Não | Endereço IP direto, sem consulta DNS |
all | Não | Mecanismo terminal, sem consulta |

A principal armadilha: o mecanismo mx pode consumir vários lookups. Se o seu domínio possui 3 servidores MX, o mecanismo mx gera 1 lookup MX + 3 lookups A, ou seja, 4 consultas para um único mecanismo.
Como contar os DNS lookups do seu registo SPF?
O método mais fiável consiste em resolver manualmente a árvore SPF. Vamos usar um exemplo concreto com captaindns.com:
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Contagem passo a passo:
| # | Mecanismo | Lookups gerados |
|---|---|---|
| 1 | include:_spf.google.com | 1 |
| 2 | → include:_netblocks.google.com | 1 |
| 3 | → include:_netblocks2.google.com | 1 |
| 4 | → include:_netblocks3.google.com | 1 |
| 5 | include:sendgrid.net | 1 |
| 6 | include:servers.mcsv.net | 1 |
| 7 | mx (resolução MX de captaindns.com) | 1 |
| Total | 7 |
Com 7 lookups, esse registo deixa uma margem de 3. A adição do HubSpot (1 lookup) e de um segundo servidor MX (1 lookup) levaria o total a 9, ainda dentro do limite.
Em vez de contar manualmente, use nosso SPF Record Check que exibe a contagem exata e sinaliza qualquer excesso.
O que acontece quando ultrapassa o limite?
Quando a avaliação SPF atinge o 11o lookup, o servidor de recebimento interrompe imediatamente a avaliação e retorna um resultado permerror. As consequências são diretas:
- O SPF é considerado inválido : não simplesmente falhou, mas estruturalmente quebrado
- O DMARC falha em cascata : se a sua política DMARC depende do SPF para o alinhamento, ela também falha
- Os e-mails são rejeitados ou enviados para spam : Gmail, Outlook e Yahoo aplicam rigorosamente esse limite
- O erro é silencioso : os seus e-mails saem sem erro do lado do envio, apenas o destinatário vê a rejeição
O problema é traiçoeiro: enquanto não ultrapassa o limite, tudo funciona. No dia em que adiciona um include: a mais, todos os seus e-mails são potencialmente afetados, não apenas os do novo fornecedor.
5 métodos para corrigir o erro "too many DNS lookups"
Método 1: Remover mecanismos desnecessários
Comece identificando os include: que não correspondem mais a serviços ativos. Um fornecedor de e-mail transacional que parou de usar há 6 meses ainda consome um ou mais lookups.
# Antes: 11 lookups (demais)
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.brevo.com mx ~all
# Após remover o Brevo (não utilizado): 9 lookups
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Verifique cada include:: esse serviço ainda envia e-mails para captaindns.com? Se a resposta for não, remova-o.
Método 2: Substituir include por ip4/ip6
Se um serviço utiliza endereços IP fixos e documentados, pode substituir seu include: pelos endereços IP diretos. Os mecanismos ip4: e ip6: não contam como lookups.
# Antes: include do servidor de e-mail (1 lookup)
v=spf1 include:mail.captaindns.com include:_spf.google.com ~all
# Depois: substituição pelo IP do servidor (0 lookup adicionado)
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Atenção: esse método só é adequado para servidores cujos IPs controla. Nunca substitua os include: do Google ou Microsoft pelos seus IPs, eles mudam regularmente sem aviso prévio.
Método 3: SPF flattening (achatamento)
O SPF flattening resolve automaticamente todos os include:, a, mx e redirect em endereços IP diretos. O resultado é um registo SPF composto apenas por ip4: e ip6:, que não geram nenhum lookup.

Vantagens:
- Resolução imediata do problema de lookups
- Compatível com todos os servidores de recebimento
- Resultado verificado e pronto para publicar
Desvantagem:
- Os IPs dos fornecedores mudam, precisa re-achatar regularmente (mensal recomendado)
Método 4: SPF macros
As SPF macros (%{i}, %{d}, %{s}) permitem construir registos dinâmicos que redirecionam a avaliação para subdomínios específicos sem consumir lookups adicionais. Essa abordagem avançada é detalhada em um próximo artigo desta série.
v=spf1 include:%{i}._spf.captaindns.com ~all
O servidor de recebimento substitui %{i} pelo IP do remetente, o que direciona para um registo SPF específico. Resultado: apenas 1 lookup em vez de vários include:.
Método 5: Subdomínios dedicados
Em vez de enviar tudo a partir do domínio principal, atribua um subdomínio a cada fornecedor:
| Subdomínio | Fornecedor | SPF dedicado |
|---|---|---|
captaindns.com | Google Workspace | include:_spf.google.com (4 lookups) |
news.captaindns.com | Mailchimp | include:servers.mcsv.net (1 lookup) |
transac.captaindns.com | SendGrid | include:sendgrid.net (1 lookup) |
Cada subdomínio tem o seu próprio registo SPF com um contador de lookups independente. Crie os SPFs de cada subdomínio com nosso SPF Generator.
Void lookups: o segundo limite que precisa de conhecer
A RFC 7208 define um segundo limite frequentemente ignorado: o número máximo de void lookups é fixado em 2. Um void lookup ocorre quando um mecanismo DNS não retorna nenhum resultado (resposta NXDOMAIN ou vazia).
Exemplos de void lookups:
- Um
include:dominio-inexistente.comque retorna NXDOMAIN - Um
aem um domínio sem registo A - Um
exists:que não corresponde a nenhuma entrada
Acima de 2 void lookups, o resultado também é permerror. Verifique se todos os seus include: apontam para domínios existentes e corretamente configurados.
Plano de ação recomendado
- Conte os seus lookups atuais: verifique o número exato de DNS lookups do seu SPF publicado
- Identifique mecanismos desnecessários: remova os
include:de fornecedores que não usa mais - Escolha o seu método de correção: flattening para um resultado imediato, subdomínios para uma solução estrutural, macros para uma abordagem avançada
- Teste antes de publicar: valide o novo registo antes de modificar a sua zona DNS
- Monitorize regularmente: os SPFs dos fornecedores mudam, verifique novamente todos os meses
FAQ
O que é o limite de 10 DNS lookups SPF?
A RFC 7208 impõe que um registo SPF não gere mais de 10 consultas DNS durante a sua avaliação. Cada mecanismo include:, a, mx, redirect e exists conta como um lookup. Os mecanismos ip4: e ip6: não contam porque contêm diretamente o endereço IP sem necessidade de resolução DNS.
Como saber quantos DNS lookups meu SPF utiliza?
Resolva manualmente cada mecanismo do seu SPF contando os include:, a, mx, redirect e exists, incluindo os dos sub-includes. Por exemplo, include:_spf.google.com consome sozinho 4 lookups porque o Google aninha 3 sub-includes. Uma ferramenta de análise SPF automatiza essa contagem e exibe o total exato.
O que acontece se meu SPF ultrapassar 10 lookups?
O servidor de recebimento retorna um resultado permerror e considera o seu SPF como inválido. Os seus e-mails correm o risco de serem rejeitados ou classificados como spam. Se o DMARC estiver configurado, ele também falha em cascata porque o alinhamento SPF não pode ser verificado.
O mecanismo mx conta como apenas um lookup?
Não. O mecanismo mx gera primeiro um lookup MX para obter a lista dos servidores de e-mail, depois um lookup A/AAAA para cada servidor retornado. Um domínio com 3 servidores MX consome potencialmente 4 lookups para um único mecanismo mx.
O que é o SPF flattening?
O SPF flattening consiste em substituir todos os mecanismos que geram lookups (include:, a, mx, redirect) pelos endereços IP diretos que eles resolvem (ip4:, ip6:). O resultado é um SPF equivalente que não consome nenhum lookup DNS.
O que é um void lookup?
Um void lookup ocorre quando um mecanismo DNS retorna uma resposta vazia (NXDOMAIN ou nenhum registo). A RFC 7208 limita os void lookups a 2. Acima disso, o resultado é permerror, mesmo que o total de lookups permaneça abaixo de 10.
Devo usar flattening ou subdomínios?
O flattening é a solução mais rápida, mas exige manutenção mensal porque os IPs dos fornecedores mudam. Os subdomínios oferecem uma solução estrutural duradoura que isola cada fornecedor com o seu próprio contador de lookups. Para organizações com mais de 5 fornecedores, os subdomínios são recomendados.
Glossário
- DNS lookup: consulta DNS realizada durante a avaliação de um registo SPF para resolver um mecanismo como
include:oumx. - Permerror: erro permanente retornado quando um SPF é estruturalmente inválido, especialmente quando ultrapassa o limite de 10 lookups.
- SPF flattening: técnica que substitui os mecanismos SPF que necessitam de lookups pelos endereços IP diretos que eles resolvem.
- Void lookup: consulta DNS que não retorna nenhum resultado (NXDOMAIN ou resposta vazia). Limitado a 2 pela RFC 7208.
- RFC 7208: especificação oficial do protocolo SPF (Sender Policy Framework) que define as regras de avaliação e os limites de lookups.
Achate o seu registo SPF agora: use nosso SPF Flattener para resolver todos os seus includes em endereços IP diretos e respeitar o limite de 10 lookups.
📚 Guias de SPF relacionados
- SPF Flattening vs SPF Macros: qual abordagem escolher para respeitar o limite de 10 lookups?
- SPF PermError: entender, diagnosticar e corrigir


