Limite de consultas SPF: como verificar e corrigir

O limite de consultas SPF pode parecer um detalhe do DNS até a autenticação começar a falhar. Você adiciona um remetente, um CRM ou uma ferramenta de suporte, e a política ultrapassa um limite do protocolo. A mensagem pode acabar filtrada ou rejeitada, conforme as regras do destinatário. Esse erro não determina sozinho o resultado da entrega.

Para entender o papel de SPF na sua configuração, comece por e-mail empresarial. O contexto importa: SPF não é apenas uma configuração de marca. É um sinal de autenticação que os destinatários podem usar para avaliar mensagens.

Este guia explica o que SPF limita, quais termos contam, por que o achatamento do registro exige manutenção adicional e quais alternativas considerar para uma configuração sustentável.

O que é o limite de consultas SPF?

O limite de consultas SPF restringe os termos que exigem consultas DNS durante a avaliação, não simplesmente todos os pacotes DNS enviados. Pela RFC 7208, o limite é 10; ultrapassá-lo produz permerror em vez de aprovação.

Em resumo, SPF tem um orçamento. Se a avaliação percorre mais de 10 termos que exigem consultas DNS, o destinatário deve interrompê-la e retornar erro permanente. Não é uma peculiaridade do Gmail, mas uma regra de SPF.

A RFC 7208 identifica os termos que consomem esse orçamento: include, a, mx, ptr, exists e redirect. Já ip4, ip6 e all não contam para esse limite durante a avaliação.

A distinção é importante porque o tamanho do texto não representa o custo da avaliação. Um registro curto pode falhar; um maior pode ser avaliado corretamente. É preciso examinar os termos efetivamente percorridos e suas dependências.

O que conta para o limite de consultas SPF?

O limite de consultas SPF conta os mecanismos e modificadores relevantes que usam DNS, não as palavras do TXT. Os termos correspondentes dentro de includes aninhados também contam. Assim, o painel DNS pode esconder parte do custo real.

Estes termos consomem orçamento quando são avaliados:

include: avalia a política de outro domínio e corresponde quando ela retorna pass.
a: consulta endereços do nome indicado e os compara com o IP conectado.
mx: obtém servidores MX e consulta seus endereços, com limites adicionais específicos.
ptr: faz verificações reversas e diretas; seu uso é desaconselhado.
exists: consulta registros A do nome indicado e corresponde se algum for retornado.
redirect: delega a outra política SPF se nenhum mecanismo anterior corresponder.

Estes termos não consomem esse orçamento de consultas na avaliação SPF:

ip4
ip6
all

O ponto delicado é a contagem recursiva. Se você inclui a Microsoft e sua política inclui outra, os termos relevantes avaliados nessa dependência também entram no total. Sua configuração depende da estrutura SPF dos fornecedores.

Você acha que adicionou 6 remetentes. Depois de percorrer as dependências, o destinatário pode avaliar 11 ou 12 termos sujeitos ao limite. É assim que o orçamento SPF pode ser excedido mesmo quando parecia estar abaixo de 10.

Por que o problema aparece quando a equipe adiciona ferramentas

O limite de consultas SPF costuma virar um problema com a incorporação de serviços. Marketing, suporte, recrutamento, CRM e envio transacional podem pedir um include na política do mesmo domínio, embora seus remetentes do envelope não precisem compartilhar esse domínio.

No início, o registro pode ser simples. Os exemplos seguintes são ilustrativos; verifique os valores atuais dos fornecedores antes de publicar:

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

Depois, a configuração cresce:

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

Você já não mantém apenas uma lista local, mas uma cadeia de dependências que os fornecedores podem alterar.

Por isso, o problema pode parecer aleatório em produção. Seu DNS não mudou hoje, mas um fornecedor pode ter ampliado suas dependências. Uma rota que antes funcionava pode passar a retornar permerror. Meça depois das mudanças e faça revisões periódicas.

Se o problema de entrega parece mais amplo que SPF, consulte o guia TrekMail sobre por que os e-mails vão para o spam. Autenticação, reputação e conteúdo são sinais distintos que podem atuar ao mesmo tempo.

