Infraestrutura de e-mail
SPF: muitas consultas DNS, e a falha silenciosa que provoca.
O SPF é limitado a dez consultas DNS por verificação. Ao ultrapassar esse limite, o seu registro devolve PermError, que falha a autenticação de cada mensagem que você envia — em silêncio, sem retorno, visível só como e-mail sumindo e relatórios DMARC falhando. Os mecanismos que custam uma consulta são include, a, mx, ptr, exists e redirect; ip4, ip6 e all são grátis. A correção honesta raramente é uma ferramenta de flattening: pode os includes que você não usa, remova o ptr obsoleto e delegue o SPF a um subdomínio para que o seu registro raiz fique numa só consulta.
Em resumo
- O teto é 10 consultas, mais 2 void. Definido na RFC 7208 §4.6.4; ultrapasse qualquer um e você recebe PermError.
- PermError falha todo o seu e-mail, em silêncio. Não só o serviço extra — cada mensagem, sem retorno que avise.
- include, a, mx, ptr, exists, redirect custam consultas. ip4, ip6 e all são grátis.
- Um só registro SPF. Dois registros v=spf1 provocam PermError sem importar a contagem de consultas.
- A delegação ganha do flattening. Um subdomínio _spf delegado é estático; o flattening fica obsoleto quando os IPs do fornecedor mudam.
Por que o SPF quebra no momento em que você adiciona mais um serviço?
O Sender Policy Framework permite a um dono de domínio listar os servidores autorizados a enviar e-mail em seu nome, e um servidor receptor verifica essa lista antes de decidir como tratar uma mensagem. Para avaliá-la, o receptor resolve os mecanismos do seu registro via DNS — e a RFC 7208 §4.6.4 limita esse trabalho a 10 DNS-querying mechanism lookups, plus a separate cap of 2 void lookups, per check. O teto existe por uma razão sólida: sem ele, um registro malicioso poderia encadear referências para disparar centenas de consultas DNS e transformar cada receptor num amplificador de negação de serviço.
O problema é que o limite te alcança aos poucos. Um registro com três remetentes funciona à perfeição. Em alguns anos um time adiciona um CRM, um help desk, uma plataforma de marketing — cada um um include de aparência inocente — e um dia o sexto inclina a contagem acima de dez. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. A partir desse momento o registro é inválido, e o modo de falha é a parte cruel: Exceeding either limit returns PermError, which fails SPF for every message from the domain — silently. There is no bounce on the sending side; the only evidence is missing mail and failing DMARC reports.
Não é um caso raro. Um escaneamento de 5,5 milhões de domínios em 2026 encontrou que 4.8% of SPF-enabled domains exceed the 10-lookup limit — 148,655 of 3.1M scanned (DMARCguard SPF Supply Chain Study, 2026, 5.5M Tranco domains). Cada um desses domínios está enviando e-mail com autenticação quebrada agora mesmo, a maioria sem saber, porque nada nos próprios sistemas deles avisa. O dano à entregabilidade aparece primeiro como uma deriva lenta rumo às pastas de spam, semanas antes de alguém rastrear até o registro.
Qual a aparência de um registro passado do limite — e a correção?
Aqui está um registro que cresceu acima do limite como a maioria: uma pilha de includes acumulados com
o tempo, um mx, e um ptr obsoleto que ninguém lembra de ter adicionado.
Parece razoável, e está devolvendo PermError em silêncio.
# Antes — 11 consultas, falhando em silêncio com PermError
v=spf1 include:_spf.google.com # 3-4 consultas
include:sendgrid.net # 1
include:servers.mcsv.net # Mailchimp · 1
include:_spf.salesforce.com # 1
include:spf.protection.outlook.com # 2-3
a mx ptr # mais 3 — ptr está obsoleto
-all
A correção durável mantém o registro raiz numa só consulta delegando a lista real a um subdomínio,
enquanto poda o que não se usa, remove ptr e converte um remetente estático para um
ip4 direto. O registro delegado segue usando includes normais, então os seus fornecedores
conservam a capacidade de atualizar os próprios IPs.
# Depois — a raiz fica em UMA consulta por delegação de subdomínio
example.com. TXT "v=spf1 redirect=_spf.example.com"
# o registro delegado guarda a complexidade real, mantida num só lugar
_spf.example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net
ip4:198.51.100.10 -all"
# ptr removido · remetente estático trocado por ip4 · includes sem uso podadosContar consultas
Quais mecanismos custam uma consulta DNS?
Todo o problema se reduz a quais mecanismos consultam DNS e quais não. Domine esta tabela e você poderá contar o seu próprio registro à mão.
| Mecanismo | O que faz | Consulta? |
|---|---|---|
| include | Custa ≥1 consulta e resolve o próprio registro SPF do destino, cujos includes aninhados também contam. O mecanismo mais comum — cerca de um terço de todos os mecanismos SPF em produção. | Conta |
| a | Resolve os registros A/AAAA do domínio. | Conta |
| mx | Uma consulta, mais uma por cada host MX devolvido — pode sair surpreendentemente caro. | Conta |
| ptr | DNS reverso por cada IP que conecta, lento e pouco confiável. A RFC 7208 o desaconselha — remova-o. | Conta (obsoleto) |
| exists / redirect | Cada um resolve o registro SPF de um domínio; uma consulta cada. | Conta |
| ip4 / ip6 / all | Correspondências literais — sem consulta DNS alguma. Use-os para substituir mecanismos caros em remetentes estáticos. | Isento |
O hábito mais útil é contar antes de adicionar. Antes de parafusar um novo include ao seu registro, verifique o total atual com um analisador SPF — porque os includes aninhados dentro do próprio registro de um fornecedor podem mudar sem aviso, um registro que estava em oito consultas mês passado pode estar em onze hoje sem uma única edição sua. Há ainda um segundo teto, mais calado: a RFC 7208 §4.6.4 limita as void lookups — consultas que não devolvem nada — a duas, e um único serviço desativado cujo include agora resolve para um registro vazio pode dispará-lo por si só.
A correção
Corrigi-lo, do mais rápido ao mais sustentável
Percorra a lista em ordem. Os primeiros passos são vitórias rápidas; os últimos são as correções estruturais que impedem o problema de voltar.
- 1
Confirme que de fato é um PermError
Passe o seu domínio por um verificador SPF como o MXToolbox; ele conta os includes aninhados e sinaliza «muitas consultas DNS». Cruze enviando um teste ao Gmail, abrindo Mostrar original e procurando spf=permerror, e lendo os seus relatórios DMARC, onde o resultado SPF mostra permerror para cada remetente e não só para um.
- 2
Pode os includes de serviços que você não usa mais
Esta é a correção mais limpa e segura. Revise cada mecanismo include, a e mx; se o serviço não envia mais por você, apague-o. Isso também limpa o PermError por void lookup que um serviço desativado provoca quando o seu include agora resolve para nada.
- 3
Substitua remetentes estáticos por ip4 / ip6 direto
Para qualquer remetente num IP fixo — normalmente o seu próprio servidor de e-mail — troque o mecanismo include ou a pelo IP em si, que não custa consulta. A contrapartida é que você assume a responsabilidade por esse IP, já que o fornecedor não pode mais atualizá-lo por você.
- 4
Remova o mecanismo ptr obsoleto
Se ptr aparece em qualquer parte do seu registro, remova-o. Ele faz uma consulta DNS reversa por cada IP que conecta, que é lenta e pouco confiável, e a especificação o desaconselha. Substitua-o por referências IP diretas onde você ainda precisa autorizar esses hosts.
- 5
Delegue o SPF a um subdomínio
Para o longo prazo, aponte o seu registro raiz a um subdomínio _spf delegado com redirect, para que a raiz fique numa só consulta enquanto o registro delegado leva a complexidade real num único lugar mantido. Isso é estático uma vez configurado e é a correção mais confiável para um domínio com muitos remetentes.
- 6
Trate o flattening como último recurso
Só se a delegação não for viável, resolva os includes para IPs em bruto dentro do registro. Como os IPs dos fornecedores mudam, um registro achatado fica obsoleto e quebra em silêncio a menos que você automatize o re-achatamento periódico e o monitoramento — que é justo a carga de manutenção que a delegação evita.
A delegação de subdomínio é mais confiável que o flattening para quase todos os casos; o flattening é um paliativo quando a delegação não é viável. Muitos times que pagam uma ferramenta de flattening descobrem que não precisam mais dela uma vez que podam e delegam.
O include obsoleto que quebra um registro por si só
Nem todo PermError vem do volume puro. O segundo teto — duas void lookups — pega uma falha diferente e mais traiçoeira: um include que aponta para um domínio que não tem mais registro SPF, então a consulta não devolve nada. Uma void lookup é uma consulta DNS que volta vazia ou com um NXDOMAIN, e a maioria dos receptores devolve PermError no momento em que um registro passa de duas. O culpado habitual é um único serviço desativado cujo include simplesmente nunca foi removido.
Há um exemplo bem documentado de exatamente isto. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it. A lição é que um registro pode estar confortavelmente abaixo de dez consultas contadas e ainda assim dar PermError, porque um include morto não é só orçamento desperdiçado — é uma void lookup ativa. Quando você migra para fora de qualquer serviço de e-mail, remover o include dele é parte da migração, não uma limpeza opcional para depois.
Por isso a correção mais limpa é também a primeira da lista. Podar não é vistoso e não há ferramenta a vender para isso, mas percorrer cada mecanismo include, a e mx e apagar os que não enviam mais por você elimina os dois tipos de falha de uma vez: recupera orçamento de consulta e limpa as void lookups que um include obsoleto deixa para trás. A maioria dos registros passados do limite tem ao menos um serviço esquecido dentro, e alguns se corrigem só com esse passo.
Por que o orçamento de consultas se esgota ao crescer
A razão estrutural por trás de quase cada registro passado do limite é a mesma: o SPF foi desenhado quando a maioria das organizações enviava e-mail de um ou dois lugares, e o stack moderno envia de uma dúzia. Cada nova ferramenta SaaS que envia e-mail em seu nome — um CRM, um help desk, uma plataforma de marketing, um sistema de cobrança, uma ferramenta de pesquisa — quer o seu próprio include, e os includes se aninham. Google Workspace alone consumes 3–4 lookups; a few more services and you hit the cap. O orçamento que parecia generoso com três remetentes sumiu quando você chega ao sétimo, e nada no processo te avisa ao cruzar a linha.
Os dados confirmam o quão mecânico isto é. O mecanismo mais comum nos registros SPF é o include, e é justo o que custa consultas e se aninha de forma imprevisível, porque o próprio registro do fornecedor pode crescer sem te dizer. AutoSPF (Apr 2026) attributed 41% of SPF failures across a sample of fast-growing domains to exceeding the 10-lookup limit. O padrão é consistente: quantos mais serviços de terceiros uma organização adota, mais rápido esgota o seu orçamento de consultas, e os times que alcançam o limite costumam ser os que crescem mais rápido e adicionam ferramentas com mais agressividade.
Esse enquadramento aponta direto à correção durável. Se o problema é que os includes se acumulam e se aninham além da sua visibilidade, a resposta não é congelar a sua infraestrutura de envio nem fixar à mão um instantâneo de IPs que vai derivar — é pôr toda essa complexidade atrás de um único registro delegado que você controla, para que a raiz fique numa consulta sem importar quantos serviços haja atrás. Crescer deixa de ser uma contagem regressiva para o PermError e passa a ser uma edição num só lugar mantido.
PermError não é a mesma coisa que uma falha de SPF
Vale ser preciso com o erro, porque os dois resultados pedem respostas completamente distintas. PermError is not the same as an SPF fail. Fail means the record was evaluated and the IP did not match; PermError means the record itself is broken (too many lookups, a syntax error, multiple records, or unresolvable/circular includes) and could not be evaluated at all. Uma falha é um resultado normal e saudável — é o SPF fazendo o seu trabalho, dizendo ao receptor que um IP específico não estava na sua lista. Um PermError é o registro em si sendo ilegível, o que significa que o SPF não dá ao receptor nenhuma resposta utilizável para nada do seu e-mail.
O efeito em cadeia alcança o DMARC. DMARC interprets an SPF PermError as a fail, so if SPF is your only alignment path, a PermError quietly weakens DMARC too. Um time que moveu com cuidado o DMARC rumo à aplicação pode descobrir que um único registro SPF passado do limite tira o chão em silêncio, porque o alinhamento com o qual contava agora resolve para PermError em cada mensagem. Corrigir a contagem de consultas não é portanto só um reparo de SPF; muitas vezes é a peça que falta para uma política DMARC se sustentar de fato.
Há mais uma má configuração que vale descartar enquanto você está no registro, porque produz o mesmo
PermError por outra via. RFC 7208 requires exactly one SPF (v=spf1) TXT record per domain. Two records cause PermError for all mail, regardless of lookup count — a very common misconfiguration. Se você está depurando e não sabe se a culpa é das
consultas ou de um registro duplicado, conte primeiro as consultas; se a contagem está confortavelmente
abaixo de dez e você ainda vê PermError, procure essa segunda entrada TXT v=spf1 perdida.
A correção honesta
Flattening versus delegação, sem rodeios
Ambos cortam a contagem de consultas. Só um fica corrigido.
Os resultados de busca dominados por fornecedores em torno deste tema empurram o flattening com força,
muitas vezes como serviço pago, porque é a correção que precisa de uma ferramenta. Diremos o menos
lucrativo: a maioria dos domínios não precisa de uma assinatura de flattening. Pode os includes que você
parou de usar, remova ptr, converta os seus próprios servidores estáticos para
ip4 e, se você ainda tem complexidade genuína, delegue-a a um subdomínio. Recorra ao
flattening só quando a delegação de fato não for opção, e se você o fizer, monte a automação que evita
que ele apodreça em silêncio.
Onde nós estamos
Hospedamos infraestrutura de envio, então vemos registros SPF passados do limite constantemente — são, na nossa experiência e nos dados publicados, a falha de SPF mais comum. O conselho honesto nos custa um produto que poderíamos vender: a maioria dos times que chegam com um PermError não precisa de um serviço de flattening, precisa de uma tarde de poda e uma delegação de subdomínio, após a qual o registro fica corrigido sozinho. Trend Micro KB KA-0017579: after migrating off Hosted Email Security, customers who left include:spf.hes.trendmicro.com in their record hit a void-lookup PermError because the stale include resolved empty. Removing the one dead include fixed it.
Se você gerencia o e-mail conosco, manter o seu SPF dentro do limite é parte da configuração, e vamos
desenhar a delegação para que ela fique estática à medida que você adiciona e remove remetentes. Se você
auto-hospeda ou envia por um ESP, a mesma sequência se aplica seja quem for que opere os servidores:
confirme o PermError, pode, remova ptr, converta remetentes estáticos para IPs diretos e
delegue o resto. Conte antes de adicionar, e o limite deixa de ser uma armadilha.
Perguntas
Respondidas com clareza
As perguntas que os times fazem quando o SPF começa a falhar sem razão óbvia.
O que é exatamente o limite de 10 consultas do SPF?
A avaliação do SPF é limitada a dez consultas DNS de mecanismos por verificação, mais um teto à parte de duas void lookups, definido na RFC 7208 §4.6.4. Os mecanismos que resolvem um nome — include, a, mx, ptr, exists e redirect — custam cada um ao menos uma consulta, e os includes aninhados contam contra o mesmo orçamento. Os mecanismos literais (ip4, ip6, all) não custam nada. O limite existe por segurança e desempenho: sem ele, um registro malicioso poderia disparar centenas de consultas DNS e transformar os receptores num vetor de negação de serviço.
O que acontece de fato quando eu ultrapasso?
O seu registro devolve PermError, e o SPF falha para cada mensagem que você envia — não só o e-mail do serviço extra, todo ele. O pior é que é silencioso: não há retorno do seu lado, então a única evidência é e-mail sumindo e relatórios DMARC mostrando permerror. Um registro que funcionava bem com três remetentes quebra no dia em que você adiciona o sexto, e a entregabilidade pode degradar por semanas antes de alguém relacionar com a mudança no SPF.
PermError é a mesma coisa que uma falha de SPF?
Não, e a distinção importa. Uma falha de SPF significa que o registro foi avaliado corretamente e o IP de envio simplesmente não estava autorizado. Um PermError significa que o registro em si não pôde ser avaliado de jeito nenhum — consultas demais, um erro de sintaxe, mais de um registro SPF, ou um include irresolúvel ou circular. Como o DMARC trata um PermError como uma falha, um registro quebrado também mina em silêncio o alinhamento do DMARC se o SPF é a via na qual você se apoia.
Devo usar uma ferramenta de flattening de SPF?
Normalmente não como primeiro movimento, e muitas vezes de jeito nenhum. O flattening substitui os includes pelos seus IPs resolvidos, o que de fato corta a contagem de consultas, mas esses IPs ficam obsoletos no momento em que um fornecedor muda a infraestrutura de envio — e os grandes fornecedores mudam os seus intervalos com regularidade. Um registro achatado precisa portanto de re-achatamento e monitoramento automatizados ou quebra em silêncio. A maioria dos times que poda os includes sem uso e delega a um subdomínio descobre que não precisa mais da ferramenta paga que estava considerando.
Por que a delegação de subdomínio é melhor que o flattening?
Porque é estática uma vez configurada, sem dependência de uma ferramenta de terceiros que reresolva IPs. Você aponta o seu registro raiz a um subdomínio _spf delegado, a raiz fica numa só consulta, e o registro delegado leva a complexidade real — mas segue usando includes normais, então os fornecedores conservam a capacidade de atualizar os próprios IPs. O flattening corrige o sintoma (a contagem de consultas) enquanto assume a fragilidade de fundo dos IPs fixados à mão; a delegação corrige a estrutura e deixa os fornecedores no comando dos próprios intervalos.
Posso simplesmente ter dois registros SPF para caber tudo?
Não — isso piora. A RFC 7208 exige exatamente um registro TXT v=spf1 por domínio, e publicar dois provoca um PermError para todo o seu e-mail sem importar quantas consultas cada um contém. É uma das más configurações de SPF mais comuns. Una cada remetente autorizado num único registro, e se esse registro for longo demais para uma string DNS, o seu provedor de DNS deve dividi-lo em várias strings dentro do mesmo registro — que é diferente de ter vários registros.
SPF falhando sem razão óbvia?
Conte o seu domínio de envio e vamos contar as suas consultas, encontrar o PermError e desenhar uma delegação que fique sob o limite à medida que você cresce — sem assinatura de flattening.