Defaults.Exposed › Relatórios
O Relatório SPF PermError: 100× Mais Domínios Ultrapassam o Limite de 10 Consultas do Que as Contagens de Superfície Mostram (2026)
Publicado 2026-07-03
Valores de 2026-06-29 · metodologia v7, mais uma passagem de tarifação de cadeias executada em 2026-07-03. A partir do censo de 261 milhões de domínios classificados, resolvemos cada alvo de SPF
include:referenciado 100 ou mais vezes — 10.842 alvos que cobrem 95,2% de todas as referências de include — e tarifámos a cadeia retida de cada domínio face a esse mapa. Os alvos de cauda não resolvidos contaram como zero e o conteúdo das cadeias reflete o dia da resolução, pelo que o número em destaque é uma aproximação conservadora e enviesada para o mínimo: dizemos “pelo menos”. Apenas agregado; nunca o registo de uma empresa individual. Veja como classificamos.
Quantos domínios ultrapassam o limite de 10 consultas do SPF?
Pelo menos 797.263 — porque o SPF tem um mecanismo de autodestruição incorporado na norma, e o gatilho esconde-se onde os proprietários não conseguem vê-lo. A RFC 7208 §4.6.4 limita uma verificação SPF a 10 consultas de DNS; passadas as dez, o recetor para e devolve PermError, e um registo em PermError não protege nada. Conte apenas as consultas visíveis no próprio registo — como faz a maioria das ferramentas, e como o nosso próprio censo fazia até este relatório — e encontrará cerca de 8.000 infratores (7.958, para ser exato). Tarife as cadeias de include: que esses registos realmente puxam, e a contagem atinge 797.263: cerca de 100 vezes maior.
Porque é que os proprietários não conseguem antecipá-lo?
Porque o orçamento é gasto pelos registos de outras pessoas. include:onetool.example.com aparece como uma linha no seu painel de DNS — mas o recetor também tem de ir buscar esse registo, e contar cada mecanismo de consulta que ele contém, recursivamente. Um registo com três includes pode custar onze. Nada na sua própria zona mudou no dia em que ultrapassou o limite; um fornecedor aninhou mais um include, e o seu SPF morreu sem aviso.
Pior ainda, o DMARC trata um PermError como falha na perna do SPF — pelo que um domínio que quebrou o seu SPF desta forma está agora a falhar metade da sua própria autenticação.
O que a tarifação de cadeias encontrou
| Descoberta | Domínios |
|---|---|
| Acima do limite de 10 consultas, cadeias tarifadas | 797.263 |
| Acima do limite contando apenas mecanismos visíveis | 7.958 |
Acima do limite enquanto terminam em -all estrito | 112.215 |
| Exatamente em 9–10 consultas — à beira do precipício | 2.119.539 |
Duas histórias nessa tabela — a terceira, a beira do precipício, tem a sua própria secção mais abaixo:
- As contagens de superfície falham ~99% da quebra. A contagem por mecanismos visíveis encontra 7.958; tarifar as cadeias encontra 797.263. Quase todo o dano é herdado daquilo que os includes incluem.
- 112.215 dos registos quebrados terminam em
-all. Os seus proprietários fizeram tudo certo — escalaram o muro, escolheram o final estrito — e um include a mais anulou tudo. Parecer estrito e estar quebrado é o modo de falha mais cruel na segurança de email.
2,1 milhões de domínios estão a uma ferramenta de distância do precipício
O número que deveria preocupar os leitores que estão atualmente bem: 2.119.539 domínios resolvem para exatamente 9 ou 10 consultas — abaixo do limite hoje, mortos no dia em que alguém ligar mais uma plataforma. Isso é cerca de 1 em cada 66 de todos os publicadores de SPF, e corresponde à forma da distribuição: o registo SPF no percentil 99 já se situa em 9 consultas. Inscreva-se em mais uma ferramenta de marketing, cole a sua linha de “basta adicionar este include”, e um registo que estava abaixo do limite ao pequeno-almoço fica anulado ao almoço.
De quem é a culpa? Cada vez mais, é da stack
Os maiores fornecedores aplanaram discretamente o seu SPF — o _spf.google.com da Google e o spf.protection.outlook.com da Microsoft agora expandem para listas simples de IP com custo zero de consultas internas (verificámos ambos face ao DNS ao vivo durante esta análise). Os rebentamentos vêm de outro lado: cadeias de painéis de alojamento que aninham três níveis, fornecedores regionais cujo include custa 7–10 consultas só por si, e a acumulação honesta de SaaS — caixa de correio mais newsletter mais CRM mais helpdesk, cada um “só um include”. Quase ninguém adiciona a décima primeira consulta de propósito. Ela chega como a soma de decisões razoáveis.
Como verificar e corrigir o seu — grátis
- Conte o seu total real — a nossa verificação gratuita resolve a sua cadeia, ou use qualquer contador de consultas de SPF.
- Elimine o peso morto: ferramentas que deixou de usar, includes duplicados, e o mecanismo
ptrobsoleto. - Aplane apenas aquilo que controla. Substituir um include profundo pelos seus blocos de IP funciona para a sua própria infraestrutura; os IP de terceiros mudam sem aviso.
- Dê aos remetentes em massa um subdomínio. As newsletters de
news.yourdomain.comobtêm o seu próprio registo e o seu próprio orçamento de 10 consultas.
Perguntas frequentes
O que é o limite de 10 consultas de DNS do SPF?
A RFC 7208 §4.6.4 permite no máximo 10 consultas de DNS para avaliar um registo SPF — contando as consultas dentro de cada include: recursivamente. Excedê-lo devolve PermError: o registo é tratado como inválido e não oferece qualquer proteção.
O que significa SPF PermError? Um erro de avaliação permanente — o recetor não conseguiu processar o seu registo (demasiadas consultas, múltiplos registos, ou sintaxe quebrada) e trata o seu domínio como não tendo SPF utilizável. O DMARC conta-o como falha na perna do SPF.
Quantos domínios excedem o limite de consultas do SPF? Pelo menos 797.263 de 139 milhões de publicadores de SPF, segundo a nossa passagem de tarifação de cadeias — cerca de 100× os 7.958 visíveis sem resolver as cadeias. Outros 2.119.539 situam-se em 9–10 consultas, a um include do limite.
Um PermError impede que o meu email seja entregue? Normalmente não — os recetores prosseguem sem SPF, e o seu correio segue apoiado no DKIM e na reputação. O que deixa de funcionar é a proteção: os falsificadores já não são rejeitados, e cada verificação DMARC do seu correio perde a sua perna de SPF. É invisível até se tornar caro.
Como reduzo a minha contagem de consultas de SPF?
Remova includes não utilizados e o ptr, aplane a sua própria infraestrutura para ip4:/ip6:, mova os remetentes em massa para subdomínios, e volte a contar após cada nova ferramenta. O guia de correção acompanha-o passo a passo.
Descubra o seu número real
Os mecanismos que consegue ver não são a sua contagem de consultas — o número resolvido é aquele que os recetores calculam, e é uma verificação de 30 segundos.
Verifique o seu domínio → · Corrigir SPF → · O modelo de maturidade do SPF → · Dois registos SPF = nenhum → · A armadilha do ptr → · Apenas dados agregados. Dados armazenados e processados na UE.