Registro SPF não encontrado: por que acontece e como corrigir

Um verificador diz «no SPF record found», ou o cabeçalho de uma mensagem mostra spf=none. Os dois avisos significam a mesma coisa: o resolvedor pediu os registros TXT de um nome específico e nenhum começava com v=spf1. Não há nada de errado com o seu servidor de e-mail. A pergunta é por que a resposta veio vazia, e quase sempre se resume a ter consultado, ou publicado, no nome errado.

Este artigo é o caminho de diagnóstico para essa resposta vazia. Se o seu problema é um registro que existe mas falha, veja em vez disso os artigos sobre consultas DNS demais e o limite de 10 consultas.

O que «não encontrado» realmente significa

O SPF fica em um registro TXT comum. Um receptor pega o domínio da mensagem (normalmente o remetente do envelope, também chamado de endereço de retorno ou Return-Path), solicita seus registros TXT e mantém apenas aqueles cujo texto começa com v=spf1. Se essa lista filtrada estiver vazia, o resultado é none. Não é um erro de sintaxe; é a ausência de uma política.

Isso é diferente das outras duas situações com as quais as pessoas o confundem. Cada uma tem seu próprio resultado e sua própria correção.

Causa 1: o registro está no nome errado

O SPF é consultado no domínio usado no e-mail e em nenhum outro lugar. Ele não é herdado de um domínio superior nem procurado em www. Um registro publicado em www.example.com não adianta nada para e-mails enviados de @example.com, e um registro em example.com não adianta nada para e-mails enviados de @news.example.com.

O erro clássico acontece nos painéis de DNS. Para um registro no apex (o domínio sem subdomínio), o campo de host costuma ser @, embora alguns painéis peçam o campo em branco ou o domínio completo. Leia o texto de ajuda do painel e confirme com uma consulta em vez de confiar no formulário.

• Registro em www ou mail: texto correto, host errado. Mova-o para o apex se você envia de @example.com.
• Domínio duplicado: um painel que acrescenta a zona automaticamente transforma example.com em example.com.example.com. Consulte esse nome e você encontrará seu registro lá.
• Domínio de envio errado: você verificou example.com, mas o remetente do envelope é bounce.example.net ou mail.example.com. O receptor olhou para esse nome, não para o seu.

Causa 2: você está verificando um domínio diferente do que o e-mail usa

O endereço que as pessoas veem no cabeçalho From é uma coisa. O remetente do envelope, que o SPF avalia, pode ser outra. Muitos provedores de serviço de e-mail usam um domínio de retorno personalizado, e alguns usam o próprio domínio por padrão. Então o SPF é avaliado nesse nome, e o seu registro nem é consultado na verificação.

O cabeçalho da mensagem mostra qual domínio foi avaliado (veja abaixo). Se for um subdomínio seu, esse subdomínio precisa do próprio registro, mesmo que o domínio superior tenha um perfeito. Um subdomínio que nunca envia pode publicar v=spf1 -all.

Causa 3: o texto não é uma cadeia SPF válida

O verificador é rigoroso com o início do valor. O texto deve começar com v=spf1, com o sinal de igual e sem espaços dentro. Todos estes quase-acertos produzem «não encontrado»:

• spf1 include:_spf.example.net ~all (falta o v=)
• v=spf include:_spf.example.net ~all (a versão deve ser spf1)
• v = spf1 ... (espaços em volta do sinal de igual)
• Texto colado com aspas tipográficas «inteligentes» copiadas de um documento ou de um chat

As aspas merecem uma observação. A maioria dos painéis de DNS hospedados adiciona as aspas duplas retas para você, então digitar as suas pode fazer com que sejam salvas como caracteres literais. Se uma resposta do dig mostrar duas camadas de aspas, remova as que você digitou.

Causa 4: a zona que você editou não é a ativa

Essa engana até gente experiente. Você pode adicionar um registro TXT perfeito em um painel de DNS e ainda assim não ver nada no DNS público, porque aquele painel não é o que a internet consulta. O motivo habitual é a delegação.

• Registrador versus host de DNS: o domínio está registrado em uma empresa, mas seus servidores de nomes apontam para outra (uma CDN, uma empresa de hospedagem, um provedor de DNS separado). Só a zona nos servidores de nomes delegados está ativa. Registros adicionados na página de DNS do próprio registrador, ou em uma zona esquecida em um provedor anterior, são ignorados.

Descubra os servidores de nomes delegados com a consulta NS e edite a zona exatamente nesse provedor. Isso muitas vezes explica o clássico «adicionei há uma hora e ainda não aparece» melhor do que a propagação.

Causa 5: tipo de registro legado, cache ou tempo

