Limite de consultas SPF: diagnóstico e soluções

O limite de consultas SPF é simples: quando a avaliação da política SPF ultrapassa o orçamento de 10 termos que acionam consultas DNS, o servidor destinatário pode interromper o processamento e retornar um erro permanente. Assim, uma configuração que parece correta no painel DNS pode falhar na autenticação durante o envio. Se você já está organizando o e-mail do domínio, comece por e-mail empresarial para pequenas empresas e depois volte para corrigir o que costuma dar problema mais adiante.

Muitas equipes caem nessa armadilha. Adicionam Google Workspace, depois Microsoft 365, Mailchimp, um CRM e uma plataforma de atendimento. Cada fornecedor diz: “Basta adicionar nosso include.” Alguns meses depois, o registro SPF continua válido na sintaxe, mas falha na prática. As mensagens começam a cair no spam. Algumas são devolvidas. Ninguém entende o motivo, porque o registro ainda parece normal à primeira vista.

A boa notícia é que a correção geralmente é simples. Remova entradas obsoletas. Pare de usar `mx`, a menos que ele seja realmente necessário. Separe o tráfego de marketing em um subdomínio. Mantenha o domínio principal organizado.

O que é o limite de consultas SPF?

O limite de consultas SPF é o teto definido pelo RFC para os termos SPF que acionam consultas DNS durante a avaliação. O destinatário não deve processar mais de 10 desses termos no caminho avaliado da árvore SPF, incluindo cadeias de `include` aninhados. Se a política ultrapassar esse teto, SPF pode retornar `permerror`, e a mensagem perde um sinal importante de autenticação.

O RFC 7208 define essa regra. O teto evita que SPF provoque problemas de amplificação DNS. Não é opcional nem uma simples boa prática: é um limite do protocolo.

Um detalhe que muita gente ignora é que o limite de consultas SPF é cumulativo. Você não tem 10 consultas no registro raiz e outras 10 dentro de cada include. Há um único orçamento para todo o caminho de avaliação.

Mecanismo SPF	Custo em consultas	Orientação prática
`include:`	1	Comum, mas includes aninhados se acumulam rapidamente
`a`	1	Adequado em configurações pequenas; muitas vezes desnecessário
`mx`	1+	Geralmente não é uma boa escolha para autorizar envios
`ptr`	1+	Evite; o RFC 7208 desaconselha fortemente seu uso
`exists`	1	Pouco comum e fácil de usar incorretamente
`redirect=`	1	Útil em certos projetos, mas também entra na conta
`ip4` / `ip6`	0	Não aciona consultas DNS durante a avaliação SPF
`all`	0	Apenas define a política, sem custo de consulta

Por que o limite de consultas SPF derruba registros que “funcionam”

O limite de consultas SPF pode fazer registros aparentemente corretos falharem porque SPF não considera a aparência organizada do TXT raiz. Ele considera os termos que acionam DNS e precisam ser avaliados ao seguir include, redirect, `a` e `mx` no caminho completo.

Exemplo:

Você publica `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` e acha que usou três consultas. Não é bem assim. Google e Microsoft podem acrescentar consultas nos registros internos. O registro visível é curto; o caminho avaliado pode não ser.

Por isso, o limite de consultas SPF costuma aparecer como problema depois, não no primeiro dia. Conforme os fornecedores alteram suas árvores SPF, a contagem pode subir mesmo sem novas edições no seu DNS.

Existe outra armadilha: consultas vazias. O RFC 7208 recomenda que as implementações as limitem a duas. Uma consulta vazia é uma consulta DNS que não retorna respostas ou retorna `NXDOMAIN`. Um erro de digitação em um include pode não interromper tudo. Duas referências inválidas podem causar uma falha. Assim, o problema do limite de consultas SPF vira um `permerror` mesmo quando você ainda está abaixo de 10.

As orientações do Google para remetentes também mostram o que está em jogo: autenticação ausente ou incorreta pode levar ao spam ou à rejeição de mensagens de remetentes em massa. O Google informa que esses remetentes precisam configurar SPF, DKIM e DMARC e que mensagens fora dos requisitos podem ser rejeitadas ou encaminhadas ao spam. Veja as perguntas frequentes sobre os requisitos do Google para remetentes.

Como calcular o uso do limite de consultas SPF

Para calcular o consumo do limite de consultas SPF, comece pelo registro SPF raiz e conte os mecanismos que acionam DNS ao longo de cada caminho de avaliação da árvore recursiva. Inclua seus próprios termos e os referenciados pelos fornecedores. Se um caminho ultrapassar 10, a política pode falhar na prática.

Comece pelo registro raiz:

dig +short txt example.com

Exemplo de saída:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Depois, inspecione cada domínio referenciado:

dig +short txt _spf.google.com

dig +short txt spf.protection.outlook.com

Continue seguindo as referências até encontrar apenas `ip4`, `ip6` ou termos finais da política.

Use este modelo de contagem:

Conte cada include, a, mx, ptr, exists e redirect encontrado no caminho avaliado.
Conte também os termos aninhados nos registros incluídos.
Não conte ip4, ip6 nem all.
Marque qualquer destino de include que não retorne dados. Ele pode causar consultas vazias.

Para uma verificação rápida do DNS durante a configuração de um domínio no TrekMail, comece pela documentação sobre verificação do status do DNS e registros DNS necessários.

Erros comuns relacionados ao limite de consultas SPF

A maioria das falhas do limite de consultas SPF vem de erros recorrentes: acumular fornecedores em um domínio raiz, manter provedores antigos, usar `mx` como atalho e fazer achatamento manual sem um processo de manutenção. Não são situações excepcionais, mas problemas de organização do DNS que se agravam com o crescimento.

Os principais erros:

