Falha de SPF: entenda o erro e corrija rápido

Seu e-mail foi rejeitado. Os cabeçalhos mostram spf=fail. Um 550 5.7.1 ou 550 5.7.26 está diante de você, enquanto um cliente aguarda uma resposta que nunca chegou.

Uma falha de SPF não é um problema de conteúdo. É uma falha de autenticação de DNS. O servidor de e-mail destinatário consultou seu registro SPF, descobriu que o IP de envio não estava na lista autorizada e rejeitou a mensagem antes que ela pudesse chegar a uma pasta de spam.

Desde fevereiro de 2024, Google e Yahoo rejeitam e-mails não autenticados no nível do protocolo, em vez de apenas marcá-los como suspeitos. Este guia explica o código de erro específico, mostra onde encontrar o IP que falhou nos cabeçalhos e apresenta as três correções de DNS que resolvem a grande maioria das falhas de SPF. Sem adivinhação. Comece pela correção certa.

Se você está configurando o e-mail no seu domínio pela primeira vez, acerte a configuração básica de DNS antes de investigar falhas; os problemas de SPF quase sempre têm origem em uma configuração inicial incompleta.

O que é uma falha de SPF?

Uma falha de SPF acontece quando um servidor destinatário avalia o registro Sender Policy Framework do seu domínio e descobre que o endereço IP de envio não está autorizado. O SPF é publicado como um registro TXT de DNS no seu domínio e lista todos os endereços IP e serviços de e-mail autorizados a enviar em seu nome. Quando a verificação falha, o servidor rejeita a mensagem (falha rígida) ou a aceita como suspeita (falha branda). Nos dois casos, sua política DMARC contabiliza o resultado como falha.

O SPF verifica o remetente do envelope, o endereço MAIL FROM negociado durante a comunicação SMTP, não o cabeçalho "From" que o destinatário vê. Essa diferença importa ao rastrear a origem da falha.

Leia o código de erro antes de alterar qualquer coisa

Cada servidor de e-mail retorna códigos SMTP diferentes para uma falha de SPF. O código informa exatamente o que o destinatário decidiu e por quê; tratar um 550 5.7.26 da mesma forma que um 550 5.7.1 genérico desperdiça tempo de diagnóstico. Relacione o código à causa antes de alterar um único registro DNS.

Etapa 1: encontre o IP que falhou nos cabeçalhos

Não tente adivinhar qual IP causou a falha de SPF. Abra os cabeçalhos brutos da mensagem rejeitada (ou a própria notificação de rejeição) e procure Authentication-Results. Esse cabeçalho informa o IP exato que o destinatário avaliou e a decisão tomada.

Authentication-Results: mx.google.com;
   spf=fail (google.com: domain of team@example.com does not designate
   192.0.2.55 as permitted sender)

Dois dados de investigação estão ali: o IP de envio (192.0.2.55) e o domínio verificado (example.com). Agora identifique quem é o proprietário desse IP:

• Uma ferramenta SaaS que você adotou recentemente? (HubSpot, Zendesk, Shopify)
• Seu servidor web? (WordPress, cPanel)
• Um serviço de encaminhamento? (Veja abaixo a seção sobre a armadilha do encaminhamento)

Depois, confirme seu registro SPF atual com uma consulta rápida:

dig +short txt yourdomain.com | grep spf

Se houver mais de uma linha começando com v=spf1, você já encontrou um dos problemas.

Etapa 2: as três correções mais comuns para falhas de SPF

A maioria das falhas de SPF se resume a uma de três causas: falta o include de um provedor, há um registro duplicado ou o limite de 10 consultas DNS foi ultrapassado. Escolha a correção correspondente ao que encontrou na Etapa 1.

Correção 1: falta o include do provedor

Você adicionou uma nova ferramenta de e-mail, como HelpScout, HubSpot, Zendesk ou o e-mail transacional da Shopify, mas não atualizou o DNS. O serviço envia em seu nome usando um IP que você não autorizou. Essa é a causa mais comum de falha de SPF após a adoção de um novo provedor.

Registro com falha:

v=spf1 include:spf.trekmail.net -all

Registro aprovado (depois de adicionar o HelpScout):

v=spf1 include:spf.trekmail.net include:helpscoutemail.com -all

Encontre na documentação do provedor a string include de SPF necessária. Adicione-a ao registro TXT de SPF existente; não crie outro registro. Todo serviço usado para enviar precisa constar nele.

Correção 2: o registro duplo, um erro fatal de sintaxe

Só pode haver um registro SPF por domínio. Se você adicionar um segundo registro TXT para uma nova ferramenta em vez de integrá-lo ao existente, os destinatários verão duas políticas conflitantes e invalidarão ambas. O resultado é um PermError, uma falha rígida de SPF para todos os e-mails do domínio, inclusive os que antes eram entregues normalmente.

Errado: dois registros separados:

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

Certo: combinados em um:

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

Acesse seu provedor de DNS, exclua todos os registros TXT de SPF menos um e combine tudo em uma única linha. Um PermError causado por um registro duplo provoca uma falha silenciosa de SPF para todos os remetentes até que seja corrigido.

Correção 3: o limite de 10 consultas, uma falha de arquitetura

A RFC 7208 limita a avaliação de SPF a 10 consultas DNS. Isso evita que os servidores sejam usados para amplificar tráfego DNS. Mecanismos como include, a e mx contam para o limite, assim como includes aninhados, quando seu provedor inclui o registro de outro provedor.

