Por que o seu email falha no SPF? Lendo o registro que os servidores conferem

Um cabeçalho diz spf=fail numa mensagem que você com certeza enviou. A sua plataforma de email diz que o SPF está configurado. As duas coisas podem ser verdade ao mesmo tempo, porque o SPF não verifica o remetente que você vê na caixa de entrada, e porque um registro que parece correto ainda pode ser inválido no instante em que um servidor de destino o avalia.

O SPF é a primeira checagem de identidade que a maioria dos servidores de destino roda, e é a que mais costuma estar errada de um jeito que parece tudo bem até uma mensagem específica falhar.

Quase toda falha é um de três formatos: dois registros SPF no mesmo domínio, o que é inválido e devolve permerror; uma ferramenta adicionada sem atualização no DNS, que falha só no email dela; ou o limite de dez lookups de DNS, que derruba tudo de uma vez. Esses três formatos são detalhados em quais erros de SPF aparecem com mais frequência. Ler o registro primeiro é o que revela qual deles você tem.

O que o SPF realmente verifica?

O SPF responde a uma pergunta: esta mensagem veio de um servidor que o seu domínio declara autorizado a enviar?

Ele não prova que a mensagem não foi alterada. Isso é papel do DKIM. Ele não diz aos servidores de destino o que fazer quando as checagens falham. Isso é papel do DMARC. O SPF é uma lista de permissões publicada no DNS, e os servidores que recebem consultam essa lista quando o email chega.

A consulta usa duas informações:

1. O domínio do remetente do envelope (o endereço MAIL FROM, geralmente escondido no cabeçalho Return-Path).
2. O endereço IP do servidor que se conectou para entregar a mensagem.

Se o IP está autorizado pelo registro SPF daquele domínio, o servidor registra spf=pass. Se não está, você recebe fail, softfail ou permerror, dependendo de como o registro está escrito e de se o próprio registro é válido.

O que o SPF não faz: ele não verifica o endereço From visível que o leitor vê. Uma mensagem pode mostrar you@yourbrand.com na caixa de entrada enquanto o remetente do envelope é bounce@esp-vendor.net. O SPF avalia apenas o domínio do envelope contra o IP que conectou. Essa lacuna é o motivo de existir o alinhamento do DMARC, e de o SPF sozinho nunca impedir a falsificação de nome de exibição.

Se o email está caindo no spam e você ainda não leu cabeçalhos, comece pelo diagnóstico sem desespero e siga as checagens de identidade em ordem. O SPF é o primeiro passo desse caminho.

Como é um registro SPF de verdade?

Um registro SPF válido é uma única resposta TXT no domínio raiz (ou no subdomínio de onde você envia). Ele sempre começa com v=spf1 e termina com um qualificador no all:

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

Leia da esquerda para a direita:

Token	Significado
v=spf1	Marcador de versão. Obrigatório. Sem ele, o registro é ignorado.
include:_spf.google.com	Segue o SPF publicado pelo Google e trata os IPs autorizados por ele como autorizados para você. Isso custa um lookup de DNS.
include:sendgrid.net	O mesmo vale para o SendGrid. Mais um lookup.
~all	Soft fail: o que não estiver listado é suspeito, mas não é rejeição automática em todos os servidores de destino.

O mecanismo include: é como a maioria das ferramentas SaaS fica autorizada sem você listar dezenas de faixas de IP à mão. O seu registro aponta para o delas; o registro delas lista os IPs.

Outros mecanismos que aparecem no mundo real:

• ip4:198.51.100.0/24 autoriza diretamente uma faixa IPv4 específica (sem lookup extra).
• a ou mx autoriza os hosts A ou MX do domínio.
• redirect=otherdomain.com delega a política inteira para o SPF de outro domínio (incomum; use com cuidado).

Um registro com apenas v=spf1 ~all é tecnicamente válido e inútil: ele não autoriza ninguém explicitamente, então tudo sofre softfail. Um registro com +all é pior: autoriza a internet inteira e sinaliza erro de configuração para os filtros que prestam atenção.

Se você está montando um registro do zero, o SPF generator cria um único TXT válido a partir dos remetentes que você realmente usa. Rode o registro pronto no email health check antes de dar o trabalho por terminado.

Qual é a diferença entre softfail e hardfail?

O qualificador no all é a política para todo mundo que não está listado explicitamente:

• ~all (softfail): “Provavelmente não autorizado.” Muitos servidores de destino tratam isso como um sinal negativo, mas ainda aceitam a mensagem se o DKIM passa e a reputação está limpa.
• -all (hardfail): “Não autorizado.” Sinal mais forte. Alguns servidores rejeitam de imediato; outros ainda aceitam com DKIM e DMARC suficientes.
• ?all (neutral): “Nada declarado.” Raro na prática; não use em um domínio de onde você envia.
• +all (pass all): Nunca use isso em um domínio de produção.