Erro	Por que prejudica	Melhor alternativa
Manter fornecedores antigos	Consome o orçamento de consultas e amplia o risco	Remova serviços que não usa mais para enviar
Usar `mx` para autorizar envios	Os hosts MX de entrada muitas vezes não são os remetentes	Autorize explicitamente o remetente real
Usar `ptr`	Lento, desaconselhado e frágil	Remova-o
Enviar tudo de um único domínio	Marketing e mensagens transacionais disputam o mesmo orçamento SPF	Separe os fluxos em subdomínios
Fazer achatamento manual	Pode falhar quando os fornecedores trocam IPs	Automatize as atualizações ou evite o achatamento

É aqui também que as equipes confundem complexidade visível com complexidade real. Um único include pode consumir várias consultas quando expandido. Por isso, o limite de consultas SPF acaba cobrando o preço da ideia de “adicionar só mais um remetente”.

Se você ainda está decidindo entre encaminhamento, alias ou uma caixa postal real para determinada tarefa, essas escolhas estão mais ligadas à configuração dos remetentes do que parecem. Leituras relacionadas: alias de e-mail de domínio ou caixa postal e encaminhamento com alias de e-mail.

Como corrigir o limite de consultas SPF sem interromper o e-mail

A forma mais prudente de resolver o limite de consultas SPF é reduzir a complexidade do SPF, em vez de acumular soluções improvisadas. Primeiro, remova os remetentes obsoletos. Depois, mova sistemas de maior volume para subdomínios. Só faça achatamento se puder manter tudo atualizado automaticamente.

1. Remova o que não serve mais.

Exclua fornecedores que não usa. Remova `ptr`. Substitua `mx` pela autorização do remetente realmente necessária. Muitas políticas SPF com problemas voltam a ficar abaixo do limite de consultas SPF com uma rodada de limpeza.

2. Separe o tráfego por subdomínio.

Costuma ser uma boa solução para equipes em crescimento.

; Primary company mail
example.com.              TXT  "v=spf1 include:spf.trekmail.net -all"

; Marketing mail
marketing.example.com.    TXT  "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"

; Transactional app mail
notify.example.com.       TXT  "v=spf1 include:amazonses.com -all"

Cada subdomínio tem seu próprio orçamento SPF. Isso ajuda a manter o domínio raiz estável e torna o limite de consultas SPF muito mais fácil de administrar.

3. Faça achatamento apenas como último recurso.

O achatamento substitui includes por faixas de IP explícitas:

; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all

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

Ele reduz o consumo de consultas a quase zero, mas cria uma obrigação de manutenção. Os fornecedores mudam seus IPs, o registro fica desatualizado e o envio pode falhar. Se fizer achatamento, automatize as atualizações.

Abordagem antiga e nova: gerenciar o limite de consultas SPF com TrekMail

A abordagem antiga para lidar com o limite de consultas SPF é acumular provedores de caixas postais, plataformas de marketing e relays em um único domínio raiz até que revisar o DNS vire uma escavação histórica. A nova abordagem reduz as dependências e separa as funções de envio desde o início.

Abordagem antiga: registro SPF raiz sobrecarregado, provedores antigos ainda presentes, marketing misturado ao tráfego das caixas postais e nenhuma responsabilidade clara sobre quem pode enviar.

Nova abordagem: simplificar a hospedagem de caixas postais, isolar remetentes de alto volume em subdomínios e manter uma política SPF curta, com margem, no domínio principal.

O TrekMail pode ajudar nessa organização. Com envio gerenciado do TrekMail em planos pagos, a configuração descrita consiste em adicionar `include:spf.trekmail.net` ao registro SPF. Esse termo consome uma consulta direta; também é preciso verificar possíveis dependências aninhadas. A oferta descrita começa em $3.50/mês e inclui domínios personalizados, caixas IMAP, catch-all, encaminhamento de caixas postais, ferramenta de migração integrada e acesso à API. Os planos pagos preveem um teste gratuito de 14 dias com cartão de crédito obrigatório. O Nano é apresentado como gratuito, sem período de teste, e usa BYO SMTP; confira as condições atuais.

No Nano, o TrekMail pode funcionar como a camada de caixas postais enquanto você envia pelo SES, Mailgun ou outro relay. Organize os subdomínios com cuidado para que a política raiz não atinja o limite de consultas SPF. A documentação do TrekMail sobre SMTP personalizado (BYO), SMTP gerenciado do TrekMail e início de uma migração pelo painel aborda os detalhes operacionais.

Se você está consolidando domínios, também pode consultar hospedagem de e-mail multidomínio e como configurar e-mail no seu domínio.

Conclusão: como ficar abaixo do limite de consultas SPF

A melhor maneira de respeitar o limite de consultas SPF é manter o SPF simples. Use o menor número possível de remetentes no domínio raiz. Mova envios em massa e de aplicativos para subdomínios. Verifique os includes dos fornecedores sempre que adicionar uma ferramenta. Se a política estiver perto de 10, trate isso como um sinal de risco.

Esse é o ponto principal. O limite de consultas SPF não é um caso teórico raro do RFC, mas uma restrição operacional que dificulta o crescimento baseado em acumular serviços. Mantenha o registro curto e as responsabilidades sobre DNS claras. Não faça cinco fornecedores compartilharem um único caminho de autenticação com orçamento limitado, a menos que você goste de analisar cabeçalhos às 2 da manhã.

Para uma configuração mais simples, o TrekMail oferece hospedagem de e-mail multidomínio com tarifa fixa, sem cobrança por usuário, armazenamento compartilhado, migração IMAP integrada e a opção de BYO SMTP ou SMTP gerenciado pelo TrekMail, conforme a oferta e o plano em vigor. Consulte os preços do TrekMail ou acesse TrekMail.