Ao ultrapassar 10 consultas, você recebe PermError. O SPF falha para todos. Verifique o número atual de consultas seguindo seu registro:

dig +short txt yourdomain.com

Conte manualmente cada mecanismo include, a e mx, e depois siga os includes aninhados de cada provedor. Se você ultrapassar o limite, há duas opções claras:

1. Separe os remetentes em subdomínios. Transfira as ferramentas de marketing de alto volume para marketing.yourdomain.com. Esse subdomínio recebe seu próprio limite novo de 10 consultas, totalmente separado do registro do domínio principal.
2. Achate o registro. Substitua as cadeias include pelos IPs reais aos quais elas resolvem usando mecanismos ip4: ou ip6:. Eles não contam como consultas. A desvantagem é que você precisará atualizar o registro manualmente quando os provedores mudarem seus IPs.

Há ainda a armadilha do limite de consultas vazias. Se mais de duas consultas da cadeia retornarem NXDOMAIN, por exemplo, devido a um erro como include:spf.gogle.com, o registro será invalidado conforme a RFC 7208 §11.1. Um único erro de digitação em qualquer include aninhado pode comprometer toda a avaliação de SPF.

A armadilha do encaminhamento: por que o SPF falha em e-mails legítimos

Esta falha de SPF não tem relação com sua configuração de DNS. Você envia um e-mail para um endereço de ex-alunos (alice@university.edu), que o encaminha automaticamente para o Gmail (alice@gmail.com). O Gmail vê a mensagem chegando do IP do servidor da universidade. Seu registro SPF não autoriza esse IP. O SPF falha, embora você tenha feito tudo certo.

O caminho: Seu servidor → Servidor da universidade → Gmail. A verificação: o Gmail avalia o último salto. Não é possível corrigir falhas de encaminhamento com SPF, pois ele só autoriza o IP de envio original. Assim que um encaminhador intervém, a verificação do IP deixa de funcionar.

A correção certa é o DKIM. Ele assina criptograficamente o corpo e os cabeçalhos da mensagem. O encaminhador geralmente não altera o corpo, portanto a assinatura DKIM sobrevive ao salto de retransmissão. Mesmo com uma falha de SPF, uma assinatura DKIM válida permite que a mensagem passe pelo DMARC.

Se você gerencia encaminhamento no nível da infraestrutura e precisa de reescritas compatíveis com SPF, vale a pena entender o Sender Rewriting Scheme (SRS). Ele permite que os encaminhadores reescrevam o remetente do envelope para que o SPF seja aprovado no destino final. Para outras falhas de entrega relacionadas ao encaminhamento, o guia de configuração e correção do encaminhamento de e-mails apresenta todo o caminho de diagnóstico.

Verifique a correção antes de continuar

Depois de atualizar o registro DNS, aguarde a propagação; ela costuma levar de 5 a 30 minutos na maioria dos provedores, mas pode demorar algumas horas em casos específicos. Em seguida, verifique se a correção foi realmente aplicada antes de considerar o trabalho concluído.

Envie um e-mail de teste para um endereço do Gmail e abra os cabeçalhos brutos. Procure Authentication-Results. Este é o resultado desejado:

Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of team@example.com designates
   192.0.2.55 as permitted sender)

Se ainda aparecer spf=fail ou spf=softfail, talvez a correção não tenha se propagado ou o registro ainda tenha um problema. Compare o IP dos cabeçalhos com o do registro atualizado. Eles precisam coincidir.

Você também pode verificar o registro diretamente:

dig +short txt yourdomain.com

Confirme que haja exatamente um registro começando com v=spf1, que todos os seus serviços de envio estejam incluídos e que o registro termine com -all (falha rígida) ou ~all (falha branda).

Gerenciamento de SPF em vários domínios

Para um domínio, gerenciar o SPF é uma tarefa pontual. Adicione seus includes, combine os registros duplicados e corrija o número de consultas. Mas, se você administra o e-mail de 10, 50 ou 500 domínios, cada um com seu registro SPF e seu conjunto de provedores SaaS, investigar manualmente cada falha de SPF se torna uma carga operacional real.

O SMTP gerenciado da TrekMail, disponível a partir do Starter por $3.50/mo, reduz a configuração a um único include por domínio. A TrekMail cuida da rotação de IP, do monitoramento de rejeições, do alinhamento DKIM e da infraestrutura de entrega subjacente. No plano Agency ($23.25/mo), as agências aplicam um modelo de DNS padronizado a todos os domínios de clientes, em vez de procurar falhas de SPF em centenas de registros individuais.

Inicie uma avaliação gratuita de 14 dias para ver como funciona a entrega gerenciada na prática.

Falha de SPF: resumo

Uma falha de SPF significa que o servidor destinatário consultou seu DNS, constatou que o IP de envio não estava listado e aplicou sua política. Falha rígida (-all) significa rejeição. Falha branda (~all) geralmente significa pasta de spam. PermError significa que o registro está incorreto e o SPF falha para todos os remetentes até que o próprio registro seja corrigido.

Aplique as correções nesta ordem:

1. Encontre o IP que falhou no cabeçalho Authentication-Results
2. Adicione o include ausente se um novo serviço causou a falha de SPF
3. Combine os registros SPF duplicados em um
4. Reduza as consultas DNS para menos de 10 ou separe os remetentes de alto volume em subdomínios
5. Se o SPF falhar em e-mails encaminhados, implemente o DKIM; o SPF não sobrevive a um salto de retransmissão

Comece pela correção certa, verifique-a nos cabeçalhos e pronto.