O que é registro SPF? Sintaxe, limites e falhas comuns

O que é registro SPF? É um único registro DNS do tipo TXT, publicado no domínio, que lista os servidores autorizados a enviar e-mail usando esse domínio no envelope do remetente. O servidor receptor lê esse registro, compara o IP que se conecta com a lista e devolve pass, fail, softfail ou neutral. O SPF autentica o caminho de envio, não a mensagem, e não diz nada sobre o endereço From que uma pessoa lê na tela.

Essa diferença explica a maior parte dos chamados de SPF que vemos nos traces.

Um registro SPF é uma lista de remetentes publicada no DNS

SPF significa Sender Policy Framework, especificado na RFC 7208. O registro é uma entrada TXT na raiz do domínio que começa com v=spf1. Um exemplo mínimo:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Leia da esquerda para a direita. O receptor verifica cada termo em ordem e para na primeira correspondência. O termo final all pega tudo o que não bateu antes.

O domínio verificado não é o cabeçalho From. É o domínio do comando MAIL FROM do SMTP, também chamado de envelope sender ou Return-Path. Se ele estiver vazio, como em bounces, o receptor usa o nome do HELO.

Os mecanismos: ip4, ip6, a, mx, include e exists

Cada termo é um mecanismo, opcionalmente precedido por um qualificador. Seis cobrem quase todos os registros reais.

• ip4: e ip6: comparam com um endereço literal ou uma faixa CIDR. Não custam consultas.

• a compara com os registros A e AAAA do domínio. Custa uma consulta.

• mx compara com os hosts dos registros MX. Custa uma consulta, mais uma por host.

• include: compara com tudo o que o registro SPF de outro domínio autoriza. Custa uma consulta, mais tudo o que estiver aninhado dentro dele.

• exists: compara com qualquer registro A de um nome montado na hora. Custa uma consulta.

• ptr compara com o reverse DNS do IP conectado. Custa consultas, e a RFC 7208 desaconselha o uso.

Os qualificadores definem o resultado quando um termo bate. + é pass e é o padrão, - é fail, ~ é softfail, ? é neutral. Assim, -all significa "rejeite tudo o que não está listado", e ~all significa "aceite, mas marque".

Prefira ip4: e ip6: sempre que você controlar o endereço. Eles não custam consultas e não quebram quando o DNS de outra empresa muda.

O limite de 10 consultas DNS é o que quebra registros reais

A RFC 7208 limita uma avaliação SPF a 10 termos que disparam consultas DNS: include, a, mx, ptr, exists e o modificador redirect. Includes aninhados também contam. Acima de 10, o resultado é permerror, e a verificação falha de forma permanente em vez de cair num padrão.

Há um segundo limite menos citado. Termos que retornam resposta vazia ou NXDOMAIN são consultas vazias (void lookups), e a especificação manda parar em duas. Um include: antigo apontando para um fornecedor que você abandonou no ano passado é uma consulta vazia pela qual você continua pagando.

Veja como as equipes chegam ao teto na prática. O Google Workspace ocupa um include. Um provedor transacional ocupa outro. Uma plataforma de marketing ocupa um, e ainda aninha três dentro dele. Uma central de suporte, um CRM e uma ferramenta de cobrança somam mais quatro. Você chega a 11 sem ter feito nada fora do comum.

A falha é silenciosa. As mensagens continuam saindo, e alguns receptores ainda entregam, mas o SPF já não autentica nada para você. Se o alinhamento DMARC depende do SPF, esse caminho some até você achatar o registro ou remover remetentes.

Existem três correções, em ordem de preferência:

1. Remova os remetentes que você não usa mais. Audite os includes com os relatórios agregados DMARC dos últimos 90 dias.

2. Mova o tráfego em massa para um subdomínio, como mail.example.com, com registro SPF próprio e orçamento próprio de 10 consultas.

3. Achate os includes em faixas ip4: literais, mas apenas com automação. Fornecedores rotacionam IPs, e um registro achatado à mão fica desatualizado sem nenhum alerta.

Publique exatamente um registro SPF por domínio

Um domínio não pode publicar dois registros SPF. Se o receptor encontrar duas entradas TXT com v=spf1, o resultado é permerror, como no limite de consultas. Isso acontece quando uma pessoa adiciona um registro para uma ferramenta nova enquanto outra já tinha publicado o seu.

A correção é mecânica. Junte os termos num único registro, com um v=spf1 no início e um all no fim. Tudo o que a documentação do fornecedor pedir entra dentro do registro existente como mais um include:, nunca como uma nova entrada TXT.

Duas armadilhas menores. Uma string TXT com mais de 255 caracteres precisa ser dividida em várias strings entre aspas dentro do mesmo registro, o que a maioria dos provedores de DNS faz para você. E mantenha a resposta inteira abaixo de cerca de 450 bytes sempre que possível, porque respostas maiores podem cair do UDP para TCP, e alguns resolvedores lidam mal com isso.

Softfail ou hardfail: escolha com base no que você consegue ver

O termo all é uma declaração de política, e o conselho padrão ("use -all") pula justamente a parte que importa. Um hard fail só é seguro quando você conhece todos os remetentes legítimos.

Nossa regra prática, tirada da leitura de traces:

• ~all enquanto você ainda faz o inventário de remetentes, ou se encaminha e-mails e não controla o caminho.

