Verificar e criar o registro SPF

Como verificar um registro SPF

1. Digite um domínio no campo acima. Um endereço de e-mail completo também funciona. A ferramenta usa só o domínio.
2. Clique em Verificar registro SPF. A verificação lê o registro atual no DNS público, o mesmo que um servidor de destino lê.
3. Leia primeiro o resumo. Ele diz se o registro é válido, se tem avisos ou se está quebrado.
4. Depois leia a lista de problemas, se houver. Cada item diz o que mudar.
5. Abaixo, cada parte do registro é explicada, com as consultas DNS que ela gasta. Abra um include para ver o que o serviço por trás dele autoriza.

O link na barra de endereço repete a mesma verificação de SPF. Você pode enviá-lo a um colega ou ao seu provedor de DNS. Há um limite: o servidor de destino verifica o SPF pelo IP do servidor que enviou a mensagem. Esta ferramenta não tem uma mensagem para analisar, então verifica o próprio registro. Ela não consegue avaliar partes feitas com macros SPF, que mudam a cada servidor de envio.

O que é um registro SPF?

Um registro SPF é um registro TXT no DNS de um domínio. Ele lista os servidores que podem enviar e-mail em nome desse domínio. SPF significa Sender Policy Framework, e as regras estão na RFC 7208. Um domínio que usa o Google Workspace costuma ter um registro como este:

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

v=spf1 indica que é um registro SPF. include:_spf.google.com autoriza todos os servidores da lista do próprio Google. ~all pede aos servidores de destino que tratem com suspeita o e-mail de qualquer outro servidor.

Quando uma mensagem chega, o servidor de destino pega o domínio do endereço de bounce, chamado Return-Path. Ele lê o registro SPF desse domínio e confere se o IP do servidor de envio está na lista. O SPF não olha o endereço From que você vê na caixa de entrada. Por isso ele trabalha junto com o DKIM e o DMARC. Para entender como os três se encaixam, leia SPF, DKIM e DMARC explicados.

Desde fevereiro de 2024, o Gmail exige SPF ou DKIM de todo remetente, e os dois de remetentes em massa. O Yahoo tem as mesmas regras.

O que significa cada parte do registro SPF

Um registro SPF é uma lista de termos separados por espaços. Os servidores de destino leem da esquerda para a direita e param no primeiro termo que corresponde ao servidor de envio.

Qualquer parte pode começar com um qualificador, que define o resultado quando ela corresponde. + significa pass e é o padrão, então ninguém o escreve. - significa fail, ~ significa softfail (falha leve) e ? significa neutral (neutro). Por isso a mesma palavra, all, pode terminar um registro como -all, ~all ou ?all.

Os nomes não diferenciam maiúsculas de minúsculas, então Include: funciona tão bem quanto include:. A RFC 7208 recomenda terminar todo registro com all ou com um redirect. Sem nenhum dos dois, os servidores que você não listou recebem um resultado neutro.

O limite de 10 consultas DNS

Cada include, a, mx, ptr, exists e redirect faz o servidor de destino executar uma consulta DNS. A RFC 7208 permite 10 no total. As consultas dentro de um include também contam, então um só include pode custar várias. ip4, ip6 e all não custam nada. Quando um registro precisa de mais de 10, os servidores de destino param e devolvem um permerror, e o SPF falha.

É fácil chegar ao limite. Medimos no DNS público o custo de includes comuns: Google Workspace 1, Microsoft 365 1, Salesforce 2, Mailgun 5 e Freshdesk 7. Uma empresa no Google Workspace que adiciona Mailgun e Freshdesk já precisa de 13 consultas. Um estudo de 2024 sobre registros SPF em .com, .net, .org e .se mostrou que 6,5% precisavam de mais de 10 consultas. Includes dos registros de apenas dois provedores de hospedagem causaram 83,7% desses casos.

Os custos também mudam. O include do Google custava 4 consultas até dezembro de 2025, quando o Google trocou os includes aninhados por uma lista simples. Alguns guias e geradores de SPF ainda falam em 4. O verificador acima conta o número real cada vez que você o usa.

Passar do limite nem sempre faz todas as mensagens falharem. A Microsoft explica que os servidores de destino param na primeira correspondência. O e-mail de um servidor listado no começo ainda pode passar, enquanto o de um servidor listado no fim falha. Isso faz o problema parecer aleatório, então conte as consultas do registro inteiro.

Existe um segundo limite. Uma consulta que não encontra nada é uma consulta vazia (void lookup), por exemplo um include de um domínio que não existe mais. A RFC 7208 diz que os servidores de destino devem parar depois de 2 delas.

Como ficar abaixo de 10 consultas

