SPF fail: causas, verificação e correção

O que significa "SPF fail"?

O SPF (Sender Policy Framework) permite que o dono de um domínio publique no DNS um registro TXT com a lista dos hosts autorizados a enviar e-mail em nome dele. Quando sua mensagem chega, o servidor de destino pega o endereço IP da conexão e consulta o registro SPF do domínio informado no comando SMTP MAIL FROM (que depois é gravado no cabeçalho Return-Path). Em seguida, avalia os mecanismos do registro da esquerda para a direita. Se o IP corresponder a algum deles, o resultado é pass. Se nada corresponder, quem define o resultado é o qualificador do "all" no final: -all gera fail, ~all gera softfail.

Um detalhe que a maioria dos guias ignora: o SPF nunca olha o endereço From visível. Uma mensagem pode exibir seu domínio no From e mesmo assim ser checada contra o registro de outro domínio, como o domínio de bounce do seu serviço de e-mail. Por isso, antes de mexer em qualquer DNS, descubra qual domínio foi realmente verificado. Na prática, o pessoal chama de "SPF fail" qualquer resultado que não seja pass. Em mensagens de bounce, ele costuma aparecer como uma rejeição 550 5.7.1 com "SPF fail" no texto. O artigo da Mailtester.com sobre falhas de SPF, de outubro de 2026, descreve esse código como um sinal direto de que a autenticação falhou.

Resultados do SPF: none, neutral, softfail, fail, temperror, permerror

Resultado	O que o resultado significa	Causa típica	O que fazer
pass	O IP está autorizado para o domínio verificado	O IP correspondeu a um mecanismo de endereço IP, a, mx ou include	Nada no SPF, mas confira mesmo assim o alinhamento do DMARC
none	Nenhum registro SPF foi encontrado para o domínio verificado	Não existe registro TXT começando com v=spf1, ou ele está no host ou subdomínio errado	Publique um registro exatamente no domínio usado no MAIL FROM
neutral	O domínio não se posiciona sobre esse IP	O registro termina em ?all	Troque ?all por ~all ou -all depois de listar todos os remetentes
softfail	O IP provavelmente não está autorizado	O IP não está listado e o registro termina em ~all	Adicione o include ou o IP do remetente que está faltando
fail	O IP explicitamente não está autorizado	O IP não está listado e o registro termina em -all	Adicione o remetente que falta ou descubra quem está usando seu domínio
temperror	Houve um erro temporário de DNS durante a verificação	Timeout de DNS ou nameserver inacessível	Verifique seus nameservers. O servidor de destino pode tentar de novo
permerror	O registro não pode ser interpretado	Dois registros SPF, erro de sintaxe ou consultas DNS demais	Una, corrija ou faça o flattening do registro

Por que o SPF falha?

• Um novo serviço de envio não está no registro. Você conectou um CRM, um help desk ou um serviço de e-mail e nunca adicionou o include dele, então os IPs não batem.
• Existem dois registros SPF no mesmo domínio. Um domínio só pode ter um registro TXT começando com v=spf1. Com dois, a verificação retorna permerror, mesmo que cada um esteja certo isoladamente. Isso costuma acontecer quando o guia de configuração de um segundo serviço manda "adicionar" um registro em vez de mesclar com o que já existe.
• O registro exige consultas DNS demais. O guia de falhas de SPF da Valimail e o guia da PowerDMARC sobre falhas de autenticação SPF colocam o limite em 10 consultas DNS por verificação, contando os includes aninhados. Includes, a, mx e redirects entram na conta. Entradas de endereço IP puro não entram. Passou do limite, o resultado é permerror.
• Includes apontam para domínios mortos. Um include cujo domínio não existe mais não retorna resposta. Mesmo assim, ele gasta uma consulta, e os servidores de destino só toleram poucas consultas vazias antes de interromper a verificação.
• Erros de sintaxe, como faltar o prefixo v=spf1, um espaço depois de "include:", um intervalo de IP mal formatado ou texto colado com aspas tipográficas.
• O registro está no host errado. O SPF não é herdado. Se o seu serviço usa bounce.example.com como domínio do MAIL FROM, o registro em example.com nunca é consultado.
• Encaminhamento e listas de e-mail. Um encaminhador repassa sua mensagem a partir do próprio IP, que não está no seu registro, então o SPF falha no destino final. Só o DKIM sobrevive a um encaminhamento que não altera a mensagem.
• Problemas de DNS durante a consulta, que geram temperror. Uma thread do Microsoft Q&A de outubro de 2024 descreve resultados temperror que só apareciam no envio para destinatários corporativos do Outlook.

