Suas campanhas vão parar no spam e sua plataforma de e-mail marketing diz que está tudo OK? É uma das situações mais frustrantes para um email marketer: a taxa de entrega marca 98%, o open rate despenca e ninguém entende o porquê. A causa costuma ser um registro SPF ausente ou mal configurado na zona DNS do domínio remetente.
Um domínio sem SPF expõe seus e-mails a dois comportamentos automáticos dos servidores de recebimento: classificação como spam ou rejeição silenciosa no nível SMTP. Nenhum dos dois erros gera um bounce visível no seu painel. As mensagens são enviadas, parecem “entregues”, mas nunca chegam à caixa de entrada.
Adicionar um registro SPF válido leva menos de 10 minutos. O tempo de propagação DNS é a única variável fora do seu controle.
O que um registro SPF faz na prática
O servidor de e-mail do seu destinatário, antes mesmo de examinar o conteúdo da mensagem, consulta a zona DNS do seu domínio para verificar se o servidor que enviou o e-mail está autorizado a fazê-lo. Esse é o papel do SPF, ou Sender Policy Framework: uma linha de texto no seu DNS que lista os servidores autorizados a enviar em nome do seu domínio.
Se essa linha estiver ausente, o servidor de recebimento recebe uma resposta vazia. O que ele faz em seguida depende da sua política interna. O Gmail, desde novembro de 2025, rejeita ativamente os e-mails não conformes no nível SMTP para grandes volumes. Acabaram as “soft penalties”, é uma rejeição de verdade. O Microsoft Exchange é ainda mais rigoroso: exibe uma taxa média de inbox placement de 75,6% para domínios parcialmente autenticados, segundo dados do TrulyInbox (análise de 32.000+ contas, maio de 2026).
Sem nenhuma autenticação, os mesmos dados mostram um inbox placement que cai abaixo de 30%. Com apenas SPF, ele sobe para 55–70%. O stack completo SPF + DKIM + DMARC chega a 85–95%. A diferença entre “nada” e “tudo bem configurado” representa 60 pontos percentuais.
Por que o problema fica invisível por tanto tempo
Em abril, um responsável de growth percebe que seu open rate caiu de 32% para 18% em três meses. Nenhuma mudança no conteúdo, nenhuma notificação do ESP. A taxa de hard bounces continuava normal. O CMO quer uma explicação.
Esse cenário é documentado pelo relatório Suped 2025 (Whittaker, atualizado em maio de 2026): 43% das empresas apresentam inbox misses significativos enquanto suas plataformas exibem taxas de entrega superiores a 95%. A razão está na distinção entre “accepted” e “inboxed”: um e-mail pode ser aceito pelo servidor destinatário e parar no spam. Seu painel só enxerga a primeira etapa.
A sender reputation não se degrada instantaneamente. Nas primeiras semanas, o Gmail é relativamente tolerante. Mas cada envio fracassado alimenta os sinais negativos: complaint rate subindo, soft bounces se acumulando, usuários que param de clicar. Quando a reputação do IP começa a cair no Postmaster Tools, o SPF ausente já costuma ter causado danos há meses.
Como verificar se o seu SPF está ausente ou com problema
Três ferramentas funcionam bem para esse diagnóstico, cada uma com um ângulo diferente.
- MXToolbox SPF Lookup: insira seu domínio em mxtoolbox.com; o resultado indica se um registro SPF existe e se é sintaticamente válido. Tempo: 30 segundos.
- Google Postmaster Tools: se seu domínio envia para o Gmail, a aba “Authentication” exibe a taxa de e-mails que passam por SPF, DKIM e DMARC nos últimos 30 dias. Uma taxa SPF inferior a 95% indica um problema ativo.
- Um envio de teste via cabeçalhos brutos: envie um e-mail do seu domínio para um endereço Gmail, abra a mensagem e clique em “Mostrar original”. A linha Received-SPF indica
pass,softfail,failounone.noneconfirma a ausência do registro.
Se o MXToolbox retornar “No SPF Record Found” ou se o Postmaster Tools exibir uma taxa de autenticação SPF inferior a 90%, prossiga para a correção.
Criar um registro SPF válido: o método direto
Um registro SPF é um registro TXT na sua zona DNS. Sua sintaxe básica é a seguinte:
v=spf1 include:_spf.google.com ~all
O mecanismo include: aponta para os servidores autorizados do seu provedor de envio. Cada ESP fornece seu próprio valor. Alguns exemplos comuns:
| Provedor | Mecanismo include a adicionar | Caso de uso típico |
|---|---|---|
| Google Workspace | include:_spf.google.com |
Envio via Gmail corporativo |
| Brevo (ex-Sendinblue) | include:spf.brevo.com |
Campanhas de marketing |
| Mailchimp / Mandrill | include:spf.mandrillapp.com |
Transacional Mandrill |
| Amazon SES | include:amazonses.com |
Envio via AWS |
| OVHcloud MX Plan | include:mx.ovh.com |
Hospedagem compartilhada |
Se você usa vários provedores, combine-os em um único registro: v=spf1 include:_spf.google.com include:spf.brevo.com ~all. Atenção ao limite de 10 lookups DNS: cada mecanismo include: consome pelo menos um lookup, e alguns encadeiam outros. Ultrapassar esse limite quebra a autenticação SPF mesmo que a sintaxe esteja correta.
O valor final ~all (softfail) ou -all (fail estrito) define o que os servidores fazem com as mensagens não cobertas. Para um domínio com configuração estável, -all é preferível; durante a migração, fique com ~all até confirmar que nenhuma fonte legítima foi esquecida.
Adicionar o registro no seu DNS: os passos concretos
O procedimento varia levemente dependendo do registrar ou do provedor DNS, mas a lógica é a mesma em todos.
Acesse sua interface DNS (OVHcloud, Cloudflare, Gandi, Namecheap, GoDaddy). Localize a zona DNS do seu domínio principal. Adicione um novo registro do tipo TXT, com o nome @ (ou o domínio nu conforme a interface) e cole o valor SPF no campo “Valor” ou “Content”. Salve.
O Cloudflare propaga em geral em menos de 5 minutos. OVHcloud e Gandi podem levar de 30 minutos a algumas horas. Para verificar se a propagação está efetiva, rode novamente o MXToolbox ou use dig TXT seudominio.com em um terminal; quando o registro aparecer, está ativo.
Na prática, a configuração leva de 5 a 8 minutos no Cloudflare; o restante do tempo anunciado (10 minutos) corresponde ao diagnóstico inicial e à verificação pós-adição.
A objeção mais ouvida: “já uso Lemlist, Instantly — meu ESP cuida disso”
Plataformas de outreach como Lemlist, Instantly ou Smartlead configuram sua própria infraestrutura de envio e podem adicionar seu mecanismo SPF no seu DNS por meio de um assistente de onboarding. Mas esse mecanismo cobre apenas os envios feitos pelos servidores delas. Se seu domínio também envia via Google Workspace, um servidor SMTP interno ou outra ferramenta transacional, esses fluxos não estão cobertos pelo include do seu ESP.
Um registro SPF cobre todas as fontes autorizadas para um dado domínio. O erro clássico: um domínio configurado para Lemlist, sem include para o Google Workspace, que vê seus e-mails de cobrança ou suporte pararem no spam porque o servidor do Google não está listado.
“As SPF misconfigurations afetam 15% dos domínios que têm um SPF ativo.” (dmarcian, citado por TrulyInbox, maio de 2026)
Ter um SPF não basta se a lista de fontes autorizadas estiver incompleta ou se os 10 lookups DNS forem ultrapassados.
O que o SPF não resolve sozinho
Um SPF corretamente configurado melhora a autenticação do remetente, mas não assina o conteúdo da mensagem. Esse é o papel do DKIM, que utiliza um par de chaves criptográficas para provar que o e-mail não foi alterado em trânsito. Sem DKIM, os dados do TrulyInbox mostram uma penalidade adicional de 10 a 15 pontos de inbox placement.
O DMARC, por sua vez, usa SPF e DKIM juntos para definir uma política: o que fazer se um e-mail falhar nos dois controles? Rejeitar, colocar em quarentena ou não fazer nada (apenas monitoramento). Sem DMARC, mesmo um SPF e DKIM corretos deixam seu domínio vulnerável ao spoofing e, principalmente, você não tem nenhum relatório agregado para detectar anomalias. Em 2026, 78% das organizações conhecem o DMARC, mas apenas 42% o aplicam de fato com uma política estrita (Valimail, State of DMARC 2026).
Começar pelo SPF continua sendo a prioridade, pois é o pré-requisito técnico dos outros dois. Mas um SPF sozinho coloca seu inbox rate entre 55 e 70%. A list hygiene e o IP warming fazem o resto.
O Gmail agora rejeita os e-mails não autenticados no nível SMTP. O registro TXT no DNS é a única variável que você controla por completo.