• -all quando os relatórios DMARC mostrarem que todas as fontes legítimas passam por algumas semanas.

• Nunca +all, que autoriza a internet inteira, e nunca ?all num domínio de produção.

Na prática, a diferença é menor do que se imagina. A maioria dos grandes receptores trata o SPF como um sinal entre vários, e com uma política DMARC publicada o veredito do DMARC é o que decide. Ainda assim, um -all num registro incompleto é a forma mais rápida de perder notas fiscais.

O SPF quebra no encaminhamento, e isso é por design

O SPF valida o IP que se conectou ao servidor receptor. Quando uma mensagem é encaminhada, redistribuída por uma lista de discussão ou retransmitida por um serviço de alias, o IP conectado é o do encaminhador, não o seu. A verificação SPF falha mesmo sem você ter feito nada de errado.

Não há como corrigir isso dentro do SPF. Por isso o DKIM existe ao lado dele: a assinatura sobrevive ao salto, uma lista de IPs não sobrevive. Um domínio que depende só do SPF verá falhas de autenticação em toda mensagem encaminhada.

Por isso o SPF sozinho também não satisfaz o DMARC para e-mails encaminhados. Conte com o DKIM para levar essas mensagens.

Alinhamento SPF: passar não é o mesmo que bater com o domínio From

Uma mensagem pode passar no SPF e ainda falhar no DMARC. O DMARC exige que o domínio que passou no SPF, o domínio do Return-Path, seja igual ao domínio do From visível. Muitos provedores compartilhados usam por padrão o próprio domínio de bounce, então o SPF passa para provedor-mail.net e não diz nada sobre example.com.

Verifique isso nos cabeçalhos brutos. Na linha Authentication-Results, procure smtp.mailfrom=. Se ele não for o seu domínio ou um subdomínio dele, o SPF está passando sem ajudar você.

O remédio é um Return-Path personalizado num subdomínio seu, algo que os remetentes sérios costumam suportar. Postmark, Resend, Mailgun e SendGrid documentam essa configuração, embora nem sempre ela venha ativada por padrão.

Os provedores de caixa de entrada agora exigem autenticação de todo remetente

Desde fevereiro de 2024, o Google exige que todos os remetentes se autentiquem com SPF ou DKIM, e quem envia mais de 5.000 mensagens por dia para o Gmail precisa ter SPF, DKIM e DMARC configurados. Os detalhes estão nas diretrizes do Google para remetentes de e-mail. O Yahoo definiu regras equivalentes na mesma época.

Isso tirou o SPF da categoria "seria bom ter" e o colocou entre os pré-requisitos de entrega. Um registro ausente ou quebrado agora aparece como rejeição e spam, não apenas como uma nota de reputação mais baixa.

Nossa leitura depois de alguns anos de traces: as regras pegam sobretudo domínios sem autenticação nenhuma e remetentes com taxa alta de reclamação de spam. Um registro SPF correto sozinho não coloca você na caixa de entrada, mas um registro ausente mantém você fora.

Como verificar e corrigir um registro SPF em quatro passos

Faça estes passos na ordem e verifique de novo após cada mudança no DNS.

1. Consulte o registro atual. Rode dig +short TXT example.com e encontre a entrada que começa com v=spf1. Se houver duas, junte-as.

2. Conte as consultas. Some include, a, mx, exists, redirect e tudo o que está aninhado nos includes. Se você estiver em 8 ou mais, planeje a limpeza agora, e não no 11º.

3. Liste os remetentes reais. Use os relatórios agregados DMARC ou os cabeçalhos Authentication-Results de envios de teste. Adicione só as fontes que aparecem.

4. Envie um teste e leia o cabeçalho. O resultado deve mostrar spf=pass com smtp.mailfrom no seu domínio.

Mudanças de DNS levam tempo para se propagar, e o TTL do registro atual define quanto tempo as respostas antigas sobrevivem. Reduza-o para 300 segundos um dia antes de uma mudança planejada.

Um registro completo para uma empresa SaaS com três remetentes

Imagine um produto que envia pelo Google Workspace, por um provedor transacional e por uma central de suporte. Um registro limpo fica assim:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

São três includes, e cada um esconde consultas aninhadas. Conte antes de publicar, porque o tamanho visível do registro não diz nada sobre o orçamento real. Um registro com três includes já pode estar em 7 ou 8 consultas.

Agora separe por finalidade. Mantenha o e-mail humano no domínio raiz. Coloque as notificações do produto em notify.example.com, com um registro que liste apenas o provedor transacional. O registro raiz fica curto, o subdomínio ganha orçamento próprio de 10 consultas, e um problema de reputação num fluxo deixa de arrastar o outro.

Essa separação também torna os relatórios DMARC legíveis. Cada fluxo tem seu próprio domínio de Return-Path, então uma falha aponta para um remetente, e não para um monte deles.

O que o SPF não faz

Ele não impede alguém de falsificar o seu endereço From, porque nunca olha esse cabeçalho. Não criptografa nada. Não explica por que uma mensagem caiu no spam. E não escala além do orçamento de 10 consultas sem manutenção contínua.

Trate-o como um de três registros que você publica juntos: SPF para o caminho de envio, DKIM para a integridade da mensagem, DMARC para a política que amarra os dois ao seu domínio From. Se você tem SPF e mais nada, o próximo passo concreto é publicar um registro DMARC com p=none e ler os relatórios por duas semanas.