Você encontrou um gerador de registros SPF gratuito, marcou todas as opções, Google Workspace, Mailchimp e seu CRM, e colou o resultado diretamente no DNS. Duas semanas depois, o Gmail rejeita suas faturas com 550 5.7.26. O Outlook retorna 550 5.7.515. Sua fila de suporte está cheia.
O gerador produziu um resultado com sintaxe válida. Não produziu um registro operacional. É exatamente nessa diferença que a entregabilidade é prejudicada. Se você ainda está montando toda a estrutura de DNS, comece por configurar o e-mail no seu domínio; o SPF faz parte de um conjunto mais amplo com MX, DKIM e DMARC.
Este guia explica por que os geradores automatizados falham em produção, como auditar o resultado em cinco minutos usando ferramentas que você já tem e como é um registro SPF pronto para produção.
O que um gerador de registros SPF realmente faz
Um gerador de registros SPF é uma ferramenta web que cria um registro TXT de DNS concatenando mecanismos include: específicos de cada provedor conforme as opções selecionadas. Você escolhe os remetentes e recebe uma string. A ferramenta não consulta seu DNS ativo, não conta as consultas recursivas e não sabe quantos registros SPF seu domínio já tem.
A maioria dos geradores gratuitos é apenas um montador de strings: produz algo que parece correto sem verificar se funciona no seu ambiente DNS real. O resultado está sintaticamente correto. Isso não significa que esteja correto do ponto de vista operacional.
Os 3 tipos de falha ignorados por todos os geradores de SPF
Toda grande falha de SPF em produção tem origem em um de três problemas. Um gerador comum não enxerga nenhum deles, pois trabalha sem acesso aos dados do seu DNS ativo nem à lógica de contagem usada pelos destinatários durante a avaliação.
1. PermError por registro duplo
Um domínio precisa ter exatamente um registro SPF. A RFC 7208 é clara: se o servidor destinatário encontrar dois registros TXT começando com v=spf1, ele retornará PermError, uma falha permanente. Gmail e Yahoo tratam PermError como ausência total de SPF. Seus e-mails são rejeitados ou enviados discretamente para o spam.
Os geradores nunca verificam se já existe um registro. Se o domínio está ativo há mais de alguns meses, provavelmente já tem um, criado pelo registrador, pelo provedor anterior ou por quem configurou o Google Workspace três anos atrás. Publicar o resultado do gerador sem verificar cria uma duplicata. Você acaba de quebrar algo que funcionava.
2. O limite de consultas recursivas
A RFC 7208 limita a avaliação de SPF a exatamente 10 consultas DNS. Essa contagem inclui cada include:, a, mx, exists e redirect, além de todas as consultas aninhadas acionadas por esses includes. Um gerador conta os mecanismos selecionados. Ele não conta o que há dentro deles.
| Provedor selecionado | Contagem do gerador | Consultas reais |
|---|---|---|
| Google Workspace | 1 | 4 (_netblocks.google.com aninhados, etc.) |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| Total | 4 | 10-12 → PermError |
O gerador mostra 4 consultas. O servidor destinatário chega à n.º 11 e interrompe a avaliação. Todas as mensagens do seu domínio falham no SPF. Não há aviso na interface nem e-mail de rejeição. Você descobre por meio de clientes irritados.
3. O limite de consultas vazias (RFC 7208 §11.1)
Existe uma restrição secundária: no máximo 2 consultas DNS podem retornar resultados vazios (NXDOMAIN). Um único erro de digitação em um include: cria uma consulta vazia. Dois erros desse tipo fazem todo o registro SPF falhar, mesmo que a verificação de sintaxe do gerador o tenha aprovado.
Exemplo:
include:spf.trekmaill.net(um 'l' a mais). A sintaxe é válida. O gerador marca o registro como correto. O servidor destinatário faz uma consulta, não encontra nada e registra a consulta vazia n.º 1. Basta um segundo include incorreto para todo o registro falhar.
Como auditar o resultado antes de publicar
Antes de publicar qualquer resultado do gerador, execute estas três verificações no DNS ativo. Elas levam cinco minutos e detectam todos os problemas críticos ignorados pela ferramenta: registros duplicados, profundidade excessiva de consultas e sintaxe incorreta. O processo funciona no macOS, Linux e Prompt de Comando do Windows.
Etapa 1: verifique se já existe um registro
Execute este comando antes de fazer alterações no DNS:
nslookup -type=txt yourdomain.comSe houver duas linhas começando com v=spf1, você tem uma duplicata. Combine-as manualmente em um único registro antes de publicar algo novo.
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -allEtapa 2: conte as consultas recursivas
Consulte o conteúdo de cada include: do seu registro:
dig +short txt _spf.google.comResultado:
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"Esse único include:_spf.google.com aciona 4 consultas reais. Repita o processo para cada provedor no registro e some os resultados. Se o total ultrapassar 10, será preciso reestruturar o conjunto, normalmente transferindo os e-mails transacionais para um subdomínio (send.yourdomain.com) com seu próprio registro mais curto.
Etapa 3: audite os mecanismos
Compare a string produzida pelo gerador com esta tabela:
| Mecanismo | Status | Ação |
|---|---|---|
ptr | Obsoleto | Exclua. A RFC 7208 desaconselha expressamente seu uso. É lento e pouco confiável. |
+all | Inseguro | Exclua. Ele autoriza toda a internet a enviar como seu domínio. |
ip4: 1.2.3.4 | Sintaxe inválida | Remova o espaço. Deve ser ip4:1.2.3.4. |
?all | Fraco | Evite. Uma política neutra não oferece proteção contra falsificação. |
~all | Aceitável | SoftFail. Use somente durante migrações, não como configuração permanente. |
-all | Correto | HardFail. Remetentes não autorizados são rejeitados. Use em produção. |
Lista de verificação da sintaxe SPF
Não importa se você usou um gerador no primeiro rascunho ou escreveu a string manualmente: revise esta lista antes de alterar o DNS. As verificações abrangem todos os problemas que um gerador não detecta, desde registros duplicados e limites de consultas recursivas até indicadores de política inseguros.
- Um registro por domínio. Se houver uma duplicata, combine os registros. Nunca publique dois.
- Começa com
v=spf1. Sem variações. A string exata. - Termina com
-allou~all. Nunca com+allou?all. - IPs antes dos includes. Os mecanismos
ip4:eip6:não consomem consultas DNS. Liste-os primeiro para agilizar a avaliação. - Sem autorreferência.
include:yourdomain.comcria um loop infinito. Exclua-o. - Não achate IPs manualmente sem uma automação que os mantenha atualizados. Se o Google mudar os IPs e você não atualizar o registro, seus e-mails deixarão de funcionar sem aviso.
- Total de consultas ≤ 10. Conte todas, inclusive os includes aninhados.
Um registro pronto para produção:
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allPrimeiro os IPs (sem custo de consultas), depois os includes e, no fim, a falha rígida. É só isso.
Por que agências e pequenas empresas deixam de depender de geradores SPF
Um gerador funciona para um único domínio com um ou dois remetentes. Quando a escala aumenta, com agências que gerenciam dezenas de clientes ou pequenas empresas com muitas ferramentas SaaS, ele se torna um risco operacional recorrente, sem visibilidade centralizada das consultas ou dos registros duplicados em todo o portfólio.
O método antigo: um registro SPF exclusivo por cliente, cada um criado em uma sessão diferente do gerador e sem trilha de auditoria. Um domínio atinge o limite de consultas. Três dias se passam antes que alguém perceba. A reputação de entrega do cliente sofre as consequências.
Para ter uma visão completa de como proteger a infraestrutura de e-mail no nível da empresa, consulte o guia sobre segurança do e-mail empresarial, que aborda toda a base necessária além do SPF.
Como a TrekMail elimina o problema dos geradores SPF
A complexidade do SPF surge da necessidade de gerenciar vários remetentes de terceiros e ficar abaixo do limite de 10 consultas. A TrekMail elimina os dois problemas da sua infraestrutura principal de e-mail. Assim, você não precisa usar um gerador, contar consultas aninhadas nem auditar mecanismos no domínio principal de envio.
Para pequenas empresas: um include, sem manutenção
No plano Starter da TrekMail ($3.50/mo), a entrega de saída passa pelo SMTP gerenciado da TrekMail. Seu registro SPF fica reduzido a uma única linha:
v=spf1 include:spf.trekmail.net -allA TrekMail gerencia a rotação de IP e a reputação do remetente por trás desse include. Em geral, não é necessário voltar a alterar o registro. Sem outra sessão no gerador nem auditoria de consultas seis meses depois, quando uma nova ferramenta SaaS for adicionada.
Para agências: um modelo para todos os clientes
O método antigo: 100 clientes, 100 registros SPF criados por 100 execuções diferentes do gerador, cada um com seu próprio risco de consultas recursivas. Qualquer um pode falhar sem avisar.
O método TrekMail: um modelo para todos os domínios de clientes:
v=spf1 include:spf.trekmail.net -allNo plano Agency ($23.25/mo), você pode gerenciar 1,000+ domínios em um único painel. Padronizar o e-mail corporativo na TrekMail elimina o problema das consultas recursivas no seu principal canal de comunicação. Se você está ampliando uma configuração multidomínio, veja como a hospedagem de e-mail para vários domínios muda o modelo de gerenciamento.
Para conhecer toda a configuração DNS que a TrekMail espera junto com o SPF, incluindo MX, DKIM e DMARC, o documento sobre registros DNS necessários aborda os quatro em um só lugar.
Perguntas frequentes sobre geradores de registros SPF
Estas perguntas surgem quando a primeira sessão com um gerador produz um registro que não funciona. Todas têm origem na diferença entre a validação sintática, feita pelo gerador, e a validação operacional, que exige a consulta do DNS ativo.
Posso usar dois geradores para comparar os resultados?
Pode, mas executar um segundo gerador não resolve o problema principal. Duas ferramentas diferentes produzirão duas strings diferentes, e nenhuma delas detectará registros duplicados no seu DNS ativo nem contará com precisão as consultas recursivas. As etapas de CLI acima oferecem uma verificação confiável.
O gerador diz que o registro é válido. Por que os e-mails são rejeitados?
Para um gerador de SPF, "válido" significa que a sintaxe está correta, não que o registro funciona no seu ambiente. As duas causas mais comuns dessa diferença são um registro duplicado que provoca PermError ou mais de 10 consultas recursivas. As duas exigem a inspeção do DNS ativo, não apenas a validação do resultado em uma interface.
Quando devo usar -all em vez de ~all?
Use -all (HardFail) em produção: remetentes não autorizados são rejeitados. Use ~all (SoftFail) somente durante uma migração, quando não tiver certeza de que listou todos os remetentes. É um estado temporário, não um objetivo final. Um gerador que usa ?all ou +all por padrão prioriza a aparência de funcionamento, não a entregabilidade real.
Resumo
Um gerador gratuito é um ponto de partida razoável para criar a string SPF, mas não é uma boa etapa final para produção. Os três problemas que ele ignora, registros duplicados, excesso de consultas recursivas e erros de consultas vazias, causam rejeições silenciosas e PermError cujo diagnóstico pode levar horas.
A solução não é um gerador melhor. É uma auditoria de cinco minutos pela CLI: procure registros duplicados, conte as consultas aninhadas e revise os mecanismos. Depois, publique.
Se preferir evitar todo o processo do gerador, a TrekMail consolida os envios em um único include:. Uma linha no DNS. Sem cálculos de consultas. Sem depurar PermError.
Inicie uma avaliação gratuita de 14 dias; é necessário informar um cartão de crédito, e você pode cancelar a qualquer momento.
