Defaults.Exposed › Relatórios

Por que o meu SPF está a falhar? O problema dos 10 lookups para remetentes do Reino Unido e da UE com ferramentas SaaS (2026)

Publicado 2026-07-09

Valores a 2026-06-29 · metodologia v7. Dados agregados do censo de 261 milhões de domínios avaliados. Ver como avaliamos.

Quando o SPF falha numa empresa que utiliza ferramentas SaaS no Reino Unido ou na UE, a causa mais provável é uma única regra RFC que nunca foi preciso considerar: acima de 10 consultas DNS, o SPF não devolve “fail” — devolve PermError, o que significa que o registo é tratado como se não existisse. Pelo menos 797.263 domínios já cruzaram essa linha. Outros 2.119.539 encontram-se exatamente em 9–10 lookups — uma nova ferramenta basta para cair no mesmo precipício.

Por que é que o SPF falha quando se adiciona uma ferramenta SaaS?

O SPF funciona listando os servidores de correio autorizados a enviar em nome do seu domínio. As empresas modernas não gerem os seus próprios servidores de correio — usam o Google Workspace para email interno, o Mailchimp para campanhas, o HubSpot para sequências de vendas, o Pipedrive para o acompanhamento CRM. Cada plataforma fornece uma linha include: para inserir no DNS.

O problema: cada include: é em si mesmo uma consulta DNS. E cada registo dentro desse include pode desencadear mais lookups de forma recursiva. O RFC 7208 §4.6.4 estabelece um limite rígido de dez. A partir de dez, o servidor de correio recetor para a avaliação e devolve PermError — e um PermError não é uma falha suave que acaba no spam. Significa que o registo SPF é tratado como ausente. A autenticação do email falha na camada SPF.

Não verá isto no seu painel DNS. O contador só funciona durante a avaliação em tempo real. É possível ter três linhas include: no registo visível e ainda assim estar a doze lookups de profundidade, porque o registo SPF de cada fornecedor contém os seus próprios sub-includes.

Quantos domínios já ultrapassaram o limite?

Pelo menos 797.263. Esse é o total após termos resolvido cada destino SPF include: referenciado 100 ou mais vezes — 10.842 destinos distintos cobrindo 95,2% de todas as referências include — e calculado a cadeia completa de cada domínio. A contagem superficial (contando apenas as linhas visíveis num registo) encontra aproximadamente 7.958. O valor calculado por cadeia é 100 vezes maior, porque quase todo o dano é invisível dentro dos destinos include.

A situação que mais afeta uma empresa europeia:

Fornecedores de alojamento europeus e configurações SPF fracas

O fornecedor de alojamento inicial é importante — porque alguns definem predefinições SPF que já consomem vários dos dez lookups antes de ligar uma única ferramenta SaaS.

Entre os maiores fornecedores de alojamento utilizados por domínios europeus no nosso censo:

A IONOS destaca-se negativamente: apenas 1,0% dos domínios alojados na IONOS têm DMARC ativo, o que significa que a esmagadora maioria não tem qualquer autenticação de remetente significativa. Os domínios OVH saem-se melhor na configuração SPF estrito (43,7%), mas caem para 2,2% na aplicação DMARC — SPF sem DMARC para o ligar ao cabeçalho From: apenas protege o envelope, não o que o destinatário vê.

A Microsoft 365 é a exceção positiva: 85,0% dos domínios alojados na Microsoft utilizam SPF estrito, em grande parte porque o assistente de fluxo de correio da Microsoft define -all por predefinição. O Google Workspace define ~all (softfail) por predefinição, deixando 92% dos seus domínios sem proteção estrita.

Como diagnosticar a falha de SPF em menos de 60 segundos

A verificação mais rápida é uma ferramenta gratuita que avalia a cadeia completa de lookups — não apenas o registo visível. Execute nslookup -type=TXT seudominio.com na linha de comandos e conte cada include: que aparecer. Depois consulte cada um desses registos e conte os seus. Se ficar sem dedos antes de ficar sem includes, está na zona de perigo.

Uma abordagem mais fiável: verifique o seu domínio aqui — o scanner avalia a cadeia resolvida completa, assinala o PermError e mostra quais os mecanismos que estão a consumir o orçamento de lookups.

Três resultados de diagnóstico possíveis:

• PermError — já ultrapassou dez. Cada email enviado falha a verificação SPF no recetor.
• Em 9–10 lookups — está na beira do precipício. A próxima integração SaaS vai empurrá-lo para lá.
• Softfail (~all) em vez de hardfail (-all) — está abaixo do limite, mas o registo está configurado de forma demasiado permissiva para fornecer proteção real. Ver o relatório de configurações incorretas de SPF para o panorama completo sobre -all vs ~all.

Como corrigir o SPF quando se utilizam múltiplas ferramentas SaaS

Existem três abordagens, por ordem de permanência:

