Como configurar SPF corretamente (e o erro que ninguém vê)

O SPF é um registro de texto publicado no DNS do seu domínio dizendo quais servidores podem enviar e-mail em nome dele. Quando uma mensagem chega ao destinatário, o servidor dele consulta esse registro, compara com o endereço IP de quem está entregando e decide se aquilo faz sentido.

Publicar é rápido. O que dá errado com frequência é o que vem depois: um serviço novo que ninguém incluiu, dois registros no mesmo domínio, ou o limite de consultas DNS estourado em silêncio.

Antes de escrever o registro: levante quem envia

Este é o passo que economiza retrabalho. Liste tudo o que envia e-mail usando o seu domínio no remetente — e a lista quase sempre é maior do que a memória sugere:

• o servidor de e-mail da empresa (Microsoft 365, Google Workspace, Zimbra, cPanel);
• o sistema de gestão que dispara nota fiscal, boleto e cobrança;
• o formulário de contato do site;
• a ferramenta de e-mail marketing, se houver;
• o sistema de RH, o de chamados, o de assinatura eletrônica;
• qualquer serviço contratado por outro setor que você talvez não conheça.

Se você já publicou DMARC com p=none e um endereço em rua, os relatórios diários mostram exatamente essa lista — inclusive o que ninguém lembrava. É por isso que a ordem recomendada é DMARC em modo observação primeiro, ajuste do SPF depois.

A anatomia do registro

Um SPF simples, para quem usa só o Google Workspace:

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

Lendo em português: “versão 1 do SPF; autorize o que o Google autorizar; para o resto, aceite marcando como suspeito”.

Termo	O que faz	Custa consulta DNS?
v=spf1	Obrigatório, sempre primeiro	não
ip4:200.1.2.3	Autoriza um IPv4 ou uma faixa	não
ip6:2001:db8::/32	Autoriza um IPv6 ou uma faixa	não
include:dominio	Incorpora o SPF de um serviço	sim
a	Autoriza os IPs do registro A do domínio	sim
mx	Autoriza os IPs dos servidores MX	sim
-all / ~all	O que fazer com o resto	não

O qualificador do final

O all é o que fecha o registro e define a política para quem não casou com nenhuma regra:

• -all (fail) — recuse. É o objetivo final.
• ~all (softfail) — aceite, mas marque como suspeito. É onde começar.
• ?all (neutral) — sem opinião. Na prática, o SPF deixa de proteger.
• +all — autoriza o mundo inteiro. Nunca use: anula completamente o SPF.

Comece com ~all, acompanhe por algumas semanas, e mude para -all quando tiver certeza de que todos os seus remetentes legítimos estão cobertos.

O limite de 10 consultas — o erro que ninguém vê

Este é o problema mais comum e o mais silencioso. A RFC 7208 determina que a avaliação de um SPF não pode custar mais de 10 consultas DNS. Passando disso, o resultado é permerror — e boa parte dos provedores trata isso como falha.

O detalhe cruel é que a contagem é em cascata. Um include: que por sua vez tem três include: dentro dele consome quatro consultas, não uma. Um registro com cinco serviços pode facilmente passar de dez sem que nada pareça errado ao olhar o texto.

O validador de SPF deste site segue toda a cadeia e mostra o número real. Se você estiver acima do limite, na ordem:

1. Remova o que não usa mais. Costuma ser a maior parte do excesso — serviços contratados no passado que ficaram no registro.
2. Troque include por ip4 nos serviços que têm IP fixo e publicado.
3. Pergunte ao provedor se ele tem um include mais enxuto. Alguns oferecem.
4. Considere um subdomínio para envio em massa (news.empresa.com.br), com SPF próprio. Assim o domínio principal fica leve.

Erros que aparecem toda semana

Dois registros SPF no mesmo domínio

A RFC permite apenas um. Com dois, o resultado é permerror e a verificação falha para todos os seus envios, mesmo que cada registro esteja correto sozinho. Acontece quando alguém adiciona um novo em vez de editar o existente. A correção é juntar tudo em um só:

❌ v=spf1 include:_spf.google.com ~all
❌ v=spf1 include:servidor.com.br ~all

✅ v=spf1 include:_spf.google.com include:servidor.com.br ~all

Publicar no subdomínio errado

O SPF do domínio vai no próprio domínio, com o nome @ ou vazio, dependendo do painel — nunca em spf.empresa.com.br.

Achar que o SPF cobre o que aparece para o usuário

O SPF valida o endereço do envelope, não o campo “De” que o destinatário vê. É possível passar em SPF e ainda assim exibir outro remetente. Quem amarra as duas coisas é o DMARC, por meio do alinhamento.

Por que o SPF sozinho não basta

O SPF quebra em qualquer encaminhamento. Quando alguém redireciona automaticamente a sua mensagem para outro endereço, quem entrega passa a ser o servidor de quem encaminhou — que não está no seu SPF. A mensagem é legítima e mesmo assim falha.

Não é defeito de configuração, é uma limitação do próprio mecanismo. A solução é publicar também DKIM, cuja assinatura viaja junto com a mensagem e sobrevive ao encaminhamento, e depois DMARC para amarrar os dois.

Conferindo

Alterações de DNS levam o tempo do TTL antigo para se propagar. Depois disso, rode o validador de SPF e confira três coisas: existe apenas um registro, a contagem de consultas está abaixo de dez, e o final é ~all ou -all.

Para ver SPF, DKIM, DMARC, MX e reputação de uma vez, use o diagnóstico completo.