A maioria das organizações descobre os limites de registro SPF somente após a autenticação falhar. Nesse momento, emails legítimos já estão sendo rejeitados, caindo em spam ou falhando silenciosamente sem erros visíveis. O limite de 10 consultas DNS não é uma recomendação—é um limite técnico rígido que encerra a avaliação SPF e retorna um erro permanente, geralmente causando falha de alinhamento DMARC mesmo quando outras autenticações passam.
Sessenta e três por cento das organizações que utilizam três ou mais plataformas de email de terceiros excedem o limite de consultas SPF em até 18 meses após a implementação inicial, de acordo com dados recentes de benchmark de autenticação de email. A falha é estrutural: cada remetente autorizado adicionado ao SPF através de mecanismos include: aumenta a contagem de consultas DNS, e a maioria das organizações atinge o limite muito antes de perceber que está contando as consultas incorretamente.
Este artigo explica como funcionam os limites de consulta SPF, o que quebra quando você os excede, como identificar a falha antes que ela impacte a entrega e como reestruturar o SPF para permanecer dentro dos limites técnicos mantendo a cobertura de fornecedores.
I. O Que É o Limite de Consultas SPF?
SPF (Sender Policy Framework) valida que o servidor de envio de email está autorizado a enviar emails em nome de um domínio. O servidor receptor realiza consultas DNS para resolver o registro SPF e avaliar a cadeia de autorização. A RFC 7208 estabelece um limite rígido de 10 consultas DNS por avaliação SPF para prevenir abuso, recursão infinita e ataques de amplificação DNS.
Quando uma avaliação SPF excede 10 consultas DNS, o servidor receptor interrompe o processamento e retorna permerror. Isto é uma falha permanente, não uma condição temporária. O resultado é tratado como uma falha SPF na maioria das implementações, o que significa:
- Alinhamento DMARC falha mesmo se DKIM passar, porque SPF não passou e não alinhou.
- Sinais de reputação degradam porque provedores de caixa de entrada veem inconsistência na autenticação.
- Entrega torna-se imprevisível porque alguns servidores receptores filtram silenciosamente, outros rejeitam, e muitos não mostram a falha nas mensagens de rejeição.
O limite é fixo. Ele não escala com o tamanho do domínio, volume de email ou complexidade do negócio. Adicionar mais um remetente autorizado quando você já está em 10 consultas quebra o registro SPF inteiro.
II. Como as Consultas DNS São Contadas
A contagem de consultas SPF é frequentemente mal compreendida porque nem todo mecanismo em um registro SPF aciona uma consulta DNS. Os seguintes mecanismos contam para o limite de 10 consultas:
include:– Cada mecanismoinclude:aciona pelo menos uma consulta, e se o registro incluído contéminclude:,a,mxouptradicionais, esses contam recursivamente.a– Consulta o registro A do domínio.mx– Consulta o registro MX do domínio, e cada destino MX requer uma consulta adicional de registro A.ptr– Consulta o registro PTR (obsoleto e não deve ser usado).redirect=– Aciona uma consulta, mais quaisquer consultas dentro do registro redirecionado.exists:– Consulta o registro A do domínio especificado.
Os seguintes mecanismos não contam:
ip4:– Endereço IP estático, nenhuma consulta DNS necessária.ip6:– Endereço IPv6 estático, nenhuma consulta DNS necessária.all– Mecanismo que define ação padrão, nenhuma consulta DNS.
Exemplo: Explosão Oculta de Consultas
Um registro SPF aparentemente simples pode exceder o limite rapidamente:
v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.salesforce.com ~allContagem aparente de consultas: 5
Contagem real de consultas: 12+
Eis o porquê:
include:_spf.google.com→ 3 consultas (Google usa includes aninhados)include:sendgrid.net→ 2 consultasinclude:spf.protection.outlook.com→ 2 consultasinclude:mail.zendesk.com→ 2 consultasinclude:_spf.salesforce.com→ 3 consultas
Total: 12 consultas. Este registro retornará permerror e falhará na autenticação SPF.
As organizações frequentemente assumem que cinco declarações include: equivalem a cinco consultas. Não é assim. Cada domínio incluído pode expandir em múltiplas consultas aninhadas, e essas contam para o total.
III. O Que Quebra Quando Você Excede o Limite
1. SPF Retorna permerror
Quando o servidor receptor atinge o limite de 10 consultas, a avaliação SPF para e retorna permerror. Isso é registrado no cabeçalho Authentication-Results como:
spf=permerror (too many DNS lookups)O email não se beneficia da autenticação SPF. Se DKIM não estiver presente ou não alinhar, DMARC falha.
2. Alinhamento DMARC Falha
DMARC requer que SPF ou DKIM passe e alinhe com o domínio From:. Se SPF retornar permerror, ele não pode alinhar. Se DKIM estiver ausente, não assinado ou desalinhado, DMARC falha completamente.
Com p=quarantine ou p=reject, isso significa que o email é filtrado ou bloqueado. Com p=none, a falha é invisível, mas ainda é registrada em relatórios agregados, degradando a reputação ao longo do tempo.
3. Filtragem Silenciosa
Nem todos os provedores de caixa de entrada rejeitam emails com SPF permerror. Alguns degradam silenciosamente a entrega:
- O email cai em spam em vez da caixa de entrada.
- O email é atrasado ou limitado.
- O email é entregue mas sinalizado como potencialmente suspeito no cliente de email do destinatário.
Como a falha é silenciosa, as organizações frequentemente não percebem que o SPF está quebrado até que as taxas de reclamação aumentem, o engajamento caia ou uma grande campanha falhe.
4. Impacto Específico por Fornecedor
O impacto varia por fornecedor:
- Gmail: Trata
permerrorcomo um sinal de falha, mas ainda pode entregar se DKIM passar e a reputação do domínio for forte. No entanto, a colocação na caixa de entrada degrada com o tempo. - Microsoft 365: Trata
permerrorcomo falha SPF. Se DKIM não alinhar, o email é filtrado ou rejeitado dependendo da política e reputação. - Yahoo, AOL: Aplicação estrita.
permerrorfrequentemente resulta em rejeição ou filtragem de spam. - Listas de discussão, encaminhadores: SPF quebra durante encaminhamento porque o remetente de envelope não alinha. Se o registro SPF original já está em
permerror, email encaminhado não tem cobertura de autenticação.
5. Relatórios DMARC Mostram a Falha
Se sua política DMARC está definida como p=none com relatórios agregados habilitados, você verá permerror no campo de resultado spf dos relatórios agregados DMARC. O relatório mostra:
<auth_results>
<spf>
<domain>example.com</domain>
<result>permerror</result>
</spf>
</auth_results>A falha é registrada, mas se você não estiver revisando ativamente relatórios DMARC, não verá. É por isso que muitas organizações excedem o limite SPF sem perceber até que problemas de entrega apareçam.
IV. Como Identificar a Contagem de Consultas SPF Antes Que Quebre
Contagem Manual de Consultas SPF
Você pode contar manualmente consultas SPF expandindo recursivamente cada mecanismo include: e somando todos os mecanismos include:, a, mx, redirect= e exists: encontrados.
Processo passo a passo:
- Consulte seu registro SPF:
dig TXT example.com- Para cada mecanismo
include:, consulte o domínio incluído:
dig TXT _spf.google.com
dig TXT sendgrid.net- Conte todos os mecanismos que acionam consultas DNS no registro primário e em todos os registros aninhados.
Este processo é demorado e propenso a erros, especialmente quando fornecedores alteram seus registros SPF sem aviso.
Validação Automatizada de Consultas SPF
Use um verificador de registro SPF que conta automaticamente consultas DNS e identifica quais mecanismos contribuem para o total. Ferramentas como:
- Skysnag Domain Checker – Escaneia seu domínio, conta consultas SPF e sinaliza registros que excedem ou se aproximam do limite de 10 consultas.
dig+ recursão manual (técnico mas abrangente).- Validadores SPF de terceiros (variam em precisão; alguns não contam consultas aninhadas corretamente).
Skysnag Domain Checker mostra:
- Contagem atual de consultas
- Quais mecanismos
include:expandem em múltiplas consultas - Se o registro já está em
permerror - Recomendações para achatar ou reestruturar
V. Como Corrigir Problemas de Limite de Consultas SPF
1. Substituir include: por ip4: ou ip6: Onde Possível
Se um remetente terceiro fornece uma faixa de IP estática, substitua o mecanismo include: por endereços IP explícitos:
Antes:
v=spf1 include:mail.vendor.com ~allDepois:
v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.5 ~allIsso elimina consultas DNS para esse remetente. No entanto, essa abordagem só funciona se o fornecedor usa IPs estáticos e não rotaciona infraestrutura frequentemente. Muitas plataformas SaaS rotacionam IPs, tornando listagens estáticas impraticáveis.
2. Achatar o Registro SPF
Achatamento SPF resolve todos os mecanismos include: em seus endereços IP finais e os consolida em um único registro. Isso reduz consultas DNS mas cria risco operacional:
- Mudanças de IP do fornecedor quebram autenticação. Se um fornecedor adiciona ou rotaciona endereços IP, seu registro SPF achatado fica desatualizado, e email legítimo falha na autenticação.
- Atualizações manuais necessárias. Você deve monitorar registros SPF de fornecedores e atualizar seu registro achatado sempre que ocorrerem mudanças.
- Sem notificação quando fornecedores mudam. A maioria dos fornecedores não anuncia mudanças de registro SPF, então você só descobre a falha quando emails começam a ser rejeitados.
Achatamento funciona como correção de curto prazo, mas requer manutenção e monitoramento contínuos.
3. Usar Subdomínios para Segmentar Remetentes
Mova fluxos de email específicos para subdomínios dedicados e crie registros SPF separados para cada:
Exemplo:
example.com→ Autenticado para email de negócios primário (Microsoft 365)marketing.example.com→ Autenticado para plataformas de marketing (SendGrid, Mailchimp)support.example.com→ Autenticado para ferramentas de suporte (Zendesk, Intercom)
Cada subdomínio tem seu próprio registro SPF, e cada registro permanece abaixo do limite de 10 consultas. Essa abordagem funciona bem para organizações com segmentação clara de remetentes, mas requer:
- Suporte da plataforma de email para envio por subdomínio (nem todas as plataformas suportam isso).
- Configuração DNS para cada subdomínio.
- Alinhamento de política DMARC através de subdomínios (se não configurado, DMARC pode falhar).
4. Remover Mecanismos include: Não Utilizados ou Redundantes
Muitos registros SPF incluem remetentes que não estão mais em uso:
- Plataformas de marketing legadas
- Ferramentas de suporte desativadas
- Declarações
include:duplicadas (por exemplo, duas entradas para o mesmo fornecedor) - Fornecedores que foram testados mas nunca implantados
Audite seu registro SPF e remova quaisquer mecanismos include: que não correspondem a remetentes ativos. Use Skysnag Protect para identificar quais remetentes estão enviando email ativamente e quais entradas include: não são utilizadas.
5. Consolidar Fornecedores Onde Possível
Se você usa múltiplas plataformas de marketing, ferramentas de suporte ou provedores de email transacional, consolide em menos fornecedores. Isso reduz o número de mecanismos include: e simplifica o gerenciamento SPF.
Por exemplo:
- Use uma plataforma de email transacional em vez de três.
- Consolide email de marketing através de um único ESP.
- Roteie email de suporte através de um sistema de tickets.
Esta é uma decisão de negócios, não apenas uma correção técnica, mas é a forma mais sustentável de reduzir a complexidade SPF.
VI. Limite de Consultas SPF e Aplicação DMARC
Quando SPF excede o limite de consultas e retorna permerror, a avaliação DMARC depende de DKIM passar e alinhar.
Cenário 1: SPF permerror + DKIM Passa + DKIM Alinha
DMARC passa porque DKIM fornece a autenticação e o alinhamento necessários. A falha SPF não bloqueia a entrega, mas enfraquece a postura geral de autenticação.
Cenário 2: SPF permerror + DKIM Falha ou Ausente
DMARC falha. Se sua política está definida como p=quarantine ou p=reject, o email é filtrado ou recusado durante a entrega SMTP quando o servidor receptor honra a política. Se sua política é p=none, a falha é registrada mas não aciona aplicação.
Cenário 3: SPF permerror + DKIM Passa mas Desalinhado
DMARC falha. DKIM deve alinhar com o domínio From: (alinhamento estrito ou relaxado). Se DKIM passar mas não alinhar, e SPF está em permerror, DMARC não tem caminho de autenticação válido.
O modo de falha mais comum é o Cenário 2—SPF quebra, DKIM não está configurado para o remetente terceiro, e DMARC falha completamente.
VII. Como Monitorar a Contagem de Consultas SPF ao Longo do Tempo
Registros SPF mudam conforme você adiciona ou remove remetentes autorizados. Monitorar a contagem de consultas previne falhas de autenticação antes que elas impactem a entrega.
Use Skysnag Protect para Monitoramento SPF Contínuo
Skysnag Protect monitora continuamente seu registro SPF e rastreia a contagem de consultas DNS. Quando um fornecedor atualiza seu registro SPF e sua contagem total de consultas aumenta, Skysnag alerta você antes que o limite de 10 consultas seja excedido.
Como funciona:
- Skysnag escaneia seu registro SPF diariamente.
- Rastreia contagem de consultas para todos os mecanismos
include:. - Alerta você quando a contagem de consultas se aproxima ou excede o limite.
- Fornece recomendações para achatamento, segmentação de subdomínio ou consolidação de IP.
Isso previne o modo de falha silenciosa onde SPF quebra e você só descobre quando a entrega degrada.
Comece a monitorar seu registro SPF com Skysnag Protect.
VIII. Alternativas ao SPF: MTA-STS e Autenticação Somente DKIM
Algumas organizações eliminam SPF completamente e confiam em DKIM para autenticação. Isso evita o limite de consultas, mas remove o papel do SPF na prevenção de spoofing no nível de envelope.
Autenticação Somente DKIM
DKIM autentica o corpo da mensagem e cabeçalhos usando uma assinatura criptográfica. Não valida o remetente de envelope (o endereço usado durante SMTP), então não previne certos tipos de spoofing. No entanto, DKIM não tem limite de consultas, não quebra durante encaminhamento e fornece garantias criptográficas mais fortes que SPF.
Se você implementar autenticação somente DKIM:
- Garanta que DKIM esteja configurado para todos os remetentes autorizados.
- Use DMARC com
aspf=r(alinhamento relaxado) para permitir flexibilidade de subdomínio. - Monitore relatórios agregados DMARC para verificar cobertura DKIM.
MTA-STS para Segurança de Transporte
MTA-STS (Mail Transfer Agent Strict Transport Security) força entrega criptografada, mas não substitui SPF ou DKIM. Garante que email seja entregue via TLS, prevenindo ataques man-in-the-middle, mas não autentica o remetente.
MTA-STS funciona juntamente com DMARC, não como substituto.
IX. Erros Comuns com Limite de Consultas SPF
1. Assumir Que Registros SPF de Fornecedores Nunca Mudam
Fornecedores atualizam seus registros SPF para adicionar infraestrutura, rotacionar IPs ou mudar provedores de hospedagem. Se você achatar seu registro SPF e não monitorar mudanças de fornecedores, a autenticação quebra silenciosamente.
2. Contar Declarações include: em Vez de Consultas DNS
Um registro SPF com 5 mecanismos include: pode acionar 12+ consultas DNS porque cada registro incluído pode conter include:, a ou mx aninhados adicionais.
Sempre conte as consultas DNS recursivas totais, não apenas os mecanismos de nível superior.
3. Usar Mecanismos ptr
O mecanismo ptr é obsoleto e ineficiente. Aciona consultas DNS reversas e aumenta a contagem de consultas. Não use ptr em registros SPF modernos.
4. Não Testar Mudanças SPF Antes de Publicar
Publicar uma mudança SPF sem testar pode quebrar autenticação para todo email. Use um domínio de teste ou subdomínio para validar o registro antes de aplicá-lo à produção.
5. Ignorar Relatórios Agregados DMARC
Relatórios DMARC mostram falhas permerror do SPF, mas muitas organizações não revisam relatórios regularmente. Configure monitoramento através do Skysnag para revelar problemas SPF antes que impactem a entrega.
X. Principais Conclusões
Limites de consultas SPF não são flexíveis. O limite de 10 consultas DNS é uma restrição técnica fixa, e excedê-lo retorna permerror, que quebra autenticação SPF e frequentemente causa falha DMARC.
Organizações usando múltiplas plataformas de email de terceiros comumente excedem o limite sem perceber porque consultas DNS são contadas recursivamente, e registros SPF de fornecedores mudam sem aviso.
A falha é frequentemente silenciosa. Email ainda pode ser entregue, mas cai em spam, é limitado ou degrada reputação ao longo do tempo. Relatórios agregados DMARC mostram o resultado permerror, mas se relatórios não são monitorados ativamente, a falha passa despercebida até que problemas de entregabilidade apareçam.
Para permanecer dentro do limite de consultas SPF:
- Substitua mecanismos
include:porip4:ouip6:onde fornecedores usam IPs estáticos. - Segmente fluxos de email através de subdomínios para distribuir contagem de consultas.
- Remova entradas
include:não utilizadas ou legadas. - Consolide fornecedores para reduzir complexidade SPF.
- Monitore registros SPF continuamente para detectar mudanças de fornecedores.
Use Skysnag Protect para monitorar contagem de consultas DNS, identificar quais remetentes contribuem para inflação de consultas e receber alertas antes que SPF quebre. Skysnag fornece visibilidade na estrutura SPF, rastreia mudanças de registro de fornecedores e ajuda você a reestruturar registros antes que a autenticação falhe.