1. Auditar e podar. Comece por listar todos os include: no seu registo atual. Remova qualquer plataforma que já não utilize — antigos ESP, ferramentas CRM de contratos anteriores, plataformas que testou mas abandonou. É gratuito e recupera frequentemente vários lookups. Cada include: removido pode eliminar 1–3 sub-lookups.

2. Aplanar o registo SPF. O achatamento SPF resolve todos os destinos include: nas respetivas gamas de IP subjacentes e escreve-os diretamente no registo como mecanismos ip4: e ip6:. Os mecanismos IP não desencadeiam lookups, pelo que um registo achatado pode listar dezenas de fontes de envio e continuar com zero lookups. A desvantagem: é necessário re-aplanar sempre que um fornecedor atualiza os seus IPs de envio, o que acontece sem aviso. A maioria das organizações utiliza um serviço de achatamento gerido (PowerDMARC, EasyDMARC, Dmarcian, entre outros) ou cria um fluxo de monitorização.

3. Utilizar macros SPF. As macros RFC 7208 permitem construir registos que realizam uma única consulta DNS por verificação e respondem dinamicamente, em vez de uma cadeia de includes. As macros requerem suporte do alojamento DNS e algum esforço de implementação, mas são a solução arquitetonicamente limpa para organizações com muitos remetentes SaaS.

Após corrigir o SPF, complemente com a aplicação de DMARC — SPF sem DMARC apenas autentica o remetente do envelope, não o endereço From: do cabeçalho que os destinatários veem.

Perguntas frequentes

Por que é que o meu registo SPF passa no teste da minha ferramenta DNS mas falha nos cabeçalhos de email? A maioria das ferramentas de lookup DNS conta apenas os mecanismos visíveis no seu próprio registo, não os sub-lookups que esses mecanismos desencadeiam. Pode ter duas linhas include: e ainda assim estar acima do limite se o registo de cada fornecedor contiver mais vários. Apenas uma ferramenta de avaliação por cadeia (ou um servidor de correio recetor) conta a profundidade total. Verifique o seu domínio para ver a contagem real da cadeia.

O SPF a falhar significa que os meus emails vão para o spam? PermError (demasiados lookups) significa que a camada SPF da autenticação devolve um não-resultado — efetivamente ausente. O DMARC avalia tanto o SPF como o DKIM; se o DKIM passar, o DMARC pode ainda passar apesar do PermError do SPF. Se nenhum passar, o DMARC falha, e o resultado depende da sua política DMARC. Com p=none, o email é entregue na mesma, mas a falha fica registada. Com p=quarantine ou p=reject, o email é filtrado ou rejeitado. Corrija o SPF para não depender apenas do DKIM.

Quantos lookups consome uma pilha SaaS típica? O registo SPF no p99 do nosso censo já se situa em 9 lookups — mesmo no limite — antes de adicionar seja o que for. Um registo do Google Workspace adiciona 3–4 lookups; o Mailchimp adiciona 1–2; o HubSpot adiciona 1–3 dependendo da configuração atual. Três ferramentas comuns mais a predefinição do seu fornecedor de alojamento são frequentemente suficientes para ultrapassar dez.

O achatamento SPF é seguro? Sim, desde que seja mantido atualizado. O achatamento converte cadeias include: em gamas de IP estáticas — se um fornecedor rodar os seus IPs de envio e não re-aplanar, começará a rejeitar o seu correio. A maioria das organizações utiliza um serviço de achatamento gerido que monitoriza as alterações de IP em vez de o fazer manualmente.

O meu SPF está assim há anos — por que está de repente a falhar? Porque os seus fornecedores atualizaram os seus registos SPF, não o seu. Cada vez que uma plataforma SaaS adiciona um novo intervalo de IPs de envio ou aninha outro include, o custo da sua cadeia sobe sem qualquer alteração da sua parte. O limite de 10 lookups é avaliado em tempo real na receção da mensagem, pelo que uma alteração de fornecedor numa manhã de terça-feira pode quebrar o seu SPF até à tarde de terça-feira.

Corrigir o SPF melhora a capacidade de entrega de email? Remove uma fonte de falhas de autenticação, que é um pré-requisito para uma entrega consistente — particularmente desde que o Google e o Yahoo impõem agora o alinhamento DMARC para remetentes em massa. O SPF por si só não é o quadro completo: combine-o com DKIM e DMARC para uma autenticação de email completa.

Verifique o seu SPF gratuitamente

Se não tem a certeza se o seu registo SPF excede o limite de lookups — ou está configurado de forma demasiado fraca para proteger o seu domínio — faça uma verificação gratuita. Avalia a cadeia resolvida completa e mostra-lhe exatamente onde o orçamento está a ser gasto.

Verificar o seu domínio → · Corrigir SPF → · O relatório SPF PermError → · Relatório de configurações incorretas de SPF → · O modelo de maturidade de adoção de SPF → · Corrigir DMARC → · Apenas dados agregados. Dados armazenados e processados na UE.