Como verificar SPF e DKIM

1. 1 Envie uma mensagem de teste para uma caixa que você controla e abra o código-fonte. No Gmail, a opção "Mostrar original" exibe no topo os resultados de SPF, DKIM e DMARC.
2. 2 Encontre o cabeçalho Authentication-Results. Anote spf= e smtp.mailfrom= (o domínio que o SPF de fato verificou), depois dkim= e header.d= (o domínio que assinou a mensagem).
3. 3 Consulte o registro SPF com dig TXT example.com +short. Conte as respostas que começam com v=spf1. Se houver mais de uma, aí está o seu permerror.
4. 4 Consulte o DKIM. Pegue o valor s= (o seletor) no cabeçalho DKIM-Signature e rode dig TXT selector._domainkey.example.com +short. Resposta vazia significa que não há chave pública publicada nesse host.
5. 5 Compare os dois domínios com o domínio do seu From. O DMARC exige que pelo menos um deles corresponda a ele.
6. 6 Conte as consultas. O Check MX do Google Admin Toolbox e o SPF lookup do MxToolbox expandem os includes aninhados. Os dois leem o DNS público, então um registro alterado há poucos minutos pode ainda não aparecer. Isso depende do TTL do registro.

Para um passo a passo mais completo dos três registros do ponto de vista de quem faz prospecção fria, veja nosso guia de DKIM, DMARC e SPF para quem faz cold email.

Qual é o registro SPF do Google para Workspace, G Suite e Gmail?

A documentação de administração do Google Workspace sobre solução de problemas de SPF traz um único valor para domínios que enviam pelo Google: um registro TXT no domínio raiz com o conteúdo v=spf1 include:_spf.google.com ~all. Cada linha abaixo responde a uma variação da pergunta. A configuração de DNS completa, incluindo os registros MX, está no nosso artigo sobre registros DNS do Google Workspace para MX, SPF e DKIM.

Pergunta	Resposta
Registro SPF do Google Workspace	Um registro TXT no seu domínio raiz: v=spf1 include:_spf.google.com ~all. Se outros serviços enviam pelo mesmo domínio, adicione os includes deles neste mesmo registro, antes do ~all. Não publique um segundo registro.
Registro SPF do G Suite	G Suite é o nome antigo do Google Workspace, e o registro não mudou: v=spf1 include:_spf.google.com ~all. Guias de configuração que ainda falam em G Suite continuam valendo.
Registro SPF do Gmail	Não dá para publicar nem alterar SPF de um endereço pessoal do Gmail, porque o Google controla o DNS de gmail.com. E-mails que exibem um From do Gmail mas saem pelos servidores de outro serviço não ficam alinhados com gmail.com. A prospecção deve sair de um domínio que seja seu.
Registros SPF do Google: um ou vários?	Um. O include do Google contém outros includes, e cada um deles conta para o limite de consultas. Confira o total depois de adicionar outros serviços.
Registros SPF e DKIM do Google	O SPF vai no registro TXT raiz acima. O DKIM você gera no Admin Console em Apps > Google Workspace > Gmail > Autenticar e-mail, publica como registro TXT em google._domainkey (o seletor padrão) e ativa com Iniciar autenticação.

Se o Brevo também assina e-mails pelo mesmo domínio, nosso guia de configuração de DKIM no G Suite mostra como manter as chaves do Google e as do Brevo separadas.

O que acontece se não houver registro SPF?

Sem registro, o resultado do SPF é none. Isso, por si só, não é uma rejeição, porque quem decide o que fazer é o servidor de destino. Mas os grandes provedores de caixa de entrada hoje esperam e-mail autenticado. As diretrizes de remetentes do Google para o Gmail pedem que todo remetente configure SPF ou DKIM, e que remetentes em massa configurem os dois, mais o DMARC. Sem SPF, seu domínio também não tem uma lista publicada de remetentes autorizados, então os servidores de destino não têm com o que comparar uma mensagem falsificada. Adicionar o registro leva minutos. Só não publique -all antes de listar todos os remetentes legítimos, senão seus próprios e-mails começam a falhar. O guia de hard fail da Sendmarc, de setembro de 2026, organiza a ordem em três etapas: auditar os remetentes, implantar de forma gradual e só então aplicar a política.

O que significa DMARC fail quando o SPF falha?

