PermError do SPF: Como Corrigir "Demasiadas Consultas de DNS" Sem Partir o Seu Email (2026)

Publicado 2026-07-08

Números a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios classificados. Veja como classificamos.

Pelo menos 797.263 domínios ultrapassam o limite de 10 consultas de DNS do SPF, segundo o censo do Defaults.Exposed de 261.086.232 domínios — de 139 milhões de publicadores de SPF. Depois de dez consultas, um recetor para e devolve PermError: o seu SPF fica nulo, e o DMARC conta um PermError como uma falha.

A correção tem uma ordem estrita, e a maioria dos guias troca-a. Conte as suas consultas reais e resolvidas; elimine includes mortos e não usados — isso sozinho corrige a maioria dos registos; mova remetentes em massa para subdomínios com o seu próprio orçamento de SPF; achate só como último recurso, e só com re-achatamento automatizado, porque o achatamento estático apodrece e quebra a entrega silenciosamente.

O que significa “PermError do SPF: demasiadas consultas de DNS”?

O RFC 7208 §4.6.4 limita cada verificação de SPF a 10 consultas de DNS. Depois de dez, o recetor para e devolve PermError — o registo inteiro é tratado como partido, não só a parte acima do orçamento. A mesma secção acrescenta um segundo teto menos conhecido: no máximo 2 “consultas vazias” (consultas que devolvem nenhuma resposta ou NXDOMAIN), portanto um par de entradas include: mortas para serviços cancelados podem, por si só, anular o seu SPF.

A consequência é pior do que “sem SPF nenhum”: o DMARC trata um PermError como uma falha de SPF, portanto um domínio que quebra o seu próprio SPF fica não autenticado na verificação de SPF de cada avaliação de DMARC. Se o DKIM não estiver configurado ou se quebrar em trânsito, esse correio agora falha o DMARC por completo.

Um número do censo mostra o quão cruel este modo de falha é: 112.215 domínios publicam um registo -all estrito que é nulo por causa do excesso de consultas — de entre os 54.655.923 domínios que publicam -all seja como for. Os seus donos fizeram a parte difícil — escolheram o final estrito — e um include a mais desligou o registo inteiro. Parecem estritos; estão partidos. Para o quadro completo dos dados, veja o relatório de PermError do SPF.

Porque é que o meu SPF se partiu sem eu ter mudado nada?

Porque o orçamento é maioritariamente gasto pelos registos de outras pessoas. Cada include: é avaliado recursivamente, e cada mecanismo de consulta dentro dele conta contra o seu dez. Uma linha no seu painel de DNS pode custar quatro ou cinco consultas depois de resolvida. Um fornecedor aninha mais um include, e o seu SPF morre sem uma única mudança na sua zona.

As grandes plataformas não são o problema: a Google e a Microsoft achataram ambas o seu próprio SPF — _spf.google.com e spf.protection.outlook.com expandem-se para listas de IP simples que custam zero consultas internas (verificado contra DNS ao vivo, julho de 2026). As explosões do mundo real vêm de cadeias de includes de painéis de alojamento aninhadas várias camadas de fundo, e de acumulação honesta de SaaS — caixa de correio mais newsletter mais CRM mais helpdesk, cada um “só mais um include”. Ninguém adiciona a décima primeira consulta de propósito; chega como a soma de decisões razoáveis. É por isso que o limite está tão cheio de gente: 2.119.539 domínios estão em exatamente 9–10 consultas resolvidas — cerca de 1 em 66 de todos os publicadores de SPF, bem hoje, nulos no dia em que alguém colar mais um include. O registo SPF do percentil 99 já resolve para 9 consultas. Se a sua pilha for pesada em SaaS, o guia do SPF a falhar para ferramentas SaaS cobre a versão fornecedor a fornecedor.

Que partes de um registo SPF contam como consultas de DNS?

Mecanismo	Custo de consulta	Nota
`include:`	1 + tudo o que está dentro dele, recursivamente	de onde vêm quase todas as explosões
`a`	1 cada	mesmo um `a` simples para o seu próprio domínio
`mx`	1 cada (mais as consultas A dos hosts MX)	frequentemente esquecido
`ptr`	1 — e obsoleto desde 2014	elimine-o de qualquer forma
`exists:`	1 cada	raro
`redirect=`	1 + o conteúdo do registo alvo	conta como um include
`ip4:` / `ip6:`	0	é por isso que o achatamento funciona
`-all` / `~all` / `?all`	0	o qualificador é grátis

Conte o total resolvido, não as linhas visíveis. Quatro includes podem ser quatro consultas ou catorze.

Como corrijo “demasiadas consultas de DNS” sem partir o email?

