SPF em Email Marketing: O Que É e Como Configurar sem Erro

Lista limpa foi o primeiro pilar. O próximo é autenticação — e o primeiro tijolo é o SPF (Sender Policy Framework): um registro no DNS que diz quais servidores podem mandar email em nome do seu domínio.

Sem SPF, ou com SPF torto, Gmail, Outlook e o resto tratam a campanha com desconfiança. Não é “detalhe de TI”. É pré-requisito de entregabilidade de email marketing.

Este é o post 3 da série: o que é SPF, como ler um registro, os erros que mais aparecem e um checklist pra validar antes do próximo disparo. DKIM e DMARC vêm na sequência — os três trabalham juntos.

O que é SPF (em português de operação)

SPF é uma política publicada no DNS. Quando o email chega, o provedor pergunta: “esse servidor que está entregando a mensagem está autorizado pelo dono do domínio?”

• Se sim → SPF passa (com nuance de pass / softfail / fail).
• Se não → sinal ruim. Sozinho quase nunca “mata” tudo, mas combina mal com reputação frágil e falta de DKIM/DMARC.

Um detalhe que confunde: SPF autentica o envelope (Return-Path / Mail From), não necessariamente o nome bonito do From. Por isso o alinhamento com DKIM/DMARC importa — a gente aprofunda no post de DMARC.

Por que SPF importa no email marketing

1. Prova básica de legitimidade — dificulta spoofing barato no seu domínio.
2. Sinal pra filtros — domínio sem SPF parece amador ou abandonado.
3. Base do DMARC — DMARC se apoia em SPF e/ou DKIM alinhados.
4. ESP + domínio próprio — se você manda por RD Station, ActiveCampaign, Brevo, Amazon SES e afins, o IP/include deles precisa estar no SPF.

From @suaempresa.com.br sem autorizar o ESP no DNS é pedido de softfail.

Anatomia de um registro SPF

SPF vive num registro TXT (às vezes legado como tipo SPF) no domínio ou no subdomínio de envio.

Exemplo ilustrativo:

v=spf1 include:_spf.google.com include:spf.seuesp.com -all

Pedacos que você vai ver o tempo todo:

Pedaco	Significado
v=spf1	Versão — obrigatório no começo
ip4: / ip6:	Autoriza IP específico
include:	Puxa a política de outro domínio (comum em ESP)
a / mx	Autoriza IPs dos registros A ou MX do domínio
~all	Softfail — não autorizado, mas não rejeita seco
-all	Fail — não autorizado deve falhar
?all	Neutro — quase inútil na prática

Regra simples: um domínio, um SPF utilizável. Vários TXT v=spf1 = configuração quebrada.

Como montar o SPF do seu envio (passo a passo)

1. Lista quem envia pelo domínio: ESP de marketing, transacional, Google Workspace / Microsoft 365, helpdesk, CRM.
2. Pega o include oficial de cada um (doc do provedor — não inventa).
3. Publica um único TXT juntando os includes necessários.
4. Espera a propagação DNS (minutos a algumas horas).
5. Testa com lookup + envio real pra Gmail/Outlook e lê os headers (Received-SPF, Authentication-Results).

Exemplo mental (marketing + Google)

v=spf1 include:_spf.google.com include:spf.provedor-de-email.com ~all

Ajusta ao que a doc do seu ESP manda. Copiar include de concorrente não funciona.

Erros clássicos que quebram SPF (e a entregabilidade)

1. Dois registros SPF no mesmo nome — um sobra, o outro confunde; na prática, falha.
2. Mais de 10 lookups DNS — SPF tem limite; include encadeado demais estoura (permerror). Consolida.
3. Esquecer o ESP novo — migrou de ferramenta e deixou o include antigo / não botou o novo.
4. +all — autoriza o mundo. Nunca.
5. ~all eterno sem DMARC — softfail “perdoa” demais; depois combina com DKIM+DMARC.
6. DNS no lugar errado — From em @mail.suaempresa.com e SPF só no apex (ou o contrário).
7. Achar que SPF sozinho tira do spam — não limpa lista suja nem mata reclamação. O pilar 1 (lista) continua valendo.

SPF passou… e o email ainda foi pro spam?

Acontece. SPF é necessário, não suficiente.

Olha em paralelo:

• Lista e reclamações (post 2)
• DKIM assinado e alinhado (próximo post)
• DMARC com política coerente
• Reputação de domínio/IP
• Conteúdo e engajamento

Autenticação abre a porta. Reputação e lista decidem se você fica na sala.

SPF no dia a dia com ESP brasileiro

Na operação real, SPF quase nunca é “só o seu servidor”. É o include do ESP + o do Google/Microsoft + às vezes o do transactional.

Antes de publicar:

• Confirma no painel do ESP o domínio de envio e o TXT exato sugerido.
• Se usa subdomínio (mail., news.), publica o SPF nele, não só no apex.
• Depois de mudar DNS, não dispara blast gigante no mesmo minuto — valida headers em endereços de teste.

Se o lookup mostrar permerror, para tudo: quase sempre é SPF duplicado ou estouro de lookups. Campanha em cima de permerror é tiro no pé.

Checklist: esta semana

1. Faz lookup do TXT do domínio de envio — existe um v=spf1?
2. Confere se todos os serviços que disparam estão no include/IP.
3. Remove SPF duplicado.
4. Evita estourar o limite de lookups.
5. Manda um teste e lê Authentication-Results (SPF pass?).
6. Anota pendências pra DKIM e DMARC (posts 4 e 5).

FAQ

SPF é obrigatório?

Na prática, sim pra quem leva entregabilidade a sério. Domínio de marca enviando sem SPF é sinal vermelho hoje em dia.

~all ou -all?

Muita gente começa com ~all enquanto estabiliza DKIM/DMARC. Com DMARC maduro, -all (ou a política DMARC equivalente) fica mais seguro. Não muda pra -all no escuro se ainda tem remetente legítimo fora do registro.

Preciso de SPF no subdomínio?

Se o From / Return-Path usa subdomínio (news@, mail.), a política precisa cobrir esse nome. Herança não é mágica — publica onde o envio acontece.

SPF substitui DKIM?

Não. São mecanismos diferentes. O combo + DMARC é o padrão atual.

Próximo passo

SPF diz quem pode falar em nome do domínio no caminho do envelope. No próximo post: DKIM — a assinatura que viaja com a mensagem e sobrevive a muita coisa no caminho (incluindo encaminhamento).

Enquanto isso: um domínio, um SPF, includes certos, teste nos headers. Sem isso, o resto da autenticação já começa torto.