1. Remova os includes de serviços que você não usa mais.
2. Remova os includes que um serviço não pede mais. Mailchimp, Postmark, Brevo e Klaviyo não precisam de um no seu domínio principal. O SendGrid e o Amazon SES colocam o deles em um subdomínio. A lista está mais abaixo.
3. Liste seus próprios servidores com ip4 e ip6 em vez de a ou mx. A RFC 7208 recomenda essa ordem, e endereços IP não gastam consultas.
4. Envie parte dos e-mails por um subdomínio, como news.exemplo.com.br. Cada subdomínio tem o próprio registro e as próprias 10 consultas.

Alguns serviços oferecem SPF flattening, que troca os includes pelos endereços IP por trás deles. Isso economiza consultas, mas os provedores mudam seus endereços, e um registro com flattening não acompanha a mudança. A Microsoft recomenda usar flattening só em serviços com faixas de IP estáveis e documentadas, nunca no próprio Microsoft 365. Ela também pede para revisar o resultado pelo menos a cada trimestre.

Includes de SPF para Google Workspace, Microsoft 365 e outros serviços

Estes são os valores de include do guia de configuração de cada serviço, com as consultas DNS que cada um gasta. Medimos os custos no DNS público em 12 de outubro de 2026. Ao configurar um serviço, copie o valor do guia dele, porque alguns dependem da sua região ou conta.

O HubSpot dá a cada conta um include próprio, terminado em hubspotemail.net. Copie-o nas configurações de e-mail do HubSpot. Ele gasta 1 consulta.

Serviços que normalmente não precisam de include

O SPF é verificado no endereço de bounce, não no endereço From. Muitos serviços de envio hoje usam um endereço de bounce próprio, ou um subdomínio seu. Um include deles no seu domínio principal só gasta consultas.

• Mailchimp. A configuração de domínio do Mailchimp agora pede só registros DKIM e DMARC, não SPF.
• Postmark. O Postmark diz que o SPF não é mais necessário. Ele envia com um endereço de bounce próprio, ou com um registro Return-Path que você aponta para ele.
• Brevo. O Brevo diz que o SPF não é necessário, a menos que você envie de um endereço IP dedicado.
• Klaviyo. O Klaviyo diz que normalmente você não precisa adicionar um registro SPF.
• SendGrid. A autenticação de domínio do SendGrid coloca o SPF em um subdomínio que ele cria para você, como em1234.seudominio.com.br.
• Amazon SES. O SES só precisa dele em um subdomínio MAIL FROM personalizado, como bounce.seudominio.com.br. Por padrão, ele usa um endereço de bounce próprio.

O verificador aponta esses includes quando os encontra no seu registro.

Como criar um registro SPF

Use a aba Criar acima como gerador de SPF. Marque os serviços que enviam seus e-mails, e a ferramenta escreve o registro SPF e conta as consultas dele. Se o seu domínio já tem um registro, carregue-o primeiro, para completar o registro em vez de substituí-lo. Estes são os passos:

1. Liste todos os serviços que enviam e-mail em nome do seu domínio. Pense além do provedor de e-mail: newsletters, CRM, help desk, cobrança, formulários do site. Os relatórios DMARC mostram remetentes que você esqueceu.
2. Encontre o include de cada um no guia de configuração dele, ou marque o serviço na ferramenta. Para seus próprios servidores de e-mail, use os endereços IP deles.
3. Escolha o final: ~all ou -all. A próxima seção explica a diferença.
4. Publique-o como um único registro TXT no próprio domínio. A maioria dos provedores de DNS chama esse nome de @. Se já existe um registro que começa com v=spf1, edite-o em vez de adicionar um segundo.
5. Espere alguns minutos e verifique o domínio de novo com o verificador de SPF.

Cada nome que envia e-mail precisa do próprio registro, porque subdomínios não usam o registro do domínio pai. Um domínio ou subdomínio que nunca envia e-mail também deve ter um: v=spf1 -all. A RFC 7208 chama isso de boa prática bem estabelecida. Isso impede que outros enviem e-mails que se passem por esse nome. O NCSC do Reino Unido sugere adicionar também a esses domínios um registro DMARC com p=reject e um registro MX nulo.

Um registro com mais de 255 caracteres precisa ser dividido em várias strings dentro do mesmo registro TXT. Os servidores de destino juntam as strings sem espaços, então coloque o espaço dentro de uma string, não entre elas. Confira como o seu provedor de DNS trata valores longos.

~all ou -all: qual final usar

Os grandes provedores não concordam, e cada um tem um motivo.