O que acontece quando o limite é ultrapassado?

Quando o limite de consultas SPF é excedido, a avaliação retorna permerror. Isso não obriga todos os destinatários a tratar a mensagem da mesma forma, mas essa avaliação deixa de fornecer uma aprovação SPF.

Não existe aprovação parcial por ter ficado perto do orçamento. Ainda assim, SPF sozinho não determina DMARC nem a entrega final.

Estado	O que o destinatário vê	Possível efeito operacional
Menos de 10 termos sujeitos ao limite	Avaliação possível se os demais requisitos forem atendidos	SPF pode aprovar um IP autorizado; respeitar o orçamento não basta.
Mais de 10 termos sujeitos ao limite	Permerror	A mensagem pode ser filtrada ou rejeitada conforme a política do destinatário.
SPF permerror e DKIM inválido	Sem via alinhada se nenhuma outra assinatura válida a fornecer	DMARC pode falhar; o destinatário decide o tratamento.
SPF permerror e DKIM válido	DKIM pode fornecer uma via alternativa	DMARC passa se a assinatura válida estiver alinhada; não garante caixa de entrada.

As recomendações do Google relacionam entrega a autenticação e alinhamento corretos, com exigências conforme a categoria de remetente. Se você envia para Gmail em grande volume, revise SPF, DKIM e o escopo atual das diretrizes para remetentes.

Há outros dois limites relacionados que merecem atenção:

Consultas sem dados úteis. A RFC 7208 recomenda limitar a duas as consultas que retornam nome inexistente ou ausência de dados. Um erro em um include ou um domínio desativado merece revisão, mas o efeito depende da resposta DNS e da avaliação.
Tamanho da resposta DNS. Uma resposta grande pode ser truncada e exigir outro transporte. Se esse recurso falhar, podem surgir erros temporários ou tempos de espera; o tamanho sozinho não causa necessariamente a falha.

Por que achatar SPF nem sempre é a melhor solução

O limite de consultas SPF incentiva a troca de includes por IPs, conhecida como achatamento ou flattening. Isso reduz termos que exigem DNS, mas transfere a manutenção das autorizações para quem publica o TXT.

Exemplo de achatamento manual:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Esses termos não consomem o orçamento indicado. Porém, fornecedores SaaS podem mudar faixas de IP e infraestrutura. Um registro desatualizado pode excluir remetentes legítimos ou continuar autorizando endereços que já não pertencem ao serviço. As faixas do exemplo são ilustrativas.

Uma prática antiga era acumular fornecedores no SPF raiz e achatá-lo quando ficava complicado.

Uma alternativa separa funções de envio por subdomínios, mantém políticas específicas e configura DKIM alinhado. Pode facilitar manutenção e identificação de problemas se os serviços realmente usarem esses subdomínios nas identidades SMTP.

No TrekMail, compare as condições atuais da hospedagem multidomínio e da cobrança sem tarifas por caixa ou domínio, sem presumir que todos os provedores antigos cobram da mesma forma. Os recursos podem incluir domínios personalizados, caixas IMAP, catch-all, migração, encaminhamento e SMTP próprio ou gerenciado conforme o plano. A fonte descreve SMTP próprio no Free e SMTP gerenciado nos planos pagos; confirme disponibilidade e limites atuais. Veja registros DNS obrigatórios e SMTP personalizado (BYO).

Uma solução sustentável: segmentar os remetentes

A segmentação é uma opção de longo prazo para o limite de consultas SPF. Separe correspondência, marketing, suporte e transações quando os serviços permitirem configurar os domínios do remetente do envelope. Cada política pode ter suas próprias dependências, mas isso não representa isolamento absoluto de reputação.

Este modelo pode servir de referência:

Domínio raiz para correspondência pessoal. Exemplo: alice@company.com.
Subdomínio de marketing. Exemplo: newsletter.company.com.
Subdomínio de suporte. Exemplo: support.company.com.
Subdomínio transacional. Exemplo: updates.company.com.

Registros ilustrativos, a adaptar ao domínio realmente usado no envelope:

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

