Registro SPF do Gmail: Seu Guia Passo a Passo para 2026

Você inicia uma atualização para clientes, um e-mail de contratação ou uma sequência de vendas pelo Gmail. O texto está sólido. A lista está limpa. Então, as respostas diminuem drasticamente ou, pior, alguém lhe diz que sua mensagem caiu na caixa de spam.

Em equipes pequenas, isso geralmente faz com que as pessoas analisem primeiro as linhas de assunto, os modelos e o volume de envio. Justo. Mas uma das causas mais comuns está fora do Gmail, nas suas configurações de DNS. Seu registro SPF decide se os servidores de e-mail de recebimento tratam o Gmail como um remetente aprovado para o seu domínio.

Isso importa ainda mais se você estiver pesquisando ferramentas de prospecção baseadas no Gmail. Tenha cuidado com nomes de produtos que soam genéricos, especialmente Mail Merge for Gmail. A frase descreve uma categoria tanto quanto um produto específico, por isso é fácil ler conselhos de configuração destinados a uma ferramenta de mala direta diferente e aplicá-los ao sistema errado.

Por que seu registro SPF do Gmail é importante

Uma maneira útil de pensar sobre o SPF é como uma lista de convidados para o seu domínio. Quando seu e-mail chega a outro servidor de e-mail, esse servidor verifica se o remetente está na lista. Se o Gmail estiver nela, sua mensagem tem uma chance muito maior de ser tratada como legítima. Se o Gmail não estiver, o destinatário tem um motivo para desconfiar da mensagem antes mesmo de ler a linha de assunto.

Esse problema de confiança aparece em situações de negócios comuns. Um fundador envia e-mails de integração. Um gerente de RH envia convites para entrevistas. Uma escola envia atualizações de eventos para os pais. Tudo parece bem dentro do Gmail, mas o servidor de recebimento não vê uma autorização clara para o seu domínio e começa a tratar essas mensagens com mais cautela.

O que o SPF protege

O SPF faz dois trabalhos ao mesmo tempo:

• Proteção de entrega: Ajuda os servidores de recebimento a reconhecer que o Google tem permissão para enviar e-mails em nome do seu domínio.
• Proteção da marca: Torna mais difícil para outra pessoa falsificar seu domínio em e-mails enviados.

O SPF diz ao mundo exterior quais sistemas de envio falam pelo seu domínio e quais não falam.

Se você está tentando impulsionar o sucesso do marketing por e-mail, esta é uma das primeiras verificações técnicas que vale a pena fazer. Um texto melhor não consegue compensar um domínio que não está autenticado corretamente.

Por que pequenos erros causam grandes problemas

A parte frustrante é que os problemas de SPF geralmente não parecem problemas de SPF. As mensagens ainda podem ser enviadas. Alguns destinatários ainda podem recebê-las. Outros podem ver a mensagem na pasta de spam, avisos ou filtragem silenciosa. Essa inconsistência é o que confunde as pessoas.

Se seus e-mails já estão indo para pastas de lixo eletrônico, vale a pena combinar este guia de configuração com um passo a passo prático sobre como evitar que o e-mail vá para o spam. O SPF não é toda a história da entregabilidade, mas é uma das poucas correções que melhora diretamente a confiança no nível do domínio, em vez de apenas ajustar o conteúdo e esperar pelo melhor.

Criando seu registro SPF principal do Gmail

Se o seu domínio envia e-mail apenas pelo Gmail ou Google Workspace, a configuração é direta. O registro SPF oficial do Google é a string exata documentada na Ajuda do Administrador do Google Workspace:

v=spf1 include:_spf.google.com ~all

Esse valor deve ser publicado como um único registro TXT na raiz do seu domínio. Na maioria dos painéis de DNS, o host é @. O Google também recomenda um TTL de 3600 segundos (1 hora), e as alterações de DNS podem levar até 48 horas para se propagarem totalmente, dependendo do seu provedor, de acordo com essa mesma documentação do Google Workspace.

O que inserir no DNS

Se o seu DNS é gerenciado no GoDaddy, Cloudflare, Namecheap ou outro provedor, os campos geralmente são mapeados assim:

1. Tipo: TXT
2. Host ou Nome: @
3. Valor ou Conteúdo: a string SPF acima
4. TTL: 3600 se o seu provedor permitir que você defina manualmente

O erro mais comum aqui é pensar demais no tipo de registro. Muitos painéis de DNS não oferecem mais um tipo de registro SPF separado. Isso é normal. Você quer um registro TXT.

Um passo a passo visual rápido pode ajudar se esta for sua primeira vez editando o DNS:

O que funciona e o que não funciona

Aqui está a versão prática.