• O Google recomenda ~all.
• O M3AAWG, um grupo do setor que reúne grandes provedores de e-mail e remetentes, diz que os registros devem terminar em ~all. Ele também pede aos servidores de destino que não recusem por falha de SPF antes de o DMARC rodar.
• A Microsoft recomenda -all, desde que o DKIM e o DMARC também estejam configurados.

O risco do -all é que alguns servidores de destino recusam a mensagem durante a entrega, antes de verificar o DMARC. A RFC 9989, o padrão DMARC de 2026, observa que esses e-mails nunca aparecem nos seus relatórios DMARC. Isso torna os problemas mais difíceis de encontrar.

Na prática, ~all é a escolha mais segura para um domínio que envia e-mail, principalmente enquanto você ainda descobre todos os seus remetentes. Se o seu DMARC está em quarantine ou reject, é ele que decide o que acontece com o e-mail que falha. Use -all em domínios que não enviam nenhum e-mail. Nunca use +all, que deixa todo servidor passar, e evite ?all, que equivale a não ter registro.

O que significa o resultado da verificação de SPF

Os servidores de destino usam termos próprios para o resultado de uma verificação SPF. Você os vê nos cabeçalhos das mensagens, como spf=pass ou spf=softfail, e nos relatórios DMARC:

Erros comuns no registro SPF e como corrigir

Uma análise de 12 milhões de domínios populares feita em 2023 encontrou SPF em 56,5% deles e erros em 2,9% dos registros SPF. O erro mais comum foi um include ou redirect apontando para um nome sem registro SPF. O excesso de consultas ficou em segundo lugar.

Dois registros SPF no mesmo domínio

Isso costuma acontecer quando o guia de um novo serviço diz “adicione este registro TXT” e alguém o adiciona ao lado do antigo. Dois registros causam um permerror. Junte os dois em um só. Comece com um v=spf1, liste todos os includes e endereços IP e termine com um único all.

Um include que não aponta para nada

Se um include aponta para um domínio sem registro SPF, o registro inteiro falha com um permerror. Pode ser um erro de digitação, ou um serviço que fechou ou mudou o include. Remova o include ou troque pelo valor atual do serviço.

+all, ?all ou nenhum all no final

+all autoriza todos os servidores da internet, então o registro não protege nada. ?all, ou a falta de all, dá um resultado neutro, que os servidores de destino tratam como ausência de registro. Termine o registro com ~all ou -all.

ptr no registro

A RFC 7208 diz que o ptr não deve ser usado. Ele é lento, gasta uma consulta e é menos confiável que outros mecanismos quando o DNS tem problemas. Troque-o por entradas ip4 e ip6 para os servidores que ele deveria cobrir.

Erros de digitação

Um espaço depois de dois-pontos, um endereço IPv4 incompleto ou uma palavra que o SPF não conhece causam um permerror. Um erro é mais discreto: include=example.com com sinal de igual é lido como uma configuração desconhecida e ignorado. Assim, aquele serviço nunca é autorizado. O verificador aponta todos esses casos.

Três detalhes que os guias de SPF costumam errar

• “Um registro SPF não pode ter letras maiúsculas.” A RFC 7208 diz que os nomes não diferenciam maiúsculas de minúsculas.
• “Um registro SPF pode ter no máximo 255 caracteres.” O limite de 255 vale para cada string. Um registro mais longo é dividido em strings. A RFC 7208 só pede que a resposta DNS inteira continue pequena, abaixo de cerca de 450 bytes.
• “Você pode ter até 10 includes.” O limite conta consultas DNS, e as consultas dentro dos includes também contam.

O SPF é uma parte da autenticação de e-mail

Um resultado pass no SPF tem limites. Na mesma análise de 2023, 34,7% dos domínios autorizavam e-mail de mais de 100.000 endereços IP. O SPF também quebra quando alguém encaminha sua mensagem, porque o servidor que encaminha não está no seu registro.

O DKIM assina a própria mensagem, então costuma sobreviver ao encaminhamento. O DMARC confere se o SPF ou o DKIM passou para o mesmo domínio do endereço From. Ele também diz aos servidores de destino o que fazer quando nenhum dos dois passou. Muitos serviços de envio passam no SPF com o próprio domínio de bounce, que não bate com o seu endereço From. Um Return-Path personalizado no serviço resolve isso. Configure os outros dois registros com o gerador de DKIM e o gerador de DMARC. Use a consulta MX para ver onde o seu domínio recebe e-mail.

A autenticação também não ajuda com endereços que não existem. E-mails para eles voltam como bounce, e uma taxa de bounce alta prejudica a entrega. Verifique endereços individuais com o verificador de e-mail, ou uma lista inteira com o validador de e-mail em massa. Se quiser uma definição curta para compartilhar com a equipe, veja o verbete sobre registro SPF no glossário.