Execute a verificação gratuita antes de tocar no DNS. Resolve toda a sua cadeia de includes e mostra a sua contagem real de consultas, para corrigir o problema real — não o registo como aparece no seu painel. (Se disser que não tem SPF nenhum, é uma falha diferente — veja “SPF record not found”.)
Elimine primeiro includes mortos e não usados. A ferramenta que abandonou em 2023, o include do alojamento antigo que sobreviveu a uma migração, duplicados, qualquer mecanismo ptr. Os includes mortos são duplamente tóxicos: gastam orçamento de consultas e são normalmente a fonte de consultas vazias. A maioria dos registos acima do orçamento voltam a ficar abaixo de 10 só com este passo. Se o seu registo ainda tiver mecanismos de um fornecedor anterior, siga o guia de limpeza de migração.
Verifique se cada include restante está a fazer alguma coisa. Os recetores avaliam o SPF contra o domínio do Return-Path (RFC5321.MailFrom), não o cabeçalho From — e muitas ferramentas SaaS põem o seu próprio domínio de devolução no Return-Path, portanto o include delas no seu registo não faz nada exceto gastar orçamento. Mantenha includes só para serviços que usam o seu domínio como Return-Path; para o resto, ative o DKIM de domínio personalizado do fornecedor.
Mova remetentes em massa para subdomínios. Newsletters a partir de news.oseudominio.com, correio transacional a partir de mail.oseudominio.com. Cada subdomínio ganha o seu próprio registo SPF com um orçamento fresco de 10 consultas, e um problema num fluxo deixa de sangrar para os outros.
Só depois considere achatar — e só achatamento automatizado. Veja abaixo.
Volte a verificar para confirmar que está confortavelmente abaixo de 10 — procure margem, não exatamente 10, ou acabou de se juntar aos 2,1 milhões de domínios no limite. Depois percorra o resto que a verificação assinalar na página corrigir o SPF.

Devo achatar o meu registo SPF?

Achatar substitui includes pelos seus blocos ip4:/ip6: subjacentes, que custam zero consultas. Funciona — e feito à mão, é uma interrupção de entrega de ação retardada.

Abordagem	Contagem de consultas	Ao longo do tempo
Reduzir + subdomínios (passos 2–4)	Normalmente volta a ficar abaixo de 10	Estável; os fornecedores gerem os seus próprios IPs
Achatamento automatizado (um serviço ou tarefa agendada volta a resolver e a republicar)	Perto de 0	Acompanha as mudanças de IP do fornecedor; seguro
Achatamento manual pontual	Perto de 0 — hoje	Apodrece silenciosamente: os fornecedores rodam IPs, o correio legítimo começa a falhar o SPF sem erro nenhum do seu lado

Os fornecedores rodam os IPs de envio rotineiramente e não anunciam a ninguém. Uma lista estática de IP está correta no dia em que a cola e silenciosamente errada em meses — e como a falha aparece como outras pessoas a não receberem o seu correio, descobre tarde. Se reduzir e usar subdomínios o colocarem abaixo do limite, pare aí; nunca copie à mão os blocos de IP de terceiros para o seu registo como uma correção permanente.

Perguntas frequentes

Um PermError do SPF significa que o meu email deixa de ser entregue? Não instantaneamente — é isso que o torna perigoso. O DMARC conta um PermError como uma falha de SPF, portanto a entrega passa a depender inteiramente do DKIM; se o DKIM estiver em falta ou se quebrar em trânsito, está a falhar o DMARC. De 139 milhões de publicadores de SPF no nosso censo (a 2026-06-29), pelo menos 797.263 estão neste estado — a maioria sem saber.

O meu registo só tem quatro includes — como pode estar acima de 10 consultas? Os includes são contados recursivamente: tudo o que está dentro de cada include (e dentro dos seus includes) é cobrado ao seu orçamento, portanto quatro linhas visíveis podem resolver para catorze consultas. Conte com uma ferramenta que resolve, não a olho — resolver as cadeias foi como o nosso relatório de PermError encontrou cerca de 100× mais domínios partidos do que as contagens de superfície mostram.

Termino o meu registo com -all — certamente estou protegido? Só se o registo se avaliar. O nosso censo (a 2026-06-29) encontrou 112.215 domínios cujos registos -all estritos são nulos por excesso de consultas. Um qualificador estrito num registo com PermError não protege nada.

O limite é de 10 consultas por include ou para o registo inteiro? A avaliação inteira: o RFC 7208 §4.6.4 limita a verificação completa a 10, mais no máximo 2 consultas vazias. Cada subdomínio tem o seu próprio registo e orçamento — é por isso que o passo 4 funciona.

As entradas ip4 e ip6 contam para o limite? Não — os mecanismos de IP não custam nada, o que é exatamente porque o achatamento reduz a contagem.

Envie o relatório ao proprietário

Se está a corrigir isto para um cliente ou empregador, termine o trabalho com evidência. Volte a executar a verificação gratuita depois das suas mudanças e reencaminhe o relatório classificado ao dono do negócio: linguagem simples, datado, PermError desaparecido. É o artefacto de que vão precisar para a renovação do seguro cibernético e o próximo questionário de segurança de cliente — a diferença entre “mudei uns registos de DNS” e um antes-e-depois documentado.

Verifique o seu domínio gratuitamente

Veja a sua contagem real e resolvida de consultas — e tudo o resto do SPF, DKIM e DMARC — em privado e só para o proprietário.

Verifique o seu domínio → · Corrigir o SPF → · SPF a falhar para ferramentas SaaS → · Configurar SPF no GoDaddy → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.