Os primeiros rascunhos do SPF usavam um tipo de registro dedicado (número 99, chamado SPF). Esse tipo está obsoleto e os receptores avaliam registros TXT, então um registro publicado apenas como tipo SPF é invisível para as verificações modernas. Publique um registro TXT mesmo que o seu provedor de DNS ainda ofereça um tipo SPF.

O tempo é o último suspeito e o mais fraco. Se um resolvedor já aprendeu que o nome não tinha registro TXT, ele pode continuar servindo essa resposta vazia por um período ligado às configurações de cache negativo da zona. Consultar diretamente o servidor de nomes autoritativo elimina a dúvida. Nosso artigo sobre quanto tempo leva a propagação do DNS explica o mecanismo.

Confirme o que o DNS realmente retorna

Antes de mudar qualquer coisa, faça ao DNS a mesma pergunta que o receptor fez. No Linux ou macOS:

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Uma resposta vazia, ou respostas que contenham apenas coisas como tokens de verificação de site, confirma «não encontrado». Para contornar o cache do seu próprio resolvedor, pergunte diretamente a um servidor de nomes: dig TXT example.com @ns1.example.net +short, usando um servidor de nomes obtido na consulta NS. Se isso retornar o registro e a sua consulta normal não, trata-se de cache. Se nenhuma das duas retornar, o registro não está na zona ativa.

O verificador SPF deste site consulta os registros TXT do domínio que você informa, mantém os que começam com v=spf1 e informa «No SPF record» quando não encontra nenhum. Se encontrar um, ele também percorre os includes e conta as consultas. A consulta TXT mostra todos os valores TXT de um nome, o que ajuda quando o registro está presente mas malformado, pois você vê o texto bruto.

Leia o cabeçalho de uma mensagem que falhou

Abra a origem original de uma mensagem entregue e localize o cabeçalho Authentication-Results adicionado pelo servidor receptor. A parte do SPF indica o resultado e, em geral, o domínio avaliado. A redação do cabeçalho varia conforme o receptor, então trate os exemplos como um padrão, não como um formato exato.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none: nenhum registro no domínio avaliado. Use este artigo.
• spf=fail ou softfail: existe um registro, mas o IP de envio não está autorizado. Adicione o remetente ou corrija a política.
• spf=permerror: o registro está quebrado, por dois registros ou por consultas demais.

Anote o domínio de smtp.mailfrom (ou Return-Path). Foi esse, e não o endereço From, que o SPF avaliou. Para ler os cabeçalhos por completo, veja como rastrear o remetente original de um e-mail.

Publique um registro mínimo e seguro

Publique um único registro TXT no nome usado no remetente do envelope. Um registro é uma lista de mecanismos lidos da esquerda para a direita, terminando com um valor padrão para todos os demais.

• ip4 / ip6: autoriza um endereço ou uma faixa, por exemplo ip4:203.0.113.25. Não custa nenhuma consulta DNS.
• include: autoriza o que o registro SPF de outro domínio autoriza, por exemplo include:_spf.example.net. Custa uma consulta.
• a: autoriza os endereços IP do registro A (ou AAAA) do próprio domínio. Custa uma consulta.
• mx: autoriza os hosts indicados nos registros MX do domínio. Custa uma consulta; errado quando o seu host de entrada não é o que envia.
• ~all, -all, ?all: o valor padrão. ~all é softfail, -all é fail, ?all é neutral.

Comece com ~all enquanto confirma que todos os remetentes estão listados e considere -all quando tiver certeza. ?all não afirma nada e é na maior parte transitório. Uma lista correta importa mais do que o final, já que os receptores ponderam o SPF junto com DKIM e DMARC.

Dicas rápidas para plataformas comuns

Os menus diferem e mudam, mas os padrões de falha se repetem. Verifique estes pontos em cada tipo de configuração.

• Microsoft 365 e Google Workspace: ambos publicam um include para você copiar do console de administração ou do guia de configuração. Um «não encontrado» ali geralmente significa que o registro foi para o provedor de DNS ou o host errado.
• GoDaddy e outros registradores: se os servidores de nomes foram trocados para uma CDN ou empresa de hospedagem, a página de DNS do registrador deixou de ser autoritativa. Edite os registros no provedor que a consulta NS mostrar.
• Cloudflare: quando o domínio usa os servidores de nomes da Cloudflare, adicione o registro TXT na aba DNS da Cloudflare.

O que os receptores fazem quando não há SPF

SPF none não é uma rejeição automática. O padrão deixa a decisão para a política local do receptor, então os resultados variam. E-mail sem SPF e sem DKIM ou DMARC para compensar tem mais chance de parecer suspeito, e alguns provedores publicam requisitos de autenticação para remetentes em massa. Consulte as regras atuais dos provedores para os quais você envia.

O SPF verifica o remetente do envelope, então sozinho não impede que alguém falsifique o seu endereço From visível; isso é trabalho do DMARC. Veja SPF, DKIM e DMARC explicados e como verificar um registro SPF.