A maioria dos pequenos remetentes publica ~all enquanto ainda descobre cada ferramenta que envia no lugar dela. Passe para o -all só quando a lista de includes estiver completa e os relatórios de DMARC mostrarem nenhuma origem inesperada por algumas semanas.

A diferença prática aparece nos cabeçalhos. Um softfail costuma ler spf=softfail mesmo quando a mensagem é aceita. Um hardfail em um domínio com DKIM fraco é um caminho comum para o email cair em pasta de promoções ou lixo. Nenhum dos dois substitui a política do DMARC; são entradas para o placar do servidor de destino, não comandos. Antes de mudar a sua política, confira essas linhas nos cabeçalhos de uma mensagem real.

Quais erros de SPF aparecem com mais frequência?

Três formatos cobrem a maioria das falhas de SPF do mundo real.

Dois registros SPF no mesmo domínio. O DNS devolve duas respostas TXT separadas que começam com v=spf1. A RFC 7208 diz que isso é inválido: os servidores não devem mesclá-las, e muitos devolvem permerror, o que falha a checagem inteira. A correção é um registro que combina todos os remetentes autorizados. Apague a duplicata; não empilhe.

Uma ferramenta adicionada, DNS nunca atualizado. Automação de marketing, ticketing, CRM e faturamento: todas essas ferramentas enviam email. Cada uma precisa de um include: ou de uma faixa de IP. O sintoma é a falha seletiva: o email do Google Workspace passa, o da ferramenta nova sofre softfail porque os IPs dela nunca foram autorizados.

O limite de dez lookups. Cada include: e a maioria dos outros mecanismos custa um lookup de DNS enquanto o servidor avalia o registro. Passando de dez lookups, o resultado é permerror. Os includes aninhados dentro dos registros das ferramentas contam no seu limite mesmo quando você nunca mexeu no DNS. Se você está perto do limite, o SPF flattener mostra a árvore completa e a contagem acumulada.

Menos comuns, mas vale conhecer: SPF no hostname errado (publicar em mail.example.com enquanto o envelope usa example.com) e entradas ip4: desatualizadas depois que um provedor muda faixas de endereço sem aviso. Se uma dessas aparecer, confirme o hostname e as faixas publicadas antes de mexer em qualquer outro registro.

Como conferir e corrigir o seu em cinco minutos?

Trabalhe a partir do domínio do envelope, não do endereço From visível.

1. Envie uma mensagem de teste de cada plataforma que você usa (email do workspace, ESP, provedor transacional).
2. Abra o código-fonte original da mensagem e procure Return-Path ou smtp.mailfrom= no Authentication-Results. Esse domínio é o que o SPF avalia.
3. Consulte: dig +short TXT example.com e confirme que você recebe exatamente uma resposta começando com v=spf1.
4. Leia o Received-SPF ou a linha do SPF dentro do Authentication-Results na mensagem de teste. pass significa que aquele caminho está autorizado. fail, softfail ou permerror significa corrigir o registro ou a configuração de envio antes de mexer no texto ou nos templates.
5. Se falta um remetente no registro, adicione o include: documentado pela ferramenta e remova qualquer TXT SPF duplicado que encontrar no mesmo nome.

Para um retrato de um único domínio sem ler cabeçalhos, o email health check devolve os vereditos de SPF, DKIM e DMARC numa passada só.

O que fazer a seguir

O SPF é uma das três pernas do banco. Publique assinaturas DKIM de cada plataforma de envio e depois o DMARC, para que os servidores de destino saibam o que fazer quando o SPF e o DKIM não alinham com o seu domínio From visível. Criadores e negócios de cursos costumam rodar três ou quatro ferramentas no mesmo domínio; agências rodam esse problema em escala, em várias zonas de clientes.

Depois que o registro de hoje estiver limpo, coloque a checagem na agenda. Registros de autenticação ficam desatualizados quando o DNS muda e ninguém atualiza o TXT. Uma passada semanal pega esse desajuste antes de a entregabilidade reclamar; o fluxo completo está na revisão semanal de entregabilidade.

Checklist

1. Confirme um único TXT SPF no domínio que o seu remetente de envelope usa.
2. Liste todos os sistemas que enviam email no seu lugar e faça cada um corresponder a um include: ou ip4: naquele registro.
3. Mantenha o ~all até os relatórios de DMARC mostrarem nenhuma origem surpresa, e então considere o -all.
4. Teste cada caminho de envio e leia o Authentication-Results numa mensagem real.
5. Corrija o permerror antes de perseguir causas de reputação ou de conteúdo.