O DMARC passa quando o SPF ou o DKIM passa e o domínio aprovado está alinhado com o domínio do cabeçalho From visível. Então um SPF fail não significa automaticamente um DMARC fail, porque uma assinatura DKIM alinhada já basta. O contrário também pega muita gente de surpresa: o SPF pode passar no domínio de bounce do seu serviço de e-mail enquanto o DMARC falha, porque esse domínio não é seu. Um DMARC fail significa que nenhuma das duas verificações deu um pass alinhado. O que acontece depois depende da sua política: p=none só gera relatórios, enquanto p=quarantine e p=reject dizem ao servidor de destino como tratar a mensagem. Nosso guia de configuração de DMARC cobre o registro, suas tags e os relatórios agregados que mostram quais fontes estão falhando.

Como corrigir "SPF fail" passo a passo

1. 1 Leia o cabeçalho primeiro. Anote o resultado e o domínio do smtp.mailfrom. Corrigir o domínio errado não muda nada.
2. 2 Liste todos os serviços que enviam com o seu domínio: seu provedor de e-mail, o Brevo, o sistema de faturamento, o help desk, o CRM.
3. 3 Junte todos em um único registro TXT por domínio: v=spf1, depois os includes e IPs, e um único mecanismo all no final.
4. 4 Conte as consultas. Se passou do limite, remova serviços que você não usa mais ou troque um include pelos intervalos de IP que o serviço documenta. Intervalos achatados (flattening) precisam ser revisados sempre que o provedor mudar os IPs.
5. 5 Comece com ~all. Só passe para -all depois que seus relatórios DMARC mostrarem que nenhuma fonte legítima está falhando.
6. 6 Verifique o DKIM junto com o SPF. O DKIM sobrevive ao encaminhamento e é o caminho habitual para o alinhamento DMARC quando seu serviço de e-mail usa um domínio de bounce próprio.
7. 7 Depois que o TTL do registro expirar, envie uma nova mensagem de teste.

Como o EmailFlow OS envia e o que isso significa para o SPF

Com o EmailFlow OS, você grava um único vídeo e faz o upload, conecta sua própria conta Brevo e seu domínio de envio e importa sua lista de prospects para o EmailFlow OS. O EmailFlow OS então cria uma versão personalizada dessa gravação para cada destinatário e envia cada versão a partir da sua própria caixa de entrada, pela sua conta Brevo e pelo seu domínio. Não existe nenhum remetente compartilhado da plataforma no meio do caminho. Por isso, os resultados de SPF, DKIM e DMARC que o servidor de destino registra pertencem ao seu domínio e à sua configuração do Brevo, e os registros DNS continuam sob o seu controle. Isso também significa que qualquer falha de SPF é sua para corrigir, no seu próprio DNS. Onde a mensagem vai parar é decidido pelo servidor de destino, não pelo EmailFlow OS. A página inicial do EmailFlow OS sobre vídeo personalizado por e-mail mostra como o lado do envio se encaixa.

Antes do primeiro envio, você pode passar seu domínio pelo verificador de SPF, DKIM e DMARC, um produto do EmailFlow OS. Ele lê os registros publicados, então um registro SPF duplicado ou uma chave DKIM ausente aparece logo de cara.

Perguntas frequentes

? Devo usar -all ou ~all no meu registro SPF?

Com -all, IPs não listados recebem fail. Com ~all, recebem softfail. O DMARC trata os dois como SPF sem pass, então a diferença importa principalmente para servidores de destino que agem só com base no SPF. Use ~all enquanto ainda estiver mapeando todos os seus remetentes. Mude para -all quando seus relatórios agregados de DMARC mostrarem todas as fontes legítimas passando.

? Posso ter dois registros SPF no mesmo domínio?

Não. A especificação do SPF permite apenas um registro TXT começando com v=spf1 por nome de domínio. Um segundo faz a verificação inteira retornar permerror, que a maioria dos servidores de destino trata como falha. Junte os includes em um único registro. Um subdomínio como mail.example.com conta como um nome separado e pode ter o próprio registro.

? Por que o SPF falha mesmo com o IP de envio no meu include?

Normalmente há três motivos possíveis. A contagem de consultas passou do limite, e a verificação para com permerror antes de chegar ao seu include. Ou o domínio verificado não é o que tem o include, porque o MAIL FROM usou um subdomínio ou o domínio de bounce do serviço. Ou existe um segundo registro SPF. O cabeçalho Authentication-Results mostra qual é o caso.

? O SPF sobrevive ao encaminhamento de e-mail?

Geralmente não. Um encaminhador envia sua mensagem a partir do próprio endereço IP, que não está no seu registro SPF, então o destino final vê fail ou softfail. Uma assinatura DKIM sobrevive desde que o encaminhador não altere os cabeçalhos assinados nem o corpo. É por isso que uma assinatura DKIM alinhada é tão importante para o DMARC.