"SPF Record Not Found" — Mas Você Tem Um? As 5 Causas Reais (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.

Se um verificador diz “SPF record not found” mas tem a certeza de que publicou um, o registo normalmente está invisível em vez de em falta: 1.013.416 domínios — cerca de um em 138 dos que tentam SPF — publicam dois ou mais registos SPF, um PermError (RFC 7208 §3.2) que muitos verificadores reportam como não encontrado, segundo o censo do Defaults.Exposed de 261 milhões de domínios.

Há cinco causas reais, todas corrigíveis numa sessão: host errado, registo duplicado, tipo de DNS errado ou aspas estropiadas, nameservers inconsistentes, ou um conflito de comprimento/CNAME. Abaixo: o teste de 60 segundos para cada uma, pela ordem em que verificar, depois os passos de correção.

Tem a certeza de que o registo realmente existe?

Comece pela possibilidade menos lisonjeira, porque é de longe a mais comum: dos 261.086.232 domínios classificados no censo do Defaults.Exposed, 121.145.609 — 46,4% — não têm registo SPF nenhum. Muitos casos de “mas eu configurei isto” acabam por ser um registo adicionado a uma zona de teste ou a um fornecedor de DNS antigo que já não é autoritativo. Verifique o fornecedor de DNS para o qual os seus nameservers realmente apontam (muitas vezes não o seu registrador) à procura de um registo TXT começando por v=spf1. Se genuinamente não estiver lá, salte o trabalho de detetive e vá diretamente a corrigir o seu registo SPF.

Como se verifica um registo SPF corretamente?

Os verificadores web consultam o DNS através do seu próprio resolvedor de cache. Para ver a verdade, pergunte diretamente ao nameserver autoritativo do seu domínio:

# encontre os nameservers autoritativos
dig NS oseudominio.com +short

# pergunte diretamente a um deles pelos registos TXT
dig TXT oseudominio.com @ns1.oseufornecedordns.com +short

No Windows: nslookup -type=TXT oseudominio.com ns1.oseufornecedordns.com.

Duas regras de interpretação. Primeiro, conte as linhas que começam por v=spf1 — a contagem importa tanto quanto o conteúdo. Segundo, verifique que consultou o nome certo: os recetores avaliam o SPF contra o domínio no Return-Path (RFC5321.MailFrom, o “envelope from”) — não o endereço From que os destinatários veem. Se a sua ferramenta de newsletter devolve correio via bounce.oseudominio.com, um registo perfeito no ápice não é o registo que os recetores consultam.

Quais são as cinco causas reais?

#	Causa	O teste de 60 segundos	A correção
1	Registo no host errado (subdomínio vs. ápice)	`dig TXT` no domínio exato do seu Return-Path	Publique no nome que realmente envia
2	Dois ou mais registos `v=spf1` = PermError	`dig TXT` devolve 2+ linhas `v=spf1`	Junte em exatamente um registo
3	Publicado como tipo de registo 99, ou aspas estropiadas	Verifique o tipo do registo e marcas de aspas estranhas	Republique como um único registo TXT limpo
4	Caches obsoletas / nameservers inconsistentes	Consulte cada NS diretamente; compare as respostas	Corrija o nameserver atrasado, espere o TTL antigo passar
5	Divisão acima de 255 carateres ou um conflito de CNAME	Procure blocos de string partidos ou um CNAME no mesmo nome	Deixe o fornecedor dividir as strings corretamente; mova o registo para fora do nome com CNAME

Dados a 2026-06-29.

1. O registo está no host errado?

O clássico: SPF adicionado em mail.oseudominio.com quando o correio reclama vir de oseudominio.com, ou vice-versa. O SPF não herda para baixo — um registo no ápice não diz nada sobre subdomínios, e vice-versa. Publique exatamente no nome que está no seu Return-Path. Um fornecedor que envia a partir do seu próprio subdomínio de devolução precisa de um registo nesse subdomínio — normalmente um CNAME ou TXT que o fornecedor fornece (o guia de configuração de SPF do GoDaddy mostra onde vivem estes campos).

2. Tem dois registos SPF?

A causa principal, e a mensagem de erro mais enganadora na autenticação de email. O RFC 7208 §3.2 é direto: um domínio tem de ter exatamente um registo SPF. Dois ou mais é um PermError — os recetores tratam o seu SPF como nulo. Alguns verificadores reportam esse estado com precisão (“multiple records found”); outros reportam o efeito líquido: no valid SPF record found. Vê um registo no seu painel e conclui que o verificador está avariado. Não está — tem um registo a mais.

O censo encontrou 1.013.416 domínios com dois ou mais registos SPF — cerca de um em 138 dos domínios que tentam SPF — todos com o SPF efetivamente desligado. Normalmente acontece durante uma mudança de fornecedor: o assistente do novo fornecedor adiciona um registo novo em vez de editar o antigo. A correção é uma junção, nunca um segundo registo: combine tudo numa única linha v=spf1 … ~all e elimine o resto. O nosso relatório de dados dois registos SPF equivalem a nenhum detalha como um milhão de domínios chegou aqui; se começou depois de uma migração, veja o SPF deixou de funcionar depois de mudar de fornecedor. Ao juntar, não concatene cegamente todos os include: — cada um custa consultas de DNS contra o limite rígido de 10 do SPF, trocando não-encontrado por um PermError: demasiadas consultas de DNS.

3. Publicou o tipo de registo errado — ou a interface estropiou-o?

O SPF antigo tinha o seu próprio tipo de registo DNS (tipo 99, literalmente chamado “SPF”). Foi descontinuado: o RFC 7208 exige TXT, e os recetores não consultam o tipo 99. Alguns painéis de DNS ainda oferecem “SPF” na lista de tipo de registo; escolha-o e o seu registo fica real, bem formado, e invisível. Verifique a coluna do tipo e republique como TXT.

A irmã mais subtil é a das aspas. Colar um valor já envolto em aspas num campo que adiciona as suas próprias aspas produz ""v=spf1 …"" — que já não começa por v=spf1, portanto para um verificador não existe. O resultado do seu dig mostra a verdade; o painel de DNS muitas vezes esconde-a cosmeticamente.

4. Está mesmo “ainda a propagar”?

“Dê 24–48 horas para propagar” é o conselho mais sobre-prescrito em DNS. A propagação é apenas caches a expirar: assim que o TTL do registo tiver passado (tipicamente 1 hora, raramente mais de 24), todos os resolvedores conseguem ver a resposta nova. Ainda não encontrado depois de 24 horas? A propagação não é a causa.

Os dois culpados reais: cache negativa — um resolvedor que o consultou antes de adicionar o registo guarda em cache a resposta “no such record” até o TTL negativo expirar — e nameservers inconsistentes depois de uma migração, onde o domínio ainda lista os nameservers do fornecedor antigo ao lado dos novos e metade do mundo lê uma zona que já não edita. Consulte cada nameserver listado diretamente; se as respostas diferirem, encontrou-o. Corrija a delegação de NS no registrador para que só o fornecedor que realmente edita seja autoritativo.

5. O registo é demasiado longo, ou está bloqueado por um CNAME?

Uma única string num registo TXT tem um máximo de 255 carateres. Registos SPF mais longos são legais mas têm de ser divididos em várias strings entre aspas dentro de um registo — e as interfaces de fornecedores de DNS regularmente estragam a divisão, truncando o valor ou partindo-o a meio de um mecanismo, deixando de se poder interpretar. Se o seu registo for longo, verifique o resultado do dig à procura de um valor que termine abruptamente.

Em separado, o DNS proíbe um registo TXT num nome que já tenha um CNAME. Se mail.oseudominio.com for um CNAME para o seu fornecedor, não pode também pôr lá o SPF — alguns painéis aceitam-no e depois servem só o CNAME. Ponha o registo onde o CNAME aponta (se o controlar), ou reestruture para que o nome de envio não tenha CNAME. Fornecedores com tratamento limpo de TXT tornam ambos mais fáceis — veja o guia de configuração de SPF do Cloudflare.

Como se corrige isto, passo a passo?

Execute a verificação gratuita em defaults.exposed — lê o seu DNS real e diz-lhe em qual dos cinco estados está antes de tocar em nada.
Confirme que nameservers são autoritativos (dig NS) e que todos concordam.
Consulte TXT no nameserver autoritativo para o domínio exato do Return-Path.
Conte as linhas v=spf1: zero → publique uma; duas ou mais → junte em uma.
Verifique que o tipo é TXT, o valor começa exatamente por v=spf1, e que não se infiltraram aspas estranhas ou truncamento.
Espere um TTL, depois volte a verificar para confirmar que resolve de forma limpa em todo o lado.

Perguntas frequentes

Porque é que o verificador diz “not found” quando vejo o registo no meu painel de DNS? Normalmente causa 2 ou 4: um segundo registo v=spf1 torna ambos nulos — um PermError que algumas ferramentas reportam como não encontrado, o estado em que 1.013.416 domínios estão a 2026-06-29 — ou o seu painel não é o DNS que é realmente autoritativo.

Quanto tempo até os verificadores verem a minha correção? Um TTL — tipicamente uma hora, no máximo 24. Além disso, “propagação” não é a explicação; volte a verificar as cinco causas, começando pela consistência dos nameservers.

Devo usar o tipo de registo “SPF” que o meu painel de DNS oferece? Não. O tipo 99 está descontinuado; o RFC 7208 exige apenas TXT. Um registo de tipo 99 é invisível para os recetores modernos.

O registo agora é encontrado — porque é que o meu correio ainda falha o SPF? Porque o SPF é verificado contra o domínio do Return-Path, não o cabeçalho From, e o registo tem de listar mesmo os servidores que enviam por si. Encontrado é o passo um; o guia corrigir o seu registo SPF cobre o passar.

Não ter registo SPF é realmente assim tão comum? Sim — 121.145.609 domínios, 46,4% dos 261.086.232 classificados no censo do Defaults.Exposed (a 2026-06-29), não publicam SPF nenhum. Não-encontrado é o estado predefinido da internet.

Envie o relatório ao proprietário

Assim que o registo resolver de forma limpa, volte a executar a verificação e reencaminhe o relatório classificado ao dono do negócio ou cliente cujo domínio é este. Mostra, em linguagem simples, o que estava partido, o que corrigiu, e onde o domínio está agora — exatamente a evidência que lhes será pedida em renovações de seguro cibernético e questionários de segurança de fornecedores. O relatório é o recibo do trabalho.

Verifique o seu registo SPF gratuitamente

Veja em qual dos cinco estados de não-encontrado o seu domínio está — em privado e só para o proprietário.

Verifique o seu domínio → · Corrigir o SPF → · O SPF avariou-se depois de mudar de fornecedor → · Como classificamos → · Apenas dados agregados. Dados armazenados e processados na UE.