• Funciona: adicionar um registro TXT na raiz do domínio com o valor SPF exato do Gmail.
• Não funciona: adicionar espaços extras, dividir o valor em registros SPF separados ou publicá-lo sob o host errado, como um subdomínio, quando seu e-mail é enviado do domínio principal.

Regra prática: Copie o valor SPF exatamente, publique-o uma vez e resista à vontade de criar um segundo registro SPF mais tarde quando adicionar outro remetente.

Se você está em um ambiente simples que usa apenas o Gmail, isso geralmente é suficiente para concluir a configuração básica do registro SPF do Gmail corretamente. Salve o registro, aguarde a propagação e verifique antes de alterar qualquer outra coisa.

Lidando com vários remetentes de e-mail e mala direta

Uma configuração comum de pequenas empresas é assim: a equipe envia e-mails regulares pelo Google Workspace, o marketing executa campanhas a partir de uma ferramenta de mala direta, e um CRM ou central de suporte envia mensagens automatizadas do mesmo domínio. O SPF precisa cobrir todos eles, ou um desses sistemas começará a falhar na autenticação.

É aí que muitas configurações de SPF do Gmail falham. O registro básico do Google é fácil. A complexidade começa quando cada nova ferramenta pede que você adicione outra entrada include: e ninguém verifica o que essas adições fazem ao registro completo.

As duas regras que mais importam

Regra um: publique um registro TXT SPF para o domínio.

Regra dois: mantenha a avaliação SPF completa abaixo de 10 consultas DNS. Esse limite inclui consultas aninhadas dentro de cada include:. Um registro pode parecer curto no seu painel de DNS e ainda falhar porque o registro SPF de um fornecedor se expande em várias outras verificações. Esta análise do DMARC Report explica por que a contagem de consultas é importante na configuração do SPF do Gmail.

Ambientes com vários remetentes atingem esse limite mais rápido do que as pessoas esperam. O Google Workspace mais um remetente de mala direta, um CRM e uma plataforma de suporte podem causar problemas, mesmo que as instruções de cada fornecedor estejam tecnicamente corretas por conta própria. O erro é tratar cada remetente como um projeto de DNS separado em vez de uma política de autorização combinada.

Como é uma mesclagem adequada

Se o Gmail e outro serviço aprovado enviam e-mails para o seu domínio, adicione ambos os remetentes ao mesmo registro SPF.

Cenário	Registro SPF mesclado correto
Apenas Gmail	v=spf1 include:_spf.google.com ~all
Gmail mais um remetente de terceiros	v=spf1 include:_spf.google.com include:spf.thirdparty.com ~all
Gmail mais vários remetentes	v=spf1 include:_spf.google.com include:spf.vendorone.com include:spf.vendortwo.com ~all

Esses exemplos mostram a estrutura. Seus valores reais de terceiros devem vir da documentação de cada provedor. O ponto prático permanece inalterado. Um domínio recebe um registro SPF.

O que geralmente quebra na vida real

Eu costumo ver três padrões de falha.

• Um segundo registro SPF é publicado. Alguém adiciona uma nova entrada TXT começando com v=spf1 em vez de editar a existente.
• Serviços antigos permanecem autorizados para sempre. Uma empresa para de usar uma ferramenta, mas seu include: permanece no DNS e continua consumindo consultas.
• A mala direta é tratada como “apenas Gmail”. Algumas ferramentas enviam através da infraestrutura do Google, enquanto outras enviam através de seus próprios servidores ou de um provedor conectado. Essa diferença altera se o SPF precisa de outro include.

O terceiro ponto é muito ignorado. Se sua equipe usa um fluxo de trabalho baseado em Planilhas, confirme como essa ferramenta envia e-mails antes de tocar no DNS. Um guia sobre mala direta do Google Sheets pode ajudá-lo a mapear o fluxo de trabalho, mas o SPF ainda depende da infraestrutura de envio por trás desse fluxo.

Como ficar abaixo do limite de 10 consultas

Comece com um inventário de remetentes. Liste todos os sistemas autorizados a enviar e-mails como seu domínio. Inclua plataformas de marketing, CRMs, ferramentas de suporte, aplicativos de faturamento, formulários de sites e qualquer produto de mala direta.

Depois, corte rigorosamente.

Remova remetentes que você não usa mais. Verifique se duas ferramentas enviam pelo mesmo provedor, o que pode tornar um include desnecessário. Se um fornecedor oferece mais de uma opção de SPF, escolha aquela que eles documentam para o seu caso de uso, em vez de colar todos os registros que encontrar.

Se o registro ainda for muito grande, a resposta não é um segundo registro SPF. A resposta é reduzir o número de caminhos de envio autorizados ou, em alguns casos, usar um subdomínio para um fluxo de e-mail separado para que o registro SPF do domínio principal permaneça gerenciável.

Se você adicionar um novo remetente, trate-o como uma revisão de alteração de DNS. Confirme se o remetente ainda é necessário, atualize o único registro SPF e verifique a contagem de consultas antes de salvar.

Como verificar se seu registro SPF está funcionando

Depois de salvar o registro, não presuma que terminou. A verificação é onde você detecta os erros silenciosos, especialmente se o seu painel de DNS aceitou a entrada, mas a sintaxe ou a contagem de consultas ainda está errada.

Use um validador primeiro

Comece com um verificador de SPF público, como o MxToolbox ou o dmarcian SPF Surveyor. Eles são úteis porque não apenas confirmam que um registro TXT existe. Eles também inspecionam a estrutura e, no caso de consultas mais avançadas, ajudam você a ver se seus includes criam muitas consultas DNS.

Insira seu nome de domínio e analise o resultado cuidadosamente. Você está procurando três coisas:

• O registro foi encontrado: a ferramenta consegue ver seu registro SPF TXT no DNS público.
• A sintaxe é válida: sem mecanismos malformados, espaços perdidos ou entradas SPF duplicadas.
• A cadeia é gerenciável: os includes não se expandem em um resultado quebrado.

Como é um bom resultado

Uma verificação saudável geralmente parece entediante, e é exatamente isso que você quer. A ferramenta encontra um registro SPF, analisa-o corretamente e não sinaliza um erro permanente.

Um resultado com falha geralmente se enquadra em um destes grupos:

• Nenhum registro SPF encontrado: o registro ainda não se propagou, foi salvo sob o host errado ou nunca foi publicado.
• Vários registros SPF encontrados: você adicionou um segundo registro TXT v=spf1 em vez de editar o existente.
• Muitas consultas: sua lista combinada de remetentes é muito grande ou muito aninhada.

Verifique também um e-mail ao vivo

Validadores são bons para a estrutura. Uma mensagem real confirma o comportamento.

Envie um e-mail de teste para uma caixa de entrada do Gmail que você possa acessar. Abra a mensagem, use a opção do Gmail para visualizar a mensagem original e inspecione os resultados da autenticação. Se o SPF passar, esse é um forte sinal de que seu DNS público e seu caminho de envio real estão alinhados.

As ferramentas de validação informam se o registro DNS é publicável. Um teste ao vivo informa se o seu fluxo de e-mail real corresponde à política de DNS.

Se o validador passar, mas as mensagens ao vivo ainda se comportarem mal, o problema pode estar em outro lugar na sua pilha de autenticação, e não apenas no SPF.

Solução de problemas comuns do registro SPF

Os problemas de SPF geralmente se tornam óbvios logo após uma alteração. Uma pequena empresa começa a enviar propostas pelo Google Workspace, adiciona uma ferramenta de mala direta e, em seguida, percebe que as respostas estão diminuindo ou as mensagens estão caindo no spam. Na prática, o problema geralmente é um erro de DNS, não um problema complexo de e-mail.

Vários registros SPF encontrados

Sintoma: seu validador relata vários registros SPF, ou os servidores de recebimento retornam um erro permanente de SPF.

Causa: seu domínio tem mais de um registro TXT começando com v=spf1. Vejo isso depois que uma empresa adiciona um segundo remetente, como um CRM ou plataforma de prospecção, e o guia de configuração do novo fornecedor é seguido à risca. O SPF não mescla esses registros. Os receptores veem o conflito e o tratam como inválido.

Solução: mantenha um registro SPF para o domínio e coloque todos os remetentes aprovados nessa única entrada TXT. Se você já tiver registros separados, escolha um como mestre, combine os mecanismos necessários e exclua os extras.

Muitas consultas DNS

Sintoma: o registro parece completo, mas o SPF ainda falha com um limite de consulta ou resultado de erro permanente.

Causa: as verificações de SPF só podem seguir um número limitado de consultas DNS. Este é o erro que os guias básicos de SPF do Gmail geralmente ignoram. Ele aparece em ambientes reais onde o Google Workspace é apenas um remetente entre vários, especialmente se você também usa software de mala direta, uma central de suporte, um sistema de cobrança e uma plataforma de marketing do mesmo domínio. Cada include: pode trazer mais includes abaixo dele, portanto, um registro que parece curto ainda pode exceder o limite.