Se as identidades usam políticas independentes, cada avaliação tem seu orçamento de 10 termos. Publicar TXT em outros subdomínios ou mudar somente o From visível não divide o custo da política original. Verifique também DMARC: o alinhamento relaxado admite o mesmo domínio organizacional; o estrito exige correspondência exata. Uma assinatura DKIM válida e alinhada também pode fornecer a aprovação.

A separação pode ajudar a acompanhar reputação por fluxo, mas os destinatários podem relacionar subdomínios, domínio organizacional e IPs compartilhados. Não protege automaticamente a correspondência raiz de práticas ruins de marketing.

Para começar, consulte adicionar um domínio e verifique o DNS com testes reais. Para sair de provedores antigos, a migração IMAP pode ajudar a copiar dados das caixas conforme os recursos disponíveis. DNS, remetentes de aplicativos e autenticação exigem trabalho separado.

Como verificar o custo de avaliação SPF

Meça o limite de consultas SPF, em vez de estimar por intuição. Obtenha o TXT e percorra cada include e suas dependências, considerando a rota de avaliação para os IPs e as identidades reais.

Comece com dig:

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Depois conte os termos relevantes efetivamente avaliados, incluindo os aninhados. Esses comandos mostram registros, mas não substituem uma avaliação SPF completa.

Um procedimento prático:

Obtenha o TXT SPF do domínio usado no remetente do envelope.
Liste include, a, mx, exists e redirect; revise também qualquer mecanismo reverso legado.
Percorra políticas aninhadas respeitando a semântica e a ordem de avaliação.
Retire serviços que já não enviam depois de verificar o inventário.
Avalie subdomínios e teste identidades antes de considerar o achatamento.

Confira também SPF duplicado. Deve existir uma única política SPF por nome, integrando as autorizações, não registros SPF separados para cada serviço. Para reorganizar uma configuração complexa, veja criar e-mail com domínio, hospedagem multidomínio e imapsync.

O papel do TrekMail em uma configuração fácil de manter

O TrekMail não elimina o limite de consultas SPF: ele é uma restrição do protocolo. Seu modelo pode facilitar uma arquitetura menos dispersa, mas custo e simplicidade dependem das necessidades e do plano.

Isso pode interessar a dois públicos.

Equipes pequenas podem manter uma política simples para a correspondência raiz e escolher SMTP próprio ou gerenciado conforme a necessidade. Agências e provedores de serviços gerenciados podem separar clientes e comparar recursos de inclusão de domínios com tarifas sem cobrança por usuário. Confirme os recursos atuais e documente as identidades de cada remetente.

Abordagem antiga e abordagem atual:

Antiga: reunir correspondência, aliases, aplicativos e marketing em um provedor e uma política SPF para evitar possíveis cobranças adicionais.

Atual: avaliar uma plataforma multidomínio com tarifa fixa, centralizar caixas IMAP, separar identidades por subdomínios e manter políticas revisadas diante de mudanças dos fornecedores.

Segundo a fonte, Starter começa em $3.50 por mês. Free custa $0 com 10 domínios, 5GB de armazenamento compartilhado e SMTP próprio. Planos pagos acrescentam SMTP gerenciado, limites maiores e automação conforme a oferta. Preços, nomes de planos e recursos podem mudar; consulte os preços do TrekMail.

Conclusão: trate o limite SPF como uma restrição de projeto

O limite de consultas SPF é uma restrição do protocolo a considerar na arquitetura. Ao incorporar ferramentas, reserve margem e examine as dependências, sem presumir que todo crescimento necessariamente causará falhas.

Não espere permerror para revisar uma política sobrecarregada. Faça inventário de remetentes, retire autorizações obsoletas verificadas e considere subdomínios. Teste SPF e alinhamento DMARC depois das mudanças e prepare reversão para proteger o tráfego legítimo.

Para administrar essa arquitetura em poucos ou muitos domínios, compare os recursos atuais do TrekMail: domínios personalizados, caixas IMAP, armazenamento compartilhado, migração de caixas e opções SMTP sob condições sem cobrança por usuário. Consulte a oferta gratuita em trekmail.net ou compare planos em trekmail.net/pricing. Nenhuma plataforma garante sozinha DNS correto ou chegada à caixa de entrada.