Solução: reduza a lista de remetentes antes de tentar qualquer coisa inteligente. Remova serviços que não enviam mais e-mails para o seu domínio. Pergunte a cada fornecedor se todos os seus includes publicados são necessários para o seu caso de uso. Se sua pilha ainda for muito grande, divida os fluxos de e-mail por subdomínio. Por exemplo, mantenha o e-mail regular da equipe no seu domínio principal e mova a prospecção ou e-mails em massa para um subdomínio com sua própria política de SPF. Essa abordagem costuma ser a correção mais limpa em uma configuração com vários remetentes, pois reduz a pressão de consulta e impede que um registro inchado quebre todo o resto.

Problemas de sintaxe e registros ausentes

Sintoma: o registro existe no DNS, mas o validador sinaliza erros de formatação ou nenhum registro SPF é encontrado.

Causa: isso geralmente vem de uma colagem ruim, do valor de host errado ou da publicação da string SPF no campo errado. No cPanel, GoDaddy, Cloudflare e substituições do Google Domains, os rótulos diferem o suficiente para confundir administradores de primeira viagem. Um registro destinado ao domínio raiz pode ser inserido em www, ou o valor TXT pode ser dividido incorretamente.

Solução: compare o valor TXT publicado com o registro pretendido caractere por caractere. Confirme se o host está correto para o domínio que você está autenticando e certifique-se de ter criado um registro TXT, não outro tipo de registro. Se a sintaxe estiver boa, mas o e-mail ainda falhar, revise a configuração de autenticação de e-mail para domínios personalizados mais ampla, porque o registro SPF pode ser válido enquanto outro controle de autenticação está causando o problema.

Uma ordem prática de solução de problemas

Use esta ordem quando o SPF falhar:

1. Verifique se há registros SPF duplicados. Este é o problema mais rápido de confirmar e corrigir.
2. Revise o texto do registro cuidadosamente. Procure por erros de digitação, espaços ausentes, aspas extras ou o host errado.
3. Mapeie cada serviço de envio. Inclua Google Workspace, ferramentas de mala direta, CRMs, plataformas de suporte e qualquer outra coisa que envie e-mails como seu domínio.
4. Conte os includes que consomem muitas consultas. Se a lista estiver lotada, simplifique-a ou mova alguns remetentes para um subdomínio.

Essa ordem economiza tempo porque corresponde à forma como o SPF geralmente falha no campo. Equipes pequenas geralmente presumem que a ferramenta mais nova causou o problema, mas a desordem antiga no DNS é tão comum quanto. Se você quiser uma lista de verificação operacional mais ampla enquanto limpa isso, o guia de segurança de e-mail da Simply Tech Today é uma referência útil.

Além do SPF: seus próximos passos na autenticação de e-mail

Uma pequena empresa pode publicar um registro SPF correto e ainda ver mensagens caindo no spam assim que faturas, prospecções e acompanhamentos começam a sair de sistemas diferentes. Isso geralmente acontece em configurações mistas, especialmente quando o Google Workspace lida com o e-mail diário e outra ferramenta envia campanhas ou mala direta do mesmo domínio.

O SPF cobre apenas parte da decisão que um servidor de e-mail de recebimento toma. Ele verifica se o servidor de envio tem permissão para usar seu domínio. Isso importa, mas não prova que a mensagem foi assinada corretamente nem diz ao servidor de recebimento o que fazer quando a autenticação falha.

É aí que entram o DKIM e o DMARC, e eles importam ainda mais em ambientes com vários remetentes.

O DKIM adiciona uma assinatura criptográfica à mensagem para que os servidores de recebimento possam confirmar que a mensagem é legítima e não foi alterada depois que saiu do seu sistema. O DMARC fica acima do SPF e do DKIM e diz aos provedores de caixa de entrada como avaliar essas verificações para o seu domínio. Ele também fornece relatórios, que geralmente são a primeira visão clara de um remetente que você esqueceu que estava usando seu domínio.

Este é o ponto que muitos guias básicos de SPF ignoram. Se você usa o Google Workspace, uma ferramenta de mala direta, um CRM e uma plataforma de suporte, o SPF pode se tornar difícil de manter devido ao limite de 10 consultas. O DKIM ajuda a reduzir o quanto você precisa depender apenas do SPF, e o DMARC oferece uma camada de política para que seu domínio não seja julgado apenas por um registro TXT lotado.

Para o próximo passo técnico após o SPF, revise este guia sobre autenticação de e-mail para domínios personalizados. Ele fornece o caminho de configuração prática para DKIM e DMARC após a implementação do seu registro SPF.

Se você quiser uma lista de verificação operacional mais ampla, o guia de segurança de e-mail da Simply Tech Today é uma leitura complementar útil.

A conclusão prática é direta. O SPF estabelece a permissão. O DKIM prova a integridade da mensagem. O DMARC oferece controle, visibilidade e uma maneira mais segura de gerenciar um domínio que envia e-mails